January 14th, 2010

4. Автоматизируйте стандарт кодирования

(В оригинале - Automate Your Coding Standard)

Наверняка с вами это тоже случалось. В самом начале проекта у всех присутствует множество позитивных намерений. Часто эти намерения даже фиксируются в документах. Вещи, касающиеся кода, формируют стандарт кодирования. В ходе kick-off митинга технический лидер проходит стандарт кодирования по пунктам, и в лучшем случае каждый соглашается следовать этому стандарту. Однако по ходу проекта намерения потихоньку исчезают одно за другим. И когда проект завершаетсся, код выглядит совершенно беспорядочно, и при этом никто не может понять, как же оно так получилось.

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

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

Существует множество инструментов для генерации отчетов о качестве кода и для документировании стандарта кодирования, но это еще не все. Автоматизировать нужно все, что касается стандарта кодирования и поддается автоматизации. Вот несколько примеров.

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

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

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

Автор оригинала - Filip van Laenen

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

О новостях

Что первым приходит вам в голову от вот такого заголовка в новостной ленте: "Авианосец ВМС США и две тысячи морпехов помогут разрушенному Гаити"?

5. Красота и простота

(В оригинале - Beauty Is in Simplicity)

Есть одна цитата, которую стоит знать каждому разработчику. А еще лучше эту цитату не просто знать, а все время помнить.

«Красота стиля, гармонии, грации и ритма определяется простотой» - Платон.

Нам всем как разработчикам ПО стоит почаще пользоваться этой цитатой как руководством к действию.

Мы добиваемся того, чтобы наш код обладал следующими качествами:

  • Читаемостью;
  • Сопровождаемостью;
  • Скоростью разработки;
  • Красотой.

И Платон говорит нам, что простота – это то, что открывает дверь для всех этих свойств.

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

Подумайте об исходном коде, в котором вам пришлось разбираться. Если вам этого делать не приходилось, то прекратите читать эту статью и прямо сейчас найдите какой-нибудь open source проект для изучения. Серьезно! Я не шучу! Найдите в интернете что-нибудь на каком-нибудь языке программирования по вашему выбору, написанное каким-нибудь известным экспертом.

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


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

Красота рождается из простоты.

Автор оригинала - Jørn Ølmheim

Перевод мой, при использовании ссылка на мой живой журнал обязательна!