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

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

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

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

«Но я могу написать тесты позднее», скажете вы. Нет, не можете. Конечно, некоторые тесты можно написать позднее. Можно даже обеспечить высокое покрытие, если вы проследите за его измерением. Однако тесты, написанные позднее, лишь защищают от ошибок – тогда как тесты, написанные с опережением, их активно атакуют . Тесты, написанные позднее, пишутся разработчиком, который уже сформировал код и знает, как решалась задача. Такие тесты никак не сравнятся по полноте и актуальности с тестами, написанными заранее.

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

При всех своих достоинствах TDD – не религия и не панацея. Выполнение трех законов не гарантирует ни одного из перечисленных преимуществ. Плохой код можно написать даже при предварительном написании тестов. Да и сами тесты тоже могут быть написаны плохо.

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

Все профессионалы оттачивают свое мастерство на специальных упражнениях. Музыканты играют гаммы. Доктора тренируются в наложении швов и выполнении других хирургических приемов. Адвокаты репетируют речи. Солдаты участвуют в учениях. Профессионалы тренируются везде, где важна эффективность выполнения работы. Эта глава полностью посвящена возможности тренировки навыков программирования.

Концепция тренировки в программировании появилась довольно давно, но собственно тренировкой она была признана лишь в начале нового тысячелетия. Вероятно, первый формальный пример тренировочной программы был напечатан на странице 6 учебника Кернигана—Ричи. [24]

main()

{

printf("hello, world\n");

}

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

Когда я был намного моложе, освоение нового компьютера обычно начиналось для меня с написания программы SQINT, вычисляющей квадраты целых чисел. Я писал ее на ассемблере, BASIC, FORTRAN, COBOL и множестве других языков. Все эти многочисленные версии одной программы также доказывали, что я могу заставить компьютер сделать то, что мне нужно.

Первые персональные компьютеры появились в магазинах в начале 1980-х годов. Каждый раз, когда мне представлялась возможность поработать за одним из них (VIC-20, Commodore-64 или TRS-80), я писал небольшую программу для вывода бесконечного потока символов \' и /'. Рисунки, которые строились такими программами, радовали глаз и выглядели намного сложнее маленькой программы, которая их строила.

И хотя эти программы были чисто учебными, программисты в целом не тренировались. Откровенно говоря, нам это просто не приходило в голову. Мы были слишком заняты написанием кода, чтобы думать о совершенствовании мастерства. Да и зачем? В те годы программирование не требовало хорошей реакции или проворных пальцев. Первые экранные редакторы появились только в конце 1970-х годов. Большая часть нашего рабочего времени проходила за ожиданием компиляции или отладкой длинных, безобразных потоков кода. Короткие циклы TDD еще не были изобретены, поэтому те нетривиальные возможности, которые открываются благодаря тренировке, были попросту не нужны.

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

Одной из первых машин, для которых я программировал, была PDP-8/I. Компьютер имел тактовую частоту 1,5 мс и 4096 12-разрядных слов основной памяти, был размером с холодильник и потреблял значительную мощность. Его дисковый накопитель позволял хранить 32K 12-разрядных слов, а взаимодействие с оператором осуществлялось через телетайп со скоростью передачи 10 символов в секунду. Нам казалось, что это очень мощная машина, на которой можно творить чудеса.

Недавно я купил новый ноутбук Macbook Pro. Он оснащен двухъядерным процессором 2,8 ГГц, 8 Гбайт памяти, 512-гигабайтным SSD-накопителем и 17-дюймовым ЖК-экраном с разрешением 1920× 1200. Я ношу его в рюкзаке. Он легко умещается у меня на коленях и потребляет менее 85 ватт.

По сравнению с PDP-8/I мой ноутбук работает в восемь тысяч раз быстрее, имеет в два миллиона раз больше памяти, в шестнадцать миллионов раз большую емкость запоминающего устройства, потребляет 1 % мощности, занимает 1 % места и стоит в 25 раз меньше. Посчитаем:

8000 × 2000 000 × 16 000 000 × 100 × 100 × 25 = 6,4 × 10 22.

Это очень большое число. Разница составляет 22 порядка ! Это расстояние в ангстремах от нас до альфы Центавра; количество электронов в серебряном долларе; масса Земли в Майклах Мурах – словом, большое, очень большое число. И теперь такой компьютер стоит у меня на коленях – и вероятно, на ваших тоже!

И что я делаю с этой мощью, возросшей на 10 в 22 степени? Примерно то же, что я делал на PDP-8/I. Я пишу команды if, циклы while и команды присваивания.

О, инструменты для написания этих команд заметно улучшились, и языки стали более мощными. Но сама природа команд за это время не изменилась. Код 2010 года будет понятен программисту из 1960-х годов. Глина, из которой мы лепим свои программы, не изменилась за четыре десятилетия.