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

По оценке Питера 4,2/1,8 Майк понимает, что задача, скорее всего, будет завершена за пять дней, но также может занять 6 и даже 9 дней.

Дисциплины. Практикуйтесь в практическом применении разработки через тестирование (TDD), объектно-ориентированного проектирования, структурного программирования, непрерывной интеграции и парного программирования. • Артефакты. Вы должны уметь работать с UML, DFD, структурными диаграммами, сетями Петри, диаграммами переходов, блок-схемами и таблицами решений.

• Паттерны проектирования. Вы должны быть способны описать все 24 паттерна из книги «Банды Четырех» и иметь практическое представление о многих паттернах из книг «Pattern-Oriented Software Architecture». • Принципы проектирования. Вы должны знать принципы SOLID и хорошо разбираться в принципах компонентного проектирования. • Методы. Вы должны понимать суть методологий XP, Scrum, экономной[6] разработки (Lean), Kanban, каскадной разработки, структурного анализа и структурного проектирования. • Дисциплины. Практикуйтесь в практическом применении разработки через тестирование (TDD), объектно-ориентированного проектирования, структурного программирования, непрерывной интеграции и парного программирования. • Артефакты. Вы должны уметь работать с UML, DFD, структурными диаграммами, сетями Петри, диаграммами переходов, блок-схемами

Модульные и приемочные тесты прежде всего являются документами и лишь потом – тестами. Их главная цель – формальное документирование архитектуры, структуры и поведения системы.

Ваша задача как профессионального разработчика – обсудить ситуацию с автором теста для его улучшения. Никогда не выбирайте пассивно-агрессивную позицию, когда вы говорите себе: «Как написано в тесте, так я и сделаю».

Том Демарко сказал: «неоднозначность в документе с требованиями появляется из-за разногласий между участниками[34]».

Профессиональные разработчики не формулируют требования до того, как будут готовы к разработке.

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

И бизнесмены, и программисты часто попадают в ловушку преждевременной точности.

В конечном итоге чем точнее формулируете свои требования, тем быстрее они теряют актуальность в ходе реализации системы.