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

Если вы пишете приложение для туристической фирмы, вы должны разбираться в туризме. Быть экспертом не обязательно, но к изучению темы необходимо относиться ответственно. Начиная проект в новой для себя области, прочитайте одну-две книги по теме. Проведите собеседование с клиентом и пользователями об основах предметной области. Поговорите с экспертами, постарайтесь понять их принципы и ценности.

Второй лучший способ чему-то научиться – совместная работа с другими людьми.

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

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

если вы хотите, чтобы ваш код был гибким, его необходимо проверять на гибкость! Как убедиться в том, что в ваш продукт легко вносятся изменения? Только одним способом – попытаться внести в него изменения!

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

но за все недочеты несете ответственность именно вы, и никто другой.

Программный код слишком сложен, и ошибки будут всегда. К сожалению, это не избавляет вас от ответственности. Человеческое тело слишком сложно, чтобы изучить его от начала и до конца, но врачи все равно клянутся не причинять вреда. И если уж они не пытаются уйти от ответственности, то с какой стати это может быть позволено нам? «Хотите сказать, что мы должны писать совершенный код?» Нет, я хочу сказать, что вы должны отвечать за свое несовершенство. Тот факт, что в вашем коде заведомо будут присутствовать ошибки, не означает, что вы не несете за них ответственность. Написать идеальную программу практически невозможно

Выделяйте не более 20 минут на ретроспективу и 25 минут на демонстрацию. Не забудьте, что прошли всего одна-две недели, так что материала для обсуждения не так уж много.

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