97 этюдов для программистов. Опыт ведущих экспертов

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

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

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

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

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

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

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

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

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

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

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