Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о методах, ценностях и принципах XP в книге Кента Бека и Синтии Андрес Extreme Programming Explained: Embrace Change (Addison-Wesley, 2004).
• Узнайте больше о модульном тестировании и разработке через тестирование в книге Энди Ханта и Дэйва Томаса Pragmatic Unit Testing (Pragmatic Bookshelf: Java version 2003, C# version 2007).
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Это один из самых сложных аспектов agile-коучинга, особенно для agile-тренеров, которые не имеют опыта программирования. Сосредоточьтесь на ХР-ценностях и принципах и помогите команде выяснить, как они влияют на код.
• Команде легко потерять мужество и уважение. Помогите найти примеры, когда они колебались, сообщать ли кому-то вне команды реальное состояние качества кода. Например, подправляла ли команда когда-нибудь демоверсию, чтобы обойти известные ей ошибки. Меняла ли она отчет об ошибке, чтобы та казалась менее серьезной, чем на самом деле? Помогите ей найти способы, чтобы было легче делиться такой информацией.
• Как найти лучшие возможности для коммуникации команды? Помогите ей создать информационное табло.
Глава 7. ХР, простота и инкрементальная архитектура
Я не великий программист, я просто хороший программист с замечательными привычками.
Цели XP выходят за рамки простого стремления научить команду работать лучше. Масштабная цель XP-практик, ценностей и принципов – помочь командам создавать программное обеспечение, которое можно легко изменять и расширять, а также работать, планировать и расти вместе в среде, легко принимающей изменения.
Внедрение ХР означает больше, чем просто использование парного программирования для постоянной проверки кода или разработки через тестирование для увеличения тестового покрытия. Повышение качества и улучшение отношений с коллегами – это замечательные побочные эффекты XP, и они помогают достичь основной цели. Эти практики изменяют технологию создания ПО, но не вносят кардинальных изменений в его проектирование.
Повторим еще раз: важная цель XP – это программное обеспечение, которое может быть легко изменено. Команды примут изменения охотнее, если создаваемый ими программный продукт несложно изменять. Это оказывает глубокое влияние на подход хорошей XP-команды к разработке и проектированию программ.
Здесь также следует отметить один из ключевых моментов приобретения правильного ХР-мышления: искреннюю веру в то, что практики, изученные в главе 6, такие как разработка через тестирование, парное программирование и временной запас, помогают вам и вашей команде изменить подход к разработке ПО. Игнорирование этих практик может привести к созданию некачественного, трудно изменяемого исходного кода.
В этой главе вы узнаете, как талантливые программисты иногда все же создают код с серьезными проблемами в нем самом и архитектуре. Вы изучите три оставшихся основных XP-практики и то, как они помогают избегать упомянутых проблем. Вы узнаете о многих замечательных привычках, которые появляются у членов ХР-команд (подобных той, о которой говорится в цитате Кента Бека в начале главы). Мы также расскажем, как все XP-практики формируют экосистему, в которой создается лучший, легкий в обслуживании, гибкий и изменяемый код.
Джастин – первый разработчик
Даниэль – второй разработчик
Бриджит – их менеджер проекта
Акт IV. Работа в сверхурочное время, часть 2: снова сверхурочные
Джастин обычно старался уходить из офиса с таким расчетом, чтобы успеть к поезду, отходящему в 17:42. Почему-то это случалось редко. Сегодняшний день не стал исключением. Поздним уходам всегда предшествовала одна и та же ситуация: примерно за час до окончания рабочего дня он приступал к исправлению небольшой ошибки или внесению незначительной настройки. Но маленькие изменения непонятным образом превращались в большую работу.
Это всегда происходило по одной и той же схеме. Внеся запланированное изменение, Джастин обнаруживал, что необходимо подправить и другую часть кода. Он шел дальше и вносил второе изменение. Но это вмешательство влекло за собой необходимость корректировать третью и четвертую части кода. Одно из этих изменений могло, в свою очередь, потребовать, чтобы он перешел к еще одной части исходного кода и т. д. Иногда, к тому времени, когда он заканчивал вносить цепочку исправлений, он уже забывал, зачем делалась первая правка.
Однажды изменения оказались такими кардинальными, что он просто не мог их внести. Он поговорил с Даниэль и Бриджит, и они решили, что требуемые изменения были настолько рискованными, что могли дестабилизировать код. Ситуация оказалась деморализующей: была потрачена масса времени на внесение изменений, а потом все пришлось возвращать в исходное состояние.
Сегодняшний вечер ничем не отличался от предыдущих и развивался по обычной схеме: изменения вызывали изменения. Джастин вспомнил, как говорил Даниэль: «Я обещал своей девушке, что буду дома рано, поэтому просто собираюсь сделать последний кусок задания на сегодня». Надо было всего-то добавить опцию в раскрывающемся списке на странице «Настройки». Это было просто, точнее, ему так казалось пять часов назад.
Если бы он знал, что дело настолько затянется, то поработал бы вечером из дома. Или вообще оставил бы это на потом.
Джастин пытался исправить раскрывающееся меню, в котором хранятся параметры конфигурации созданных им команд. Все, что ему нужно было сделать, – это добавить параметр в раскрывающемся меню, чтобы пользователь мог скрыть рейтинг для игрока. Он добавил этот параметр, но всякий раз, когда новый пункт был уже выбран, на странице возникало сообщение: «Вы должны выбрать пункт из списка». И то, что казалось простой манипуляцией, отняло у него часы.
Когда он занимался отладкой кода страницы валидатора, то увидел, что тот читает параметры из кэшированной копии таблицы базы данных. Поэтому он добавил вызов обновления кэша, когда пользователь нажимает кнопку ОК, и теперь этот пункт проверялся, что потребовало от него перейти в другое место кода и внести еще три изменения. Кроме того, еще три страницы обращались к той же странице настроек. Поэтому их тоже понадобилось исправить.
В результате Джастину пришлось сделать более десятка различных изменений в коде, но в итоге он заработал, хотя и благодаря отвратительному читерскому клуджу[56]. Он попросил совета у Даниэль, и она придумала обходной путь решения неприятной проблемы. «Это обновление кэша использует только ID-номер пользователя. Попробуй создать фейк-класс пользователя, который имеет только его идентификатор, а возвращает ноль для всего остального». Это было некрасиво, но сработало.
Наконец Джастин добавил пункт в раскрывающийся список. И ощутил давно знакомое чувство, вызванное пребыванием в офисе допоздна. Он сказал Даниэль:
– Наконец-то дело сделано. Ухожу домой. Я уже весь издерган изменениями, которые пришлось внести ради этой дурацкой настройки. Думаю, я теперь понимаю, что чувствует пинбольный шарик во время игры.
Она ответила:
– Я знаю, что ты имеешь в виду. Казалось бы, нужно просто поменять кое-что на странице авторизации, но это привело к необходимости править код в трех других местах. Два изменения потребовали дополнительных изменений в других классах, а один из этих классов вызывает сервис, выдающий непонятный ответ. И я не знаю, что с этим делать.
Джастин спросил:
– Почему всегда так происходит?
Даниэль ответила:
– Такова сущность программирования. Фактически вопрос заключается в том, действительно ли ты уверен, что только что написанный код работает?
Ей не хотелось задавать этот вопрос. Несколько секунд они пристально смотрели друг на друга и чувствовали себя неуютно.
– Я лучше потрачу еще несколько минут на тестирование этого, – сказал Джастин. Он надел наушники и начал печатать для своей подруги еще одно послание с извинением.
Код и архитектура
В ходе работ над проектом Chrysler Comprehensive Compensation (C3)[57] Кенту Беку было необходимо изменить корпоративную культуру команды, переключив ее с создания «умного» кода на простые решения, а это весьма сложная задача. Один из методов, который он использовал, – это церемония давления со стороны коллег. Например, группа торжественно шествовала к человеку, придумавшему самое заумное решение, ему надевали на голову шапочку с пропеллером, а затем раскручивали его и комментировали эту заумь. Негативное внимание со стороны команды заставило людей отойти от усложненных решений и перейти к простой архитектуре и простым решениям. Но все люди разные, и не все в команде с готовностью приняли ХР. Одному человеку не понравился новый стиль работы и тесное сотрудничество, поэтому он покинул проект.
XP-команды создают код, который легко изменить. Но как они это делают? Ведь никто не собирается создавать код, который изменить трудно.
Многие разработчики – даже очень умные! – стремятся делать наоборот. Они будут настраивать свои команды на создание кода, пригодного для повторного использования, и потратят много времени, пытаясь спроектировать компоненты, которые можно применять многократно. Но планировать повторное использование очень трудно, и совсем непросто довести до конца разработку чрезмерно абстрактного и обобщенного кода. Ведь объем работы, который придется выполнить для создания общей структуры, ровно такой же, какой необходим для выполнения проекта под ключ. Архитектура для многократно используемой библиотеки, созданная сегодня, вскоре превращается в препятствие, которое команда должна обойти или боится трогать.