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

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

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

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

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

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

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

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

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

Существуют известные паттерны программного обеспечения для распространённых проблем. В 1995 году была опубликована книга «Design Patterns: Elements of Reusable Object-Oriented Software», описывающая распространённые паттерны программного обеспечения. Эта книга описывает распространённые проблемы, встречающиеся в большинстве приложений, и предлагает элегантный способ их решения. Разработчики также создают свои собственные паттерны при решении проблем, с которыми они регулярно сталкиваются. Хотя они не публикуют книгу, если присмотреться, вы сможете их определить.

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

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

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

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

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

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

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

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

Не делайте так:

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

Делайте так:

int feedInterval = 3;

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

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

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

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

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

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

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

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

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

Для получения дополнительной информации о написании чистого простого кода см. книгу Uncle Bob’s Clean Code и Code Simplicity Макса Канат-Александера.

Заключение

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