"Идеальный программист" Роберт С. Мартин

Прочитал эту книгу, 90% книги автор расхваливал методологию разработки через тестирования(TDD). Ничего не могу написать про эту книгу, как по мне, так она не стоит такого внимания, которое ей оказывают. 90% книги просто ни о чем. Возможно просто я уже столкнулся с большинством проблем и поэтому знаю как их решать.

Т.к. я не испытал никаких особенных чувств при чтении этой книги, то перейдем к основным моментам из нее:

Безжалостный рефакторинг. "Всегда оставляйте модуль чище, чем чем до вашего прихода". Автор говорит о том, что если вы взялись за работу над каким-то модулем, то необходимо сразу там навести порядок и сделать мини рефакторинг. Таким образом не будет неизвестности кода и боязни его изменения. По мнению писателя боязнь изменения кода говорит о том, что никто не знает как эта система работает и поддерживать ее очень трудно.
Работодатель не обязан выделять вам время на обучение. Распланируйте свою рабочую неделю на 60 часов. 40 для основной работы и 20 для дополнительного обучения новым технологиям.
Минимальный список, в чем должен разбираться каждый разработчик: 1) Методы разработки(scrum, cascade и тд). 2) Дисциплины (практиковаться разные виды программирования, разработки и проектирования). 3) Уметь работать с различными диаграммами (DFD, UML). 4)
Нельзя говорить слово "попытаюсь", если вы обещаете попытаться, человек воспринимает эту фразу "я сделаю", таким образом вы берете на себя обязательство. Необходимо приходить к компромиссу между сторонами и не брать на себя невыполнимых обязательств и нести за них ответственность
Три закона TDD: 1) Новый рабочий код пишется только после того, как будет написан модульный тест, который не проходит. 2) Вы пишите ровно такой объем кода модульного теста, который необходим для того, чтобы этот тест не проходил. 3) Вы пишете ровно такой объем рабочего кода, какой необходим для прохождения модульного теста, который в данный момент не проходит.
Никогда нельзя выбирать пассивно-агрессивную позицию: "я же говорил".