5 шагов для написания кода для следующего разработчика

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

Кент Бек о хороших программистах:

Любой дурак может написать код, который понимает компьютер. Хорошие программисты пишут код, который понимают люди.

Дуглас Крокфорд о хороших компьютерных программах:

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

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

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

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

Существуют известные программные паттерны для общих программных проблем. В 1995 году была опубликована книга “Паттерны проектирования: элементы повторно используемого объектно-ориентированного программного обеспечения”, описывающая общие программные паттерны. Эта книга описывает общие проблемы, встречающиеся в большинстве программных приложений, и предлагает элегантный способ решения этих проблем. Разработчики также создают свои собственные паттерны при решении проблем, с которыми они регулярно сталкиваются. Хотя они не публикуют книгу, если присмотреться достаточно внимательно, их можно выявить.

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

Некоторый код просто раздражает, обратитесь к коллеге — второй взгляд всегда помогает. Пройдитесь по коду вместе. Вы удивитесь тому, что вы двое найдете.

Вот 5 советов по оставлению подсказок для следующих разработчиков

1. Паттерны
Используйте известные паттерны, создавайте свои собственные паттерны. Придерживайтесь последовательной парадигмы во всем коде. Например, не используйте 3 подхода к доступу к данным.

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

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

3. Подробные названия
Это ваш язык. Это слова вашей истории. Сплетите их хорошо.

Это включает имена классов, имена методов, имена переменных, имена проектов и имена свойств.

Не делайте:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

Делайте:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

В первом примере число 3 жестко закодировано в операторе if. Этот код синтаксически корректен, но намерение числа 3 ничего вам не говорит. Глядя на свойство, с которым оно сравнивается, можно предположить, что это действительно 3 часа. На самом деле мы не знаем. Мы делаем предположение.

Во втором примере мы присваиваем 3 переменной с именем ‘feedInterval’. Намерение четко указано в имени переменной. Если прошло 3 часа с последнего приема пищи, пора кормить обезьяну. Побочным эффектом установки переменной является то, что теперь мы можем изменить интервал кормления, не изменяя логику.

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

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

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

Стив Джобс о простоте:

Простое может быть сложнее комплексного: вы должны много работать, чтобы очистить свое мышление и сделать его простым. Но в конце концов это того стоит, потому что, достигнув этого, вы можете свернуть горы.

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

Для получения дополнительной информации о написании чистого простого кода см. книгу дяди Боба “Чистый код” и “Простота кода” Макса Канат-Александера.

Заключение

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