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

Выбор профессионалов
Из всего сказанного следует, что TDD – выбор профессионалов.
Эта методология повышает уверенность, придает смелости
разработчикам, 
снижает 
количество 
дефектов, 
формирует
документацию и улучшает архитектуру. При таком количестве доводов
в пользу TDD отказ от использования этой методологии можно
считать проявлением непрофессионализма.
Чем TDD не является
При всех своих достоинствах TDD – не религия и не панацея.
Выполнение трех законов не гарантирует ни одного из перечисленных
преимуществ. Плохой код можно написать даже при предварительном
написании тестов. Да и сами тесты тоже могут быть написаны плохо.
В некоторых ситуациях три закона оказываются просто
непрактичными или неподходящими. Такие ситуации встречаются
редко, но они все же возможны. Ни один профессиональный
разработчик не станет применять методологию, которая в конкретной
ситуации приносит больше вреда, чем пользы.

---

6
Тренировка
Все профессионалы оттачивают свое мастерство на специальных
упражнениях. Музыканты играют гаммы. Доктора тренируются в
наложении швов и выполнении других хирургических приемов.
Адвокаты репетируют речи. Солдаты участвуют в учениях.
Профессионалы тренируются везде, где важна эффективность
выполнения работы. Эта глава полностью посвящена возможности
тренировки навыков программирования.
Азы тренировки
Концепция тренировки в программировании появилась довольно
давно, но собственно тренировкой она была признана лишь в начале
нового тысячелетия. Вероятно, первый формальный пример
тренировочной программы был напечатан на странице 6 учебника
Кернигана—Ричи.
[24]
main()
{
printf("hello, world\n");

---

}
Кто из нас не писал эту программу в той или иной форме? Мы
используем ее для того, чтобы опробовать новую среду
программирования или новый язык. Когда мы пишем и выполняем эту
программу, это доказывает, что мы точно так же можем написать и
откомпилировать любую другую программу.
Когда я был намного моложе, освоение нового компьютера обычно
начиналось для меня с написания программы SQINT, вычисляющей
квадраты целых чисел. Я писал ее на ассемблере, BASIC, FORTRAN,
COBOL и множестве других языков. Все эти многочисленные версии
одной программы также доказывали, что я могу заставить компьютер
сделать то, что мне нужно.
Первые персональные компьютеры появились в магазинах в начале
1980-х годов. Каждый раз, когда мне представлялась возможность
поработать за одним из них (VIC-20, Commodore-64 или TRS-80), я
писал небольшую программу для вывода бесконечного потока
символов \' и /'. Рисунки, которые строились такими программами,
радовали глаз и выглядели намного сложнее маленькой программы,
которая их строила.
И хотя эти программы были чисто учебными, программисты в
целом не тренировались. Откровенно говоря, нам это просто не
приходило в голову. Мы были слишком заняты написанием кода, чтобы
думать о совершенствовании мастерства. Да и зачем? В те годы
программирование не требовало хорошей реакции или проворных
пальцев. Первые экранные редакторы появились только в конце 1970-х
годов. Большая часть нашего рабочего времени проходила за
ожиданием компиляции или отладкой длинных, безобразных потоков
кода. Короткие циклы TDD еще не были изобретены, поэтому те
нетривиальные возможности, которые открываются благодаря
тренировке, были попросту не нужны.