Читаем Постигая Agile полностью

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

Новая архитектура возникает, когда команда обнаруживает изменения, которые необходимо сделать. Чтобы добавить новое поведение в систему или переменить способ ее работы, команда должна изменить отдельные модули или способ их взаимодействия. Но поскольку каждый модуль несвязан и взаимодействия между ними просты, эти изменения, как правило, не носят каскадного характера по всей системе. Если встречается код «с душком» (скажем, программист обнаруживает, что занимается «стрельбой дробью», продирается через спагетти-код или сырые объекты), то это серьезное предупреждение, что во время работы были допущены ненужные усложнения. И разработчик знает (а что еще важнее – чувствует): стоит потратить время на рефакторинг, чтобы разделить код на более простые модули.

Система, построенная на возникающей архитектуре, может развиваться годами, оставаясь простой для поддержки и изменений. Успешные ХР-команды имеют инструменты для поддержания простоты исходного кода. Стиль их работы поощряет постоянно отслеживать появление сложного кода и выполнять его рефакторинг. Это, в свою очередь, позволяет им без напряжения вносить изменения, ведущие к возникновению архитектуры. Такой эффективный цикл приводит к простому, стабильному и очень качественному коду – и в результате команды обнаруживают, что таким образом можно создавать и поддерживать программное обеспечение намного быстрее. Когда система нуждается в поддержке (исправить ошибку или внести изменения), редко требуется серьезная модификация, затрагивающая много различных частей кода.

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

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

В этом суть ХР.

Описание: команда занимается разработкой фантазийного баскетбольного сайта

Джастин – первый разработчик

Даниэль – второй разработчик

Бриджит – менеджер проекта

<p>Акт V. Окончательный результат</p>

Даниэль и Джастин были заняты парным программированием, когда Даниэль вдруг воскликнула:

– Ты понимаешь, что мы работаем в паре уже почти три месяца?

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

Джастин сказал:

– Ты права. Все это время мы работали парами, но меняли партнеров так часто, что, по-моему, я успел поработать с каждым членом команды.

Даниэль спросила:

– Когда ты в последний раз засиживался допоздна?

Джастин задумался.

– Знаешь, мне придется поискать в телефоне последнее сообщение с извинениями. Давненько это было.

– Думаю, это потому, что мы стали лучше, – сказала Даниэль. – Я знаю, что теперь пишу более простой код, чем шесть месяцев назад.

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

Даниэль добавила:

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

Проходившая мимо Бриджит остановились и прислушалась.

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

Джастин спросил:

– А как теперь?

Перейти на страницу:

Похожие книги

100 абсолютных законов успеха в бизнесе
100 абсолютных законов успеха в бизнесе

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

Брайан Трейси

Деловая литература / Маркетинг, PR, реклама / О бизнесе популярно / Финансы и бизнес