• Применяйте средства статического анализа кода для поиска нежелательных антипаттернов. Прерывайте сборку при их обнаружении.
• Научитесь настраивать эти инструменты, что поможет находить антипаттерны, специфические для вашего проекта.
• Не просто замеряйте процент покрытия тестами, но и делайте автоматическую оценку результатов. Прерывайте сборку, если процент покрытия тестами недопустимо низкий.
Постарайтесь внедрить эти принципы в отношении всех требований к коду, которые вы считаете важными. Полностью автоматизировать все, что вас беспокоит, вы не сможете. Те аспекты, которые невозможно обнаружить или исправить автоматически, следует включить в дополнительный набор правил — как приложение к автоматизированной части стандарта. Однако вам придется принять тот факт, что у вас и ваших коллег есть возможность соблюдать правила из этого приложения менее строго.
Наконец, стандарт кодирования должен эволюционировать, а не быть высеченным в камне. С течением времени потребности проекта меняются, и то, что казалось разумным в начале, совсем не обязательно останется таковым через несколько месяцев.
У Платона есть одно высказывание, которое, как мне кажется, особенно полезно было бы знать и принимать близко к сердцу всем разработчикам программного обеспечения:
Рано или поздно каждому программисту приходится выполнять рефакторинг существующего кода. Но прежде чем броситься в бой, поразмыслите о нескольких вещах, которые могут сберечь вам и коллегам уйму времени (и уберечь от головной боли):
• Лучше всего начинать рефакторинг с оценки состояния существующего в проекте кода и написанных для него тестов. Так вы сможете выяснить достоинства и недостатки кода в его текущем состоянии, чтобы сохранить его сильные стороны и избежать уже сделанных ошибок. Каждому кажется, что его система будет лучше, чем нынешняя… до тех пор, пока не выяснится, что новый код не лучше, а может, даже хуже, чем предыдущая версия, — и все потому, что мы не стали учиться на ошибках, допущенных в старой системе.
• Сопротивляйтесь желанию переписать все заново. Лучше всего повторно использовать как можно больше кода. Каким бы уродливым он ни казался, этот код уже протестировали, прорецензировали и все прочее. Выкинуть старый код, а особенно если он использовался в рабочей системе, — значит выкинуть месяцы (или годы) работы над протестированным и проверенным в боях кодом, который может содержать неведомые вам обходные решения или исправления дефектов. Если не учесть этого, в новом коде могут проявиться те же загадочные ошибки, которые уже были исправлены в старом коде. В результате вы потеряете массу времени и сил, а также знания, копившиеся годами.
• Множество мелких изменений лучше, чем одно масштабное. Внося небольшие изменения, легче оценить их воздействие на систему при помощи стандартных каналов обратной связи, таких, например, как тестирование. Грустно видеть, как после внесенного изменения «падает» добрая сотня модульных тестов. Вызванные подобными результатами раздражение и нервозность могут спровоцировать вас на принятие сомнительных решений. Значительно легче справляться, если в каждый момент времени «падают» лишь один-два теста.
• После каждой итерации разработки важно убедиться, что все имеющиеся тесты успешно отрабатывают. Если имеющиеся тесты не покрывают внесенные вами изменения, создайте новые тесты. Не выбрасывайте тесты из старого кода бездумно. Внешне может казаться, что некоторые из них не применимы к новой архитектуре системы, но будет совершенно не лишним потратить время и разобраться, с какой целью был создан конкретный тест.
• Личные предпочтения и самолюбие оставьте в
Красота — следствие простоты Йорн Ольмхейм
У Платона есть одно высказывание, которое, как мне кажется, особенно полезно было бы знать и принимать близко к сердцу всем разработчикам программного обеспечения:
Красота стиля, гармония, изящество и хороший ритм основываются на простоте.Одно это предложение объединяет ценности, которыми нам, разработчикам, надлежит восхищаться. Есть ряд вещей, которых мы стремимся достичь в нашем коде: • Читаемость • Простота сопровождения • Скорость разработки • Неуловимая красота Платон говорит нам, что все эти качества возможны только благодаря простоте. Что такое красивый код? Вероятно, это очень субъективный вопрос. Восприятие красоты сильно зависит от личного опыта, как зависит от него наше восприятие чего бы то ни было. Изучавшие искусство иначе воспринимают красоту (по крайней мере, иначе к ней подходят), чем получившие техническое образование. Люди с гуманитарным образованием обычно рассматривают красоту программы, сравнивая ее с произведением искусства, тогда как люди с техническим образованием чаще рассуждают о симметриях и золотом сечении, пытаясь все свести к формулам. По моему опыту, именно на простоте строятся в большинстве своем доводы обеих сторон. Поразмышляйте об исходном коде всех программ, которые вам доводилось встречать. Если вы никогда не занимались изучением кода, написанного другими людьми, прямо сейчас отложите чтение, найдите какой-нибудь открытый исходный код и изучите его. Я серьезно! Поищите в Интернете код на вашем любимом языке, написанный известным и признанным специалистом. Вы вернулись? Хорошо. На чем мы остановились? Ах, да… Я обнаружил, что примеры кода, которые находят отклик в моей душе и кажутся мне красивыми, имеют некоторые общие свойства. Прежде всего, это простота кода. Я считаю, что каким бы сложным ни было приложение или система в целом, отдельные его части должны быть простыми: простые объекты, выполняющие единственную задачу, и в них настолько же простые специализированные методы с хорошо понятными именами. Некоторые считают, что требовать, чтобы методы содержали не более 5-10 строк кода, — это крайность, и в некоторых языках этого очень трудно достичь. Однако мне все же кажется, что такая лаконичность очень желательна. Вывод таков: красивый код — значит простой код. Все составные части просты, решают простые задачи и связаны простыми отношениями с другими частями системы. Благодаря этому мы можем облегчить сопровождение кода своих систем, а понятный, простой, легко тестируемый код обеспечит высокую скорость разработки на протяжении всего времени существования системы. Простота — источник и непременный атрибут красоты.
Прежде чем приступать к рефакторингу Раджит Аттапатту
Рано или поздно каждому программисту приходится выполнять рефакторинг существующего кода. Но прежде чем броситься в бой, поразмыслите о нескольких вещах, которые могут сберечь вам и коллегам уйму времени (и уберечь от головной боли):
• Лучше всего начинать рефакторинг с оценки состояния существующего в проекте кода и написанных для него тестов. Так вы сможете выяснить достоинства и недостатки кода в его текущем состоянии, чтобы сохранить его сильные стороны и избежать уже сделанных ошибок. Каждому кажется, что его система будет лучше, чем нынешняя… до тех пор, пока не выяснится, что новый код не лучше, а может, даже хуже, чем предыдущая версия, — и все потому, что мы не стали учиться на ошибках, допущенных в старой системе.
• Сопротивляйтесь желанию переписать все заново. Лучше всего повторно использовать как можно больше кода. Каким бы уродливым он ни казался, этот код уже протестировали, прорецензировали и все прочее. Выкинуть старый код, а особенно если он использовался в рабочей системе, — значит выкинуть месяцы (или годы) работы над протестированным и проверенным в боях кодом, который может содержать неведомые вам обходные решения или исправления дефектов. Если не учесть этого, в новом коде могут проявиться те же загадочные ошибки, которые уже были исправлены в старом коде. В результате вы потеряете массу времени и сил, а также знания, копившиеся годами.
• Множество мелких изменений лучше, чем одно масштабное. Внося небольшие изменения, легче оценить их воздействие на систему при помощи стандартных каналов обратной связи, таких, например, как тестирование. Грустно видеть, как после внесенного изменения «падает» добрая сотня модульных тестов. Вызванные подобными результатами раздражение и нервозность могут спровоцировать вас на принятие сомнительных решений. Значительно легче справляться, если в каждый момент времени «падают» лишь один-два теста.
• После каждой итерации разработки важно убедиться, что все имеющиеся тесты успешно отрабатывают. Если имеющиеся тесты не покрывают внесенные вами изменения, создайте новые тесты. Не выбрасывайте тесты из старого кода бездумно. Внешне может казаться, что некоторые из них не применимы к новой архитектуре системы, но будет совершенно не лишним потратить время и разобраться, с какой целью был создан конкретный тест.
• Личные предпочтения и самолюбие оставьте в