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

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

Программист, как и мастер боевых искусств, должен знать разные ката и регулярно тренировать их, чтобы они не стерлись из памяти. Описания многих ката находятся по адресам http://katas.softwarecraftsmanship.org и http://codekata.pragprog.com. Некоторые из моих любимых ката: • Игра в кегли: http://butunclebob.com/ArticleS.UncleBob.TheBowling-GameKata • Простые числа: http://butunclebob.com/ArticleS.UncleBob.ThePrime-Factors-Kata • Перенос текста: http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html

Далее приводится минимальный список тем, в которых должен разбираться каждый разработчик. • Паттерны проектирования. Вы должны быть способны описать все 24 паттерна из книги «Банды Четырех» и иметь практическое представление о многих паттернах из книг «Pattern-Oriented Software Architecture». • Принципы проектирования. Вы должны знать принципы SOLID и хорошо разбираться в принципах компонентного проектирования.

Как можно называть себя профессионалом, если вы не знаете, что весь ваш код работает? А как можно знать, что весь ваш код работает, если вы не тестируете его при каждом внесении изменений? А как тестировать код при каждом внесении изменений, не имея автоматизированных модульных тестов с очень высоким покрытием? Но можно ли создать автоматизированные модульные тесты с очень высоким покрытием без применения TDD? Впр

Преданность делу и профессионализм проявляются в дисциплине, а не в продолжительности работы.

При оценке задачи предоставляются три числа (так называемый анализ по трем переменным):

Контроль качества не должен находить дефекты

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

Одним из самых распространенных аспектов общения между программистами и бизнесом является разработка требований. Бизнесмены описывают то, что по их мнению им нужно, а программисты создают то, что по их мнению им описали.

//butunclebob.com/ArticleS.UncleBob.TheBowling-GameKata • Простые числа: http://butunclebob.com/ArticleS.UncleBob.ThePrime-Factors-Kata • Перенос текста: http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html