Идеальный программист. Как стать профессионалом разработки по

Стоп-сигнал
Очень важно, чтобы тесты непрерывной интеграции все время
проходили успешно. Они никогда не должны завершаться отказом. В
случае отказа вся группа прекращает заниматься текущими делами и

---

направляет все усилия на то, чтобы обеспечить успешное прохождение
всех тестов. Сборка в системе с непрерывной интеграцией должна
рассматриваться как экстренное событие, своего рода «стоп-сигнал».
Я общался с группами, которые недостаточно серьезно относились
к отказам в тестах. Такие группы обычно были «слишком заняты»,
чтобы решать проблему немедленно, поэтому тесты откладывались в
сторону до лучших времен. В одном случае нерабочие тесты были
попросту исключены из сборки, потому что программистов
раздражали сообщения об отказах. Позднее, уже после сдачи продукта
заказчику, они вдруг вспомнили, что забыли вернуть тесты в сборку.
Это выяснилось уже после того, как разгневанный заказчик забросал
их сообщениями об ошибках.
Заключение
Передать информацию о подробностях сложно. Это в полной мере
относится к программистам и ключевым участникам проекта,
обсуждающим подробности приложения. Слишком легко каждой из
сторон махнуть рукой и считать, что другая сторона ее понимает.
Слишком часто стороны соглашаются с тем, что они поняли друг
друга, и расходятся с совершенно разными убеждениями.
Мне известен только один способ эффективного исключения
коммуникационных ошибок в общении программистов с ключевыми
участниками проектов – написание автоматизированных приемочных
тестов. Эти тесты формализованы, полностью однозначны и всегда
остаются синхронизированными с приложением. Они являются
идеальным документом, определяющим требования к проекту.

---

8
Стратегии тестирования
Профессиональные разработчики тестируют свой код. Однако
тестирование не сводится к написанию нескольких модульных или
приемочных тестов. Написание этих тестов – дело полезное, но
отнюдь 
не 
достаточное. 
Любой 
группе 
профессиональных
разработчиков нужна хорошая 
стратегия тестирования
.
В 1989 году я работал над первой версией Rational Rose. Каждый
месяц или около того начальник службы контроля качества объявлял
день «охоты за ошибками». Все участники проекта, от программистов
до начальников, от секретарей до администраторов баз данных,
садились за Rose и пытались вызвать сбой в программе. За разные
типы ошибок присуждались призы. Ошибка, приводящая к аварийному
завершению приложения, могла быть награждена обедом для двоих.
Тот, кто обнаруживал больше всего ошибок, мог выиграть поездку на
выходные в Монтеррей.