Эта статья изначально была написана в личном блоге автора

TL;DR

Для тех, кто ищет быстрые ответы, не желая читать весь текст, вот краткое содержание:

  • Повторно используйте код, который повторяется более одного раза.
  • Читабельность и простота поддержки важнее универсальности.
  • Делайте модули, классы и компоненты как можно меньше.
  • Используйте правила и стандарты для кода.
  • Пишите код, как будто вы в команде, даже если работаете один.

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

Большинство разработчиков знакомы с принципом DRY (Don’t Repeat Yourself). Он позволяет избежать дублирования кода.

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

Но имейте в виду, что использование принципа DRY увеличивает сложность кода, потому что, в конце концов, количество повторно используемого кода будет расти.

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

Читабельность и простота поддержки важнее универсальности

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

Когда вы начинаете придерживаться принципа DRY, сложность вашего кода начинает расти. Когда растет сложность - страдает читабельность.

Поэтому не начинайте написание кода с громоздких универсальных решений. Начинайте с простых! Не надо пытаться сделать идеально с первого раза.

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

Когда вы работаете в компании с несколькими командами разработчиков, в вашей команде скорее всего будут еще и внешние исполнители (фрилансеры или консультанты). Таким людям, как правило, приходится намного чаще переключаться с одного проекта на другой.

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

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

Делайте модули, классы и компоненты как можно меньше

Разрабатывая новые функции для проекта, вы, скорее всего, стараетесь тщательно их продумать.

Помните, что лучшие решения — это те, которые можно разделить на небольшие модули, классы или компоненты. А знаете почему?

Маленькие куски кода проще тестировать и поддерживать.

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

Большинство современных библиотек и фреймворков разбиты на маленькие строительных блоки, а не представлены в виде одного файла. JavaScript библиотеки и фреймворки такие, как Angular, React и Vue используют концепцию компонентов. Вряд ли они делают это случайно.

Используйте правила и стандарты для кода

Одна из составляющих написания читабельного и легко поддерживаемого кода - его архитектура. Другая - его стиль.

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

И лучшим решением в данной ситуации будет автоматическое форматирования кода. Большинство IDE имеют для этого встроенные или устанавливаемые в виде плагинов инструменты.

Самый простой из таких инструментов, подходящий для большинства языков программирования и редакторов — editorconfig. Вы можете применять правила форматирования кода просто добавляя файл .editorconfig в свой проект.

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

  • Использование табов или пробелов для отступов
  • Тип кавычек: двойные или одинарные
  • Максимальную длину строки
  • Набор символов
  • и т.д.

Вот пример такого файла:

root = true

[*]
charset = utf-8
end_of_line = lf
indent_size = 4
indent_style = tab
insert_final_newline = false
max_line_length = 120
tab_width = 4

[*.md]
max_line_length = off
trim_trailing_whitespace = false

Подробнее про формат файла можно почитать на editorconfig.org

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

Пишите код, как будто вы в команде, даже если работаете один

Последний, но не менее важный пункт: пишите, как будто вы в команде!

Я могу представить, что людям, которые никогда не писали код в команде, очень трудно понять каково это.

Но если вы пишите проект в одиночку, есть большой соблазн начать писать код, который поймете только вы (например, использовать непонятные имена переменных или имена из 2–3 символов и т.д.).

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

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

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

Запомните, что грань между хорошо читаемым и плохо читаемым кодом очень тонка. И чаще всего субъективна.

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

Это перевод статьи 5 Rules to Improve Code Readability