|
Десять самых распространенных проблем в ИТ разработке
1. Ненадлежащее отношение к спецификациям - полное их отсутствие или лишь формальное наличие.
Если это так, то при этом практически на 100% со стороны заказчика последуют претензии вида "А надо было совсем другое". Точно также при отсутствии спецификаций сложно адекватно управлять меняющимися требованиями. Ведь если с самого начала не определено, что надо, то в ответ на просьбу заказчика "добавить еще одну маленькую фичу" ответить будет сложно. А еще сложнее - оценить, сколько для этого потребуется времени.
2. Недостаточное выделение времени на дизайн системы.
Ну не любят программисты писать документы, не любят! И одна мысль о том, что собственно написание кода в правильно организованном проекте должно занимать не более 30% времени, кажется им кощунственной :) В результате, если вместо серьезной разработки дизайна сразу броситься все реализовывать, получится слабоструктурированная смесь кода, изобилующая примерами из списка антипаттернов. Дизайн - это важно!
3. Излишнее усложнение.
Очень часто самый эффективный способ что-то сделать - слишком скучен для "продвинутых" программистов. И в такой ситуации они могут захотеть внести в проект что-нибудь интересное, даже если оно там нафиг не нужно. Другой пример - пытаться построить слишком универсальную систему, даже если этого не требует заказчик. В этом случае опять же разрабатываемый проект сильно усложнится, как следствие на него будет потрачено гораздо больше ресурсов, не говоря уже о том, что из-за чрезмерного усложнения проект вообще может не быть завершен успешно.
4. Слишком ранняя оптимизация или оптимизация того, что оптимизировать не надо.
Еще одна "болезнь" слишком "продвинутых" разработчиков - стремление все оптимизировать. Даже если оптимизация в этом месте не нужна вообще. Да, написанный на ассемблере кусок кода действительно будет в разы быстрее, но при этом его будет в разы сложнее отлаживать и сопровождать. И если на самом деле эта оптимизация не нужна, то лучше пойти по менее оптимальному, но более простому (более наглядному, более сопровождаемому) пути. И даже если она реально нужна, вначале нужно написать все понятно и неоптимально, потом провести анализ по выявлению реального "узкого места", и только после этого переписать это "узкое место" более оптимально (и скорее всего, с потерей легкости чтения и сопровождения, и чтобы это скомпенсировать, лучше не удалять старый, неоптимальный, но при этом понятный код, а закомментировать его, и к нему дописать комментарий, объясняющий смысл проведенной оптимизации)
5. Отсутствие отдельной группы верификаторов
Очень часто принимается решение "сэкономить" на верификаторах. Мол, пусть сами разработчики и тестируют свой код. Подход же этот в корне неверный. Не может автор кода адекватно его протестировать. Вот не может - и точка. Да, он безусловно будет проводить какое-то тестирование и отладку в процессе написания кода, но основные ошибки он выявить не сможет. Так уж устроен человек - он всегда, даже не осознавая этого, будет избегать ситуаций, в которых его код может "упасть". И экономия на верификаторах выливается в потери на исправления ошибок в финальном релизе у заказчика (или, что сильно хуже - у покупателей после выхода продукта на рынок). Тщательное тестирование возможно только тогда, когда проводится отдельной командой людей.
6. Слишком позднее начало тестирования
Одна из наиболее распространенных практик - начинать тестирование после завершения разработки. И это далеко не самая правильная практика. На самом деле тестирование надо начинать намного раньше, в идеале - сразу же после написания функциональных спецификаций. Как только спецификации готовы, верификаторы могут начинать процесс составления тестовых сценариев, готовить необходимое тестовое окружение, и как только у вас появится код, который можно тестировать - приступить к непосредственно тестированию.
7. Отсутствие внутреннего контроля качества кода, например, при помощи code review
Наверняка у вас в команде есть люди разного уровня. И если вы не проводите code review, то рискуете пропустить в финальный релиз то, чего ни в коем случае нельзя было туда пропускать. Многочисленные примеры на сайте worsethanfailure.com должны вас в этом убедить. Организация и периодическое проведение code review вас очень сильно обезопасит от того, что сильно некачественный кусок кода попадет в релиз и будет всем портить жизнь в дальнейшем.
8. Отсутствие системы контроля версий
Про этот пункт даже нечего и говорить. Даже если на проекте работает всего лишь один человек, наличие системы контроля версий невероятно облегчает ему жизнь. Если же работают сразу больше трех людей, то ее отсутствие превращают их жизнь в настоящий ад. Объединение кода, написанного разными людьми без системы контроля версий - просто тихий ужас. Сопровождение более двух версий продукта одновременно - форменный кошмар. Не говоря уже о возможности отката последних изменений. В общем, мне кажется, что здесь лучше не экспериментировать - система контроля версий должна быть - и точка :)
9. Отсутствие системы трекинга ошибок
Если необходимость системы контроля версий часто не вызывает сомнений, то с системой трекинга ошибок все не так радужно. Многим кажется, что и без нее можно обойтись. Только очень быстро такая практика приведет к тому, что одни и те же люди будут находить одни и те же ошибки, тратя время на решение того, что уже решено, некоторые ошибки будут просто теряться, а исправление других ошибок будет забываться тестироваться. И очень просто в такой ситуации полностью потерять контроль над проектом вообще. Скажу лишь, что средний проект, на котором работают 3-5 людей в течении полугода, легко может содержать за время своей жизни до 400 ошибок. И поверьте, что ни один даже самый талантливый менеджер проекта не сможет удержать такое количество информации у себя в голове. Единственная альтернатива - система трекинга ошибок. Must be и никаких разговоров :)
10. Отсутствие простой и эффективной системы учета проделанной работы.
Когда нет простой и прозрачной системы учета, очень сложно отслеживать текущее положение вещей. При этом плохо и когда ее нет совсем, и когда она слишком усложнена и запутана, и для того, чтобы отправить отчет, разработчику приходится проходить квест каждый раз как заново. Хорошо построенная система отчетности не должна вызывать отторжения у программистов, и при этом она должна давать ПМ-у или тим-лиду достаточно информации для трекинга состояния проекта в целом.
Многие могут сказать, что это все выглядит уж слишком просто, чтобы быть правдой. Ведь управление проектами - это ж суперсложная вещь, с кучей умных и непонятных терминов, диаграмм и прочего. Однако это так. Вот эти вот самые простые вещи, правильное их выполнение, могут очень сильно повысить шансы проекта на успех и облегчить ведение всех процессов. И наоборот, игнорирование всех или нескольких пунктов ни к чему хорошему еще никого не приводили...
ЗЫ. И на последок тренинги Секреты эффективной разработки и UML за пять дней!
HTC CDMA Touch Pro
|
