День 297. Agile (IX). Экстремальное программирование (III)

Код и архитектура

Принцип простоты

XP-команды создают код, который легко изменить. Но как они это делают? Ведь никто не собирается создавать код, который изменить трудно.

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

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

Многие люди считают, что хрупкий, трудно изменяемый код — это ошибка, типичная для новичков. Но нередко даже лучшие разработчики создают код, который непросто модифицировать. (Неопытные программисты редко создают достаточно большой исходный код, чтобы в нем проявились такие проблемы) И необязательно написанное ими программное обеспечение будет плохим или неудачно спроектированным. В большинстве случаев это сводится к вопросу, какой код написан: «заумный» или простой.

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

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

Принятие решений в последний ответственный момент — это инструмент не только планирования. Он ценен также при проектировании и кодировании. И это главное средство, при помощи которого XP-команды реализуют принцип простоты.

Спагетти-код, костыли и технический долг

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

признак того, что код пытается выполнять слишком много задач и может

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

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

ник ошибок, особенно если программист вносит изменения в три копии,

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

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

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

Проектирование в XP-стиле

Переход к проектированию в XP-стиле — это смещение дат принятия проектных решений. Проектирование откладывается до тех пор, пока не появится возможность использовать накопленный опыт и сразу же внедрять принятые решения. Это дает возможность команде:

— разворачивать программное обеспечение как можно раньше;

— принимать решения с уверенностью;

— избегать последствий плохих решений;

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

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

Использование непрерывной интеграции для поиска проблем проектирования

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

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

Монолитная архитектура

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

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

Обсудить у себя 0
Комментарии (0)
Чтобы комментировать надо зарегистрироваться или если вы уже регистрировались войти в свой аккаунт.

Войти через социальные сети:

Сахаров Денис
Сахаров Денис
Был на сайте сегодня в 15:47
Читателей: 21 Опыт: 920.487 Карма: 10.1215
все 22 Мои друзья