Роберт Мартин - Чистый Agile. Основы гибкости

Двойная запись

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

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

Разработка через тестирование по сути то же самое, только для программистов. Каждое необходимое изменение проходит двойную проверку. Сначала под такое изменение пишут тест, затем пишут готовый код, который позволяет пройти этот тест. Обе проверки дополняют друг друга, как активные и пассивные счета в бухгалтерском учете. После прохождения двойной проверки получается нулевой результат — ноль тестов провалено.

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

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

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

Три правила разработки через тестирование

Разработку через тестирование можно описать тремя простыми правилами.

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

• Не пишите тестов больше, чем это необходимо для неудачи, — сбой при компиляции также считается неудачей.

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

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

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

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

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

Отладка

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

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

Единственный способ научиться хорошо пользоваться отладчиком — это проводить много времени за отладкой. А если за отладкой проводится много времени, значит, часто попадаются ошибки. Те, кто практикует разработку через тестирование, плохо умеют пользоваться отладчиками просто в силу их редкого использования. А если пришлось-таки воспользоваться отладчиком, это, как правило, не отнимает у них много времени.

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

Документация

Вам хоть раз доводилось интегрировать сторонний пакет? Скорее всего, он пришел в zip-архиве, в котором были исходники, библиотеки, Java-архивы и тому подобное. Скорее всего, в архиве был и документ PDF, в котором содержались инструкции по интеграции. А в конце PDF, наверное, было уродливое приложение с примерами всего кода.

Что вы прочли первым делом, как открыли этот документ? Если вы программист, то промотали в самый низ и прочитали примеры кода, потому что в этом коде вся правда.

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