Файл: Роберт мартин.pdf

5
ТЕХНИЧЕСКИЕ МЕТОДЫ

Глава 5. Технические методы
172
Методы этой главы предлагают полный отход от тех, что господ- ствовали среди большинства программистов на протяжении 1970-х годов . Раньше предлагался набор осмысленных ритуалов, проводи- мых периодично — ежеминутно и ежесекундно, которые большин- ство программистов изначально считают чушью . Поэтому многие программисты пробовали применять Agile, исключив эти методы .
Однако у них ничего не получилось, потому что эти методы как раз лежат в основе Agile . Без разработки через тестирование, рефак- торинга, простой структуры проекта и, да-да, даже парного про- граммирования Agile становится бесполезным жалким подобием того, чем должен быть .
РАЗРАБОТКА ЧЕРЕЗ ТЕСТИРОВАНИЕ
Разработка через тестирование — это сложная и глубокая тема для обсуждения, и чтобы ее как следует раскрыть, понадобится целая книга . В этой главе приведен лишь общий обзор, который больше сосредоточен на обосновании и объяснении, чем на глубо- ких технических сторонах метода . В частности, в этой главе вы не найдете никакого кода .
Профессия программиста уникальна . Мы создаем огромные до- кументы, написанные загадочными техническими символами .
Каждый символ такого документа должен быть правильным, иначе может произойти что-то действительно страшное . Один неверный символ повлечет за собой потери больших средств или жизни . Раз- ве есть другие такие профессии?
Бухгалтерский учет . Бухгалтеры также создают огромные до- кументы, исписанные загадочными техническими символами .
Каждый символ такого документа должен быть правильным, в противном случае это может стоить потери больших средств

Разработка через тестирование
173
или жизни . Как бухгалтеры проверяют, чтобы каждый символ был правильным?
Двойная запись
У бухгалтеров есть инструмент, который появился еще тысячу лет назад . Это двойная запись
1
. Каждая операция, которую они проводят, заносится в книгу дважды: один раз как кредит в ак- тивном счете и еще раз, в дополнение, как дебет в пассивном сче- те . Затем эти счета сводят в единый документ, балансовый отчет, где из суммы финансовых активов вычитается сумма долговых обязательств и долей собственников . Бухгалтер должен выйти в ноль . Если в итоге получается не ноль, значит, где-то допущена ошибка
2
Бухгалтеров учат вносить операции по одной за раз и каждый раз формировать баланс после проведения операции . Такой способ позволяет им быстро выявлять ошибки . Они не делают проводок между сверкой баланса, поскольку так будет тяжелее найти ошиб- ки . Этот метод, который называется методом двойной записи, на- столько важен для правильного учета денежных средств, что стал мировым стандартом .
Разработка через тестирование по сути то же самое, только для программистов . Каждое необходимое изменение проходит двой- ную проверку . Сначала под такое изменение пишут тест, затем
1
https://ru.wikipedia.org/wiki/Двойная_запись.
2
Если вы изучали бухгалтерское дело, то, скорее всего, кипите от возмуще- ния . Да, это было грубым упрощением . С другой стороны, я описал раз- работку через тестирование упрощенно, одним абзацем . Программисты, наверное, тоже возмутились .

Глава 5. Технические методы
174
пишут готовый код, который позволяет пройти этот тест . Обе проверки дополняют друг друга, как активные и пассивные счета в бухгалтерском учете . После прохождения двойной проверки получается нулевой результат — ноль тестов провалено .
Программисты, изучающие разработку через тестирование, учатся вносить запись дважды — когда код не проходит специально на- писанный тест и еще раз, когда готовый код проходит тест . Такой способ позволяет им быстро выявлять ошибки . Их учат избегать написания большого количества готового кода и запуска партии тестов, поскольку так тяжело найти ошибки .
Эти две дисциплины, двойная запись в бухгалтерском учете и раз- работка через тестирование, схожи .
И то и другое служит одной цели — предотвращать ошибки в кри- тически важных документах, где каждый символ должен быть пра- вильным . Хотя программирование и стало неотъемлемой частью нашего общества, мы до сих пор не обязали проводить разработку через тестирование на законодательном уровне . Но учитывая то, скольких жизней и средств стоило плохо написанное ПО, может, такой закон не за горами?
Три правила разработки
через тестирование
Разработку через тестирование можно описать тремя простыми правилами .
z
Не пишите готовый код до того, как напишете тест, который не получится пройти из-за нехватки этого кода .

Разработка через тестирование
175
z
Не пишите тестов больше, чем это необходимо для неудачи, — сбой при компиляции также считается неудачей .
z
Не пишите готового кода больше, чем достаточно для прохож- дения теста, который был провален до этого .
Программист с опытом чуть больше нескольких месяцев наверняка посчитает эти правила странноватыми, если не сказать прямо, глу- пыми . Эти правила подразумевают, что цикл программирования длится пять секунд . Программист начинает с написания тестового кода для готового кода, который пока что не написал . Тест не удается скомпилировать почти сразу, потому что есть упоминание частей го- тового кода, которые еще не существуют . Программист должен пере- стать писать тест и начать писать готовый код . Но после нескольких нажатий на клавиши тест, который не получалось скомпилировать, теперь компилируется должным образом . Это заставляет програм- миста вернуться к тесту и дописывать к нему новый код .
Такое колебание между тестовым и готовым кодом составляет всего несколько секунд, и программист ограничен в действиях в рам- ках этого цикла . Программист никак не сможет написать целую функцию, или даже простое выражение с оператором if
, или цикл с while
, не прерывая себя написанием дополняющего тестового кода .
Большинство программистов изначально рассматривают такой подход как нарушение их мыслительного процесса . Это постоянное прерывание, вызванное нашими тремя правилами, не позволяет им должным образом думать во время написания кода . Им мешает ощущение, что три правила разработки через тестирование застав- ляют отвлекаться до невозможности часто .
Однако представьте группу программистов, которые соблюдают эти три правила . Посмотрите на любого из них в любой момент

Глава 5. Технические методы
176
времени . Все, над чем программист работал, запустилось или про- шло соответствующие тесты меньше минуты назад . Неважно, на кого и когда вы посмотрите, у всех все работало меньше минуты назад .
Отладка
Что было бы, если бы минуту назад все всегда работало? Как долго пришлось бы выполнять отладку? Если минуту назад все работало, то почти каждый сбой, с которым вы столкнетесь, произошел не больше минуты назад . Отладка сбоя, который появился только что, зачастую пустяк . И в самом деле использовать отладчик для поиска проблемы, наверное, чересчур .
Вы ловко управляетесь с отладчиком? Помните его горячие клави- ши? Ваша мышечная память позволяет непроизвольно нажимать эти клавиши так, чтобы вводить точки останова, входить в режимы: пошаговый, шаг с заходом в процедуры, шаг с обходом процедур?
При отладке вы чувствуете себя в своей тарелке? Это не тот на-
вык, который желают получить.
Единственный способ научиться хорошо пользоваться отладчи- ком — это проводить много времени за отладкой . А если за отлад- кой проводится много времени, значит, часто попадаются ошибки .
Те, кто практикует разработку через тестирование, плохо умеют пользоваться отладчиками просто в силу их редкого использова- ния . А если пришлось-таки воспользоваться отладчиком, это, как правило, не отнимает у них много времени .
Я хочу сказать, что не даю ложных надежд . Даже лучшие про- граммисты, пользующиеся этим методом, натыкаются на ошибки .
Это все-таки разработка, куда без них . Но частота и тяжесть таких

Разработка через тестирование
177
ошибок значительно снижается, если соблюдать три правила раз- работки через тестирование .
Документация
Вам хоть раз доводилось интегрировать сторонний пакет? Ско- рее всего, он пришел в zip-архиве, в котором были исходники, библиотеки, Java-архивы и тому подобное . Скорее всего, в архиве был и документ PDF, в котором содержались инструкции по ин- теграции . А в конце PDF, наверное, было уродливое приложение с примерами всего кода .
Что вы прочли первым делом, как открыли этот документ? Если вы программист, то промотали в самый низ и прочитали примеры кода, потому что в этом коде вся правда .
При соблюдении трех правил разработки через тестирование на- писанные вами тесты становятся примерами кода для всей про- граммы . Если нужно узнать, как вызвать функцию API, есть тесты, которые вызывают эту функцию всевозможными способами, с уче- том каждого возможного исключения . Если вы желаете узнать, как создать объект, есть тесты, которые создают нужный объект всеми способами, которыми он может быть создан .
Тесты — это один из видов документации, которая описывает те- стируемую программу .
Такая документация написана на языке, который программисты отлично знают . Он совершенно недвусмыслен, настолько форма- лен, что исполняем и не может не синхронизироваться с кодом приложения . Тесты являются отличной документацией для про- граммистов, потому что представляют собой код .

Глава 5. Технические методы
178
Более того, тесты не образуют системы сами по себе . Они знать не знают друг о друге . Между ними нет никаких зависимостей . Каж- дый тест — это небольшой и независимый модуль кода, который описывает поведение только маленькой части всей системы .
Радость
Если вы хоть раз писали тесты после того, как работа выполнена, то согласитесь, что развлечение это так себе . Вообще не прикольно, потому что вы уже знаете, что код работает . Вы уже вручную его протестировали . Скорее всего, вы пишете эти тесты лишь потому, что вам так сказали . Чувствуете себя загруженным рутиной . Скучно .
Когда вы пишете тесты согласно трем правилам разработки через тестирование, это клево . Каждый новый тест — это вызов . Каждое успешное прохождение теста — это маленький праздник . Когда вы следуете трем правилам, ваша работа представляется чередой маленьких вызовов и праздников . Нет чувства неблагодарной ра- боты, вместо этого вы понимаете, что даете жизнь чему-то новому .
Полнота
Но вернемся к тестам, которые выполняют после того, как все уже готово . Кто-то зачем-то обязал вас написать эти тесты, причем вы уже протестировали все вручную и знаете, что все работает .
Вы переходите от теста к тесту, не удивляясь тому, что программа спокойно проходит тесты .
Неизбежно вы дойдете до теста, который будет трудно написать .
Его трудно написать, потому что во время написания кода вы забы- ли о тестируемости, а структура кода такова, что его просто так не протестируешь . Чтобы написать тест к этому коду, надо поменять