Глава 9. Обратно к истокам

We use cookies. Read the Privacy and Cookie Policy

Глава 9.

Обратно к истокам

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

Рассказ об управлении автомобилем. Четыре ценности – коммуникация, простота, обратная связь и храбрость. Двойной набор принципов. Теперь мы готовы приступить к формированию дисциплины разработки программного обеспечения. Вначале надо определить круг решаемых нами проблем. К какой области будут относиться наши предписания? Решением проблем какого сорта мы будем заниматься? Проблемы какого сорта будут игнорироваться нами?

Я вспоминаю, как я впервые научился программировать на BASIC. У меня была пара книг, в которых описывались основы программирования. Я достаточно быстро прочитал их и, когда я закончил, решил приступить к решению проблемы, которая была несколько сложнее, чем примитивные примеры, рассматривавшиеся в этих книгах. Я решил написать игру Star Trek (Звездный путь), похожую на ту, в которую я играл в Lawrence Hall of Science в университете Berkeley, только моя версия должна была бы стать круче.

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

Я чувствовал, что надо сделать что-то еще помимо программирования, но я не знал, что именно.

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

Кодирование

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

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

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

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

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

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

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

Тестирование

Английские философы-позитивисты Лок (Locke), Беркли (Berkeley) и Хьюм (Hume) утверждают, что все, чего нельзя измерить, на самом деле не существует. Если речь заходит о коде, я с ними полностью согласен. Возможности программного продукта, которые нельзя продемонстрировать с использованием тестов, просто не существуют. Я запросто могу обмануть самого себя, убедив себя в том, что то, что я написал, есть то, что я имел в виду. Я также вполне могу обмануть себя в том, что то, что я имел в виду, является тем, что я должен был иметь в виду. Поэтому я не должен верить ничему, что я написал до тех пор, пока я не напишу для этого тесты. Тесты позволяют мне думать о том, что я хочу, вне зависимости от того, как это реализовано. Если я что-либо реализовал, тесты сообщают мне о моем представлении о том, что я реализовал.

Многие люди думают об автоматических тестах в контексте тестирования функциональности – то есть вычисления чисел. Чем более опытным я становлюсь в деле написания тестов, тем яснее для меня становится, что я могу разрабатывать тесты для тестирования нефункциональных требований, например для тестирования производительности, или соответствия некоторым стандартам кодирования.

Эрих Гамма (Erich Gamma) придумал термин инфицированный тестами (Test Infected) для описания людей, которые не приступают к кодированию до тех пор, пока у них не будет набор тестов для проверки разрабатываемого кода. Тесты сообщают вам о том, что ваша работа завершена, – когда все тесты сработали, считайте, что на данный момент кодирование успешно завершено. Когда вы больше не можете придумать ни одного теста, можете считать, что вы завершили работу.

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

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

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

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

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

Я помню, как я занимался этим на публичной программистской демонстрации. Каждый раз, когда я отворачивался от аудитории, чтобы продолжить программирование, я машинально щелкал на кнопке тестирования. Я не менял никакого кода. Абсолютно все в рабочей среде оставалось неизменным. Зачем же я раз за разом щелкал на тестирующей кнопке? Я всего лишь хотел получить заряд уверенности. Когда я в очередной раз видел, что все тесты по-прежнему срабатывают и ничего в системе не нарушено, я получал такой заряд!

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

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

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

Заглядывая вперед, отмечу, что в дальнейшем разговор пойдет о двух наборах тестов. Тесты модулей (unit tests) разрабатываются программистами для того, чтобы убедиться в корректной работе разрабатываемого ими кода. Функциональные тесты (functional tests) разрабатываются (или по крайней мере специфицируются) заказчиками для того, чтобы убедиться в том, что система как единое целое работает именно так, как она должна работать.

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

Слушание

Программисты ничего не знают. Говоря точнее, программисты не знают ничего такого, что является интересным для бизнесменов. Если бы бизнесмены могли обойтись без программистов, они бы вышвырнули нас вон в одну секунду.

К чему я веду? Если вы решили тестировать, вы должны получить откуда-либо ожидаемые ответы. Так как вы (программист) ничего не знаете, вы должны спросить у кого-то еще. Они сообщат вам, какие ответы являются ожидаемыми и какие случаи являются необычными с точки зрения бизнеса.

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

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

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

Проектирование

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

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

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

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

Таким образом, последним родом деятельности, который мы должны структурировать в рамках разрабатываемой нами новой дисциплины, – это проектирование, или, по-другому, формирование дизайна. Мы должны сформировать контекст, в рамках которого создается только хороший дизайн, а плохой дизайн исправляется. Кроме того, в рамках этого контекста о текущем дизайне системы знает каждый, кому это необходимо.

Как будет показано в последующих главах, методы формирования дизайна в ХР существенно отличаются от методов, традиционно используемых в рамках многих других дисциплин разработки программного обеспечения. В рамках ХР проектирование является частью ежедневной работы каждого из программистов. Программисты ХР занимаются проектированием прямо в процессе кодирования. Однако вне зависимости от стратегии, которая используется для получения хорошего дизайна, в процессе разработки программного продукта проектирование не выполняется по желанию. Это неотъемлемая часть любого программного проекта, и для того, чтобы сделать разработку программы эффективной, вы должны уделить проектированию очень серьезное внимание.

Заключение

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

• кодирование;

• тестирование;

• слушание;

• проектирование.

Данный текст является ознакомительным фрагментом.