Обучение - видеокурсы, видеоуроки и обучающие тренинги!

Статьи

Главная » Статьи » WEB дизайн

Десять самых распространенных проблем в ИТ разработке
Десять самых распространенных проблем в ИТ разработке


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



Пост-
Категория: WEB дизайн | Добавил: romanww (11.07.2010)
Просмотров: 2531
Воскресенье, 25.09.2022, 20:14
Приветствую Вас Гость

Форма входа

Логин:
Пароль:

Поиск

Категории

Liex.ru [105]
3D моделирование [0]
Автолюбителям [0]
Бизнес в интернет [96]
Бизнес, Менеджмент, Реклама [3]
Для дома и сада [2]
Иностранные языки [9]
Компьютеры [14]
Любовь,отношения [24]
Музыка, Звук [1]
Обработка изображений,фото [24]
Обучение,экзамены [10]
Программирование [0]
Психология,мотивация [54]
Работа с видео [11]
Развлечения [2]
Своими руками [5]
Создание сайтов [64]
Спорт,здоровье,красота [33]
Разное [3]
Скрипты, Сервисы [0]
Финансы [20]
Электронные платежи [2]
Forex, Инвестиции [6]
WEB дизайн [2]

Друзья сайта

  • Рекомендую

    Инфобизнес

    Финансы

    Как вырваться из замкнутого круга финансовых проблем

    Статистика


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0

    Яндекс.Метрика Рейтинг@Mail.ru