[Отзыв] Мартин Р. Идеальный программист
Начну цикл статей, посвященный «отзывам» на книги. Пока писал, вспомнилось как в школе, каждый год после лета нам давали задание писать «отзывы» на книги, прочитанные за каникулы, поэтому и такой заголовок. Рассказывать буду о личном восприятии прочитанных книг, на объективность можете не рассчитывать.
До этой публикации не читал ни одной книги Мартина ( да я слышал про них, но не читал, можно кинуть в меня чем-нибудь за это ).
Стиль
Лично мне очень понравилась стилистика этого автора, возможно мне попался хороший перевод. Пишет легко, и нет ощущения, что читаешь техническую или около техническую литературу, будто взял на выходные или в дорогу книжку, чтобы расслабить мозги. Самое приятное, что информация из книги усваивалась при этом намного быстрее и лучше, чем если бы это было замудреное научное издание.
Содержание
Вкратце: она того стоит. Малая по объему, достаточная по содержанию.
Далее пойду по главам, приведу своё резюме для каждой.
- Профессионализм: автор переборщил про стремление к 100% покрытию тестами, такого просто не бывает и никогда не будет даже близко. Тестирование ради тестирования.
- Как сказать «нет»: наверное знал про это, но почему-то показалось в новинку, интересный разбор диалогов, многие из которых слышал вживую.
- Как сказать «да»: Хорошо сказано данные обещания, и про то, как правильно говорить и чего ожидать от других.
- Написание кода: Одна из самых важных глав в книге. Тут описано многое, и про зону потока и про музыку и про общение. Обязательно к прочтению и причем очень внимательно! Удивило, что автор против не только всяких раздражителей, но и «зоны потока», было немного неожиданно.
- Разработка через тестирование: В данном разделе автор как и следовало ожидать расписывает плюсы TDD. На данный момент, лично я, только учусь применять эту методологию, поэтому сложно сказать насколько она эффективна. В конце, подводя резюме, автор говорит, что даже TDD не панацея от плохого кода и вот тут я с ним согласен.
- Тренировка: Ката, додзе и иже с ними. Есть несколько ссылок на забавные тренировочные упражнения и автор пропагандирует постоянную отточку техники написания. Терпение и труд все перетрут.
- Приемочное тестирование: Приемочные тесты — это по сути метод однозначной валидации требований заказчика. Декларативное описание тестов крутая штука. (Selenium, Cucumber etc.). Также говорится интересная мысль, что можно тестировать интерфейс, удобно при этом устанавливать уникальный идентификатор кнопкам и затем вызывать их при тестировании.
- Стратегии тестирования. Всем, кто не знает различия между интеграционными, приемочными модульными и еще какими-нибудь тестами сюда. Все подробно расписано: зачем, кто такие, кому и когда писать. Еще одна умная фраза — «QA не должен находить дефекты». Очень часто путают задачу тестировщиков, они должны не просто тестировать, а именно следить за качеством продукта.
- Планирование: Рассказ про GTD и управление своим временем. Стоимость встреч($200) и отвлечения, как относиться к спорам и альтернативным решениям. Умная мысль — дешевле решить проблему сейчас, иначе потом она будет стоить дороже.
- Оценки: Бизнес воспринимает оценку как обязательство, разработчик воспринимает как предположение. Оценка — не число, а распределение. В идеале их должно быть 3: O — оптимистичная, N — нормальная, P — пессимистичная. Оптимистичная — это положительный исход, вероятность наступления которого меньше 1%, нормальная — это действительная оценка, которая скорее всего будет истиной, пессимистичный вариант показывает отрицательный исход, вероятность наступления которого меньше 1%. Автор вскользь упоминает несколько видов оценок, которые действительно применялись или применяются в некоторых компаниях. Широкополосный дельфийский метод — для больших корпораций, метод быстрого голосования — для компаний среднего размера. Профессионал не даёт обязательств по срокам, он дает вероятностную оценку.
- Под давлением: Сказ про стрессовые ситуации и поведение профессионального разработчика.
- Избежать давление = избежать ситуаций создающих давление.
- Если руководство обещает заказчику что-то, не посоветовавшись с разработчиком по срокам, то разработчик не несет ответственности за срыв сроков(вот это очень сложно прочувствовать и понять).
- Сохранять чистоту в коде, как бы быстро не требовалось писать
- Обратить внимание на приемы и методы, используемые в критических ситуациях, именно в них ты и веришь(вот это интересно, надо будет попробовать)
- Сохраняй спокойствие в сложных ситуациях и обращайся за помощью
- Сотрудничество:
- профессионал заботится об интересах работодателя
- понимать зачем пишется твой код
- проф. программист обращает внимание на корабль на котором плывет
- 3 строчки про сотрудничество «программист и программисты» — порадовало
- если ты работаешь эффективно, не факт, что вся группа эффективно
- если вы хотите заниматься программированием придется научиться общаться
- Группы и проекты:
- половины человека не бывает ( чем меньше дергаем на разные проекты, тем лучше)
- оптимальная притертая группа разработки — 12 человек
- «притертой» группе можно давать несколько проектов
- создать хорошую команду сложнее чем создать проект
- Наставники, ученики и мастерство: тут ничего нового, учиться надо у людей и у учебников, у каждого вида свои плюсы и минусы. Учиться надо везде, для полноценного познания всего и вся требуется наставник. Профессионализм заразителен, если вы видите его у кого, за ним хочется повторять, стремитесь быть таким специалистом, за которым хочется повторять.
Приложение А. Инструментарий: Использует передовые технологии, Jenkins, Pivotal Tracker и т. д.
Подводя итог: книжку можно осилить за пару вечеров дома, за поездку в поезде или за выходные на диване. Она стоит того, чтобы её прочитать, некоторые мысли были для меня в новинку, на некоторые вещи взглянул чуть под другим углом, но в основном все это знал и так. Книга просто помогает немного структурировать знания и выработать подход. Ну и ссылка для тех, кто изъявит желание почитать:
 | Книга "Идеальный программист. Как стать профессионалом разработки ПО" Роберт Мартин - The Clean Coder: A Code of Conduct for Professional Programmers ISBN 978-5-459-01044-2 |