Стандарты кодирования — залог хорошей сопровождаемости проекта
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Иначе разработка начинает напоминать басню Крылова «Лебедь, Щука и Рак».
Если над проектом работает больше одного разработчика, то обязательно должен быть стандарт оформления кода (его еще часто называют стандартом кодирования или стилем программирования). Это касается и аутсорсинговых компаний, в которых проект может передаваться от одного разработчика к другому, и проектов, которые передаются на поддержку и сопровождение «во вне», да и вообще любых проектов, которые будут существовать больше нескольких месяцев, сопровождаться и дорабатываться.
Стандарт кодирования — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков. Цель использования стандарта — упрощение восприятия программного кода человеком, сокращение нагрузки на память и зрение при чтении программы. Бонусом к этому идёт возможность эффективного использования сравнений в системе контроля версий — разный стандарт оформления кода «ломает» нормальный процесс работы с diff, так как подсвечиваются все изменения в оформлении, а не только в бизнес‑логике.
В стандарт кодирования обычно входят соглашения о принципах именования классов, функций и переменных, правила форматирования (например, ширина отступов и используемые для этого символы), стиль оформления комментариев и условия их использования, а также использование нотации документирующих комментариев.
Обычно это всё автоматизируется на уровне IDE (программной платформы, которая служит для написания кода). Программист может писать код как ему удобно, а IDE будет автоматически форматировать написанный программный код согласно заданным правилам. Для этого используются линтеры — программы, которые форматируют код в сответствии с задаваемой конфигурацией. В разработке на Ruby, например, используется rubocop, в JavaScript и TypeScript — eslint.
Использование стандартов кодирования — это экономически целесообразный подход, так как чем быстрее программист может понять написанный ранее код, тем меньше оплачиваемого времени он на это потратит. Да и для душевного здоровья программистов это полезно — практически все программисты не любят читать чужой «говнокод» в смутной надежде понять задумку его автора и разобраться с фактически заложенной в него бизнес‑логике, ведь нередко бывает, что задумка и фактическая реализация — это «две большие разницы». Разумеется, что правильное оформление не гарантирует красоту и тем более правильность реализации, но всё же значительно ускоряет понимание.
Стремления к красоте реализации и правильности программной архитектуры тоже реализуемы на уровне соглашений — в этом очень помогает соблюдение принципов программирования, например: DRY, KISS, YAGNI, SOLID.
Тематические статьи
Принцип программирования YAGNI — «Вам это не понадобится»
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться.
В результате разработка ненужных функций не сжигает бюджет проекта, а разработчики не тратят оплачиваемое время на реализацию и дальнейшее сопровождение в реальности ненужного функционала. Избыточный функционал сжигает больше всего ресурсов именно на сопровождении: больше написанного кода — труднее сопровождать и выше вероятность появления «багов». И тут очень уместна поговорка: «лучший код — это ненаписанный код».
Принцип программирования KISS — делайте вещи проще
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.
Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
SOLID — принципы объектно‑ориентированного программирования
SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
TDD — разработка через тестирование
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов.
TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.
Флаги функций (Feature Flags)
Флаги функций позволяют отделить развертывание функций от развертывания кода, обеспечивают возможности для A/B-тестирования и предоставляют механизм быстрого отключения проблемных функций