97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф Страница 4

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

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

Простота — источник и непременный атрибут красоты.

Прежде чем приступать к рефакторингу

Раджит Аттапатту

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

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

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

• Множество мелких изменений лучше, чем одно масштабное. Внося небольшие изменения, легче оценить их воздействие на систему при помощи стандартных каналов обратной связи, таких, например, как тестирование. Грустно видеть, как после внесенного изменения «падает» добрая сотня модульных тестов. Вызванные подобными результатами раздражение и нервозность могут спровоцировать вас на принятие сомнительных решений. Значительно легче справляться, если в каждый момент времени «падают» лишь один-два теста.

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

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

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

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

Осторожно: общий код

Уди Дахан

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

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

Оказывается, я упустил из виду нечто очень важное.

Контекст.

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

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

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

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