Практики кодинга, за применение которых вы в будущем скажете себе спасибо

Перевод статьи «Coding practices your future self will love you for».

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

1. Стандартизируйте форматирование кода

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

Есть много инструментов, помогающих с форматированием. Например, Golang предоставляет отличную команду gofmt в стандартной библиотеке. Она кладет конец всем дискуссиям относительно форматирования, которые часто возникают при ревью кода в Golang-сообществе.

2. Не нужно слепо следовать принципу DRY

DRY (Don’t Repeat Yourself — «не повторяйся») это практически мантра для разработчиков. Но если применять этот принцип необдуманно, вы получаете код, сложный для чтения и понимания. Это также мешает различным частям кода проявить весь их потенциал. Поэтому не следуйте принципу DRY вслепую.

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

3. Дебаггинг при помощи логов

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

Но не увлекайтесь: не стоит добавлять повсюду ненужные логи. Это засорит ваш log-файл в продакшене.

Излишек логов == отсутствие логов.

4. Остерегайтесь преждевременных оптимизаций

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

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

5. Не усложняйте свою кодовую базу ненужным функционалом

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

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

6. Настраивайте CI/CD пайплайн на ранних стадиях цикла разработки

Даже если у вас театр одного актера, CI/CD пайплайн снижает накладные расходы, связанные с необходимостью помнить (и выполнять) сборку и деплоймент отдельно взятой кодовой базы.

Довольно распространено мнение, что CI/CD пайпллайны важны только в командах, ежедневно отправляющих в продакшен большое количество кода. Исходя из собственного опыта могу сказать, что они имеют куда большее значение для кодовых баз, с которыми работают редко, потому что вы банально не помните, как и куда деплоился код. Особенно это касается случаев, когда вы обновляете код раз в году. Кроме того, наличие CI/CD пайплайна подразумевает наличие сценария, который расскажет вам, о чем именно вы думали Х месяцев назад.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]