Б. Личностные качества программиста

Такие, как халатность, невнимательность и лень.

В. Отсутствие опыта

Программист может просто не знать, как нужно сделать пра­вильно.

Г. Пренебрежение стандартами кодирования

О стандартах чуть позже.

Д. Сложность системы

Современные интернет-проекты отличаются такой сложностью, что мозг простого смертного порой просто не в состоянии про­анализировать все последствия создания/изменения/удаления кода и предугадать появление проблемы.

е. Баги в ПО третьих лиц, т.е. баги

• в операционных системах;

• в компайлерах (compiler — ПО для переведения (напри­мер, C++) кода в машинный язык и создания исполняе­мых файлов);

• в веб-серверах;

• в базах данных и др.

Цикл разработки ПО 89

Ж. Отсутствие юнит-тестирования,

хт.е. тестирования кода самим программистом: "И вообще, почему я должен искать баги в своем коде, когда есть тестировщики?" (Поговорим о юнит-тестировании через минуту.)

З. Нереально короткие сроки для разработки

Об этом мы тоже скоро поговорим.

Возможности оздоровления кода и превентирования багов до передачи кода тестировщикам (иллюстрации последуют не­медленно) включают:

1. Наличие требований к содержанию спеков и следова­ние правилам их изменения;

2. Возможность прямой, быстрой и эффективной комму­никации между программистами и программистами и продюсерами;

Инспекции кода;

Стандарты программирования;

Реальные сроки;

Доступность документации;

7. Требования к проведению юнит-тестирования (о кото­ром мы поговорим уже через 30 секунд);

8. Реальные финансовые рычаги стимуляции написания эффективного и "чистого" кода;

9. Наличие понятий "качество" и "счастье пользователя" как основных составляющих корпоративной философии.

Подробности.

1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ
И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ

О спеках мы уже говорили.

2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ
КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ

И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ

Здесь есть следующие аспекты:

А. Психологические аспекты

Очень важно привить в культуру компании следующее правило: "Если к тебе обратились — помоги".

Тестирование Дот Ком. Часть 1

Пример

Программист приходит к продюсеру с просьбой объяснить некую часть спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра, добро?"

Очень часто после пары "давай завтра" программист что делает? Пра­вильно! Он пишет код так, как его понимает, — без всякой гарантии, что сей код отразит требуемое.

Следующий аспект:

программист (как и все остальные участники цикла) никогда не должен стесняться спрашивать (хоть двести раз!) и подтверждать свое понимание е-мейлами типа: "Просто хотел уточнить, что я правильно понял, что пункт 12.2 такого-то спека говорит..." Если же программисту не отвечают, когда он подходит, прекрасно — нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я хотел уточнить". Если снова не отвечают, программист должен идти к своему менеджеру и просить его принять меры. И это не стукачество, а деловая практика — business is business.

Следующий аспект:

Менеджмент должен регулярно устраивать так называемые Team Building Activities (мероприятия по сплочению коллектива) с той простой целью, чтобы между членами команды кроме профес­сиональных налаживались и человеческие контакты. Причем, как показывает опыт, совместный выезд для игры в пейнтбол раз в месяц гораздо эффективнее для сплочения коллектива, чем со­вместная проспиртовка мозгов во время пятничных застолий.

Дата добавления: 2015-12-07