РБПО-046. Процесс 8 — Формирование и поддержание в актуальном состоянии правил кодирования (часть 2/4)

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

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

В любом случае, код должен оформляться единообразно. Иначе неизбежны проблемы при совместной разработке и поддержке проекта. А мы в рамках темы РБПО говорим о проектах, где участвуют много разработчиков, а не об индивидуальном пет-проекте.

Есть ещё одна проблема, которая возникает, если нет единого подхода к написанию и оформлению кода: как вносить правки в код коллег, оформленный в их собственном стиле? Хорошего варианта нет:

1. Написать нужный код в своём стиле. Постепенно получится каша из несвязанных стилей. Это то же самое, когда вообще ни у кого нет никакого стиля написания кода. Код со временем при совместной работе будет становиться всё хуже и непонятнее всем сразу.
2. Постараться подстроиться под код коллег и написать в их стиле. На практике не сработает, так как на самом деле программист не знает, что это за стиль. А если даже ему расскажут, он всё равно забудет или запутается, ведь сложно запомнить все рассказанные ему варианты написания. В общем, и это не рабочий подход.
3. Отрефакторить код коллег под свой стиль. Большая, пустая трата времени и большие diff-ы, в которых будет невозможно понять, где рефакторинг, а где, собственно, нужные изменения.

Надеюсь, что у вас в компании уже давно принят стандарт кодирования. Тогда достаточно это просто переоформить в регламент, а всё, что я здесь пишу, прочитать по диагонали. Однако если стандарта кодирования нет, внедрение РБПО — хороший момент наконец создать эту полезную вещь! Впрочем, стандарт кодирования однозначно принесёт пользу даже вне контекста РБПО. Так что если у вас его нет, прямо сейчас откройте задачу на его создание :)

Если я всё ещё не убедил, расскажу последнюю историю. Общаясь с одним человеком, который проработал в коммерческой компании почти с момента её основания до становления успешным большим бизнесом, я спросил, что бы он устроил по-другому в работе, если бы вернулся лет на 15 назад? Ответ, в том числе, содержал следующий момент:

Я бы настоял принять единый стандарт кодирования на всю компанию. Мы упустили этот момент, и сейчас мы по факту имеем свои собственный стандарты кодирования для С++ и Java в разных командах, работающих над своими проектами. Это очень неудобно, но сейчас внедрять единый стиль и переформатировать код всех этих проектов нереально.

В общем, чем раньше вы позаботитесь о единообразии, тем лучше!