О разделе "Культура кода"
Культура кода — это общие договорённости в команде — как мы называем сущности, форматируем файлы, комментируем неочевидное, ревьюим изменения и не превращаем качество в личный вкус одного человека. Хорошая культура снижает стоимость правок: код читают и меняют чаще, чем пишут с нуля.
Знать синтаксис языка недостаточно — важно понимать стиль проекта, инструменты (форматтеры, линтеры) и то, какую информацию оставлять в коде, а какую — в документации и тестах.
Для кого
- Новичкам — соглашения об именовании, форматирование, комментарии "про зачем", а не "про что".
- Разработчикам — связь читаемости с метриками (цикломатическая сложность), принципы KISS/DRY/YAGNI на примерах.
- Тимлидам и ревьюерам — как обсуждать качество без морализаторства и споров "на вкус".
Рекомендуемый порядок
| Шаг | Материал | Содержание |
|---|---|---|
| 1 | Культура написания и поддержки кода | Именование, стиль, комментарии, XML/JSDoc, IntelliSense, базовые принципы |
| 2 | Цикломатическая сложность и читаемость | Метрика, пороги, запахи кода, рефакторинг, кейсы |
| 3 | MAPPER — модель и реальность | Сопоставление домена и кода, биекция, единый принцип |
| 4 | Анемичные модели и примитивы | Богатые объекты, value objects |
| 5 | Изменяемость и побочные эффекты | const, иммутабельность |
| 5a | Декларативный код | "Что" и "как", итерации, async, ошибки |
| 6 | Условия, null и контракты | Fail fast, меньше if, без null |
| 7 | Связанность и глобалы | Singleton, god object, запахи модульности |
| 8 | YAGNI, быстрый провал, техдолг | Объём кода, PR, warnings |
| 9 | Тесты как часть культуры | Качество assert, flaky, моки |
| 10 | Исключения | try/catch, сообщения об ошибках |
| 11 | Итоги | Краткое резюме раздела |
| 12 | Чек-лист самопроверки | Вопросы перед merge |
| — | Справочник тем | Симптом → статья раздела |
Если времени мало: 1 → 2 → 5 → 6 → Примитивы, value objects и маленькие типы → 8; перед ревью — 4 и 13 (поиск по симптому).
Что здесь и чего нет
Здесь — качество исходного кода на уровне файла и модуля. Настройка пайплайнов, политики веток и процессы релиза — в других главах энциклопедии (методология, инфраструктура, команда). Зато много про формулировки в ревью, автоматизацию рутины и то, как не спорить о пробелах вручную.
Закрепить базовую теорию (глава 2)
Читаемый код не отменяет понимания среды, в которой он работает:
| Вопрос при ревью или ошибках | Теория |
|---|---|
| HTTP-контракт, статусы, идемпотентность | 2.09 API и HTTP · HTTP |
| Сообщения об ошибках и утечки в ответах | 2.08 Основы ИБ · исключения в культуре кода |
| Асинхронность, очереди, retry | Брокеры · устойчивость в 7.06 |
Закрепить базовую теорию (глава 4)
Культура кода — про файл и модуль; фундамент терминов и механизмов — в томе "Код и разработка":
| Вопрос при ревью или рефакторинге | Теория |
|---|---|
| Запахи, каталог приёмов Фаулера | Методы рефакторинга |
| Примитивы, value objects | Примитивы и маленькие типы · ООП — введение |
| Иммутабельность, потоки | Параллельные вычисления — о разделе |
| Декларативность, async/await | Асинхронность — о разделе |
| SOLID, DIP, абстракции | SOLID |
| try/catch, стек, Error vs Exception | Ошибки и исключения |
| YAGNI, мёртвый код, техдолг | Архитектура выполнения · технический долг |
Культура кода — о разделе
Подборка материалов раздела Культура кода в энциклопедии Вселенная IT
Культура написания и поддержки кода
Именование, форматирование, комментарии, документация в коде и базовые принципы читаемости — практики, которые команда договаривается соблюдать каждый день.
Цикломатическая сложность и читаемость кода
Цикломатическая сложность — одна из наиболее устойчиво применяемых метрик статического анализа программного кода, призванная количественно оценивать логическую структуру исполняемого модуля.
MAPPER — модель кода и предметная область
Правило MAPPER (Model Abstract Partial Programmable Explaining Reality) — как сопоставлять реальность и код один к одному.
Анемичные модели и примитивная одержимость
Богатые объекты предметной области, value objects вместо string/int и антипаттерны DTO-оргии.
Изменяемость, побочные эффекты и неизменяемые данные
const, иммутабельность, ленивая инициализация и побочные эффекты в читаемом коде.
Декларативный код — что и как
Разделение «что» и «как», итерации, магические числа, callback hell и явные ошибки.
Условия, null и явные контракты
Меньше if и switch, отказ от null, быстрый провал и полиморфизм вместо флагов.
Связанность, глобалы и запахи модульности
Singleton, god object, shotgun surgery, feature envy и глобальное состояние — симптомы и приёмы рефакторинга.
YAGNI, быстрый провал и техдолг в коде
Мёртвый код, лишние абстракции, отключённые предупреждения и отложенный рефакторинг.
Тесты как часть культуры кода
Приватные методы, flaky-тесты, assertTrue, моки и данные — качество тестового кода и связь с разделом тестирования.
Исключения и обработка ошибок в читаемом коде
Пустые catch, исключения как goto, узкие try и сообщения для пользователя.
Культура кода — итоги
Итоги раздела «Культура кода» — FAQ и краткие ответы по теме.
Культура кода — чек-лист
Вопросы перед отправкой кода в репозиторий — именование, принципы, тесты, ревью и безопасность. Ответы ищите в статьях раздела.
Справочник тем чистого кода
Указатель запахов и тем качества кода с ссылками на статьи раздела 7.10 и смежные материалы энциклопедии.
В подборках
Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:
Техлид — Микросервисы и интеграция — о разделе, Технический дизайн на основе требований, Архитектура выполнения — о разделе, Командная работа в разработке ПО, Проектирование — о разделе, Паттерны проектирования — о разделе.
Управление проектами и Agile — Базы знаний и задачники — о разделе, Экономика производства ПО — о разделе, Scrum — о разделе, Коммуникация и общение — о разделе, Методология и жизненный цикл ПО — о разделе, Команда и управление — о разделе.
Тимлид — Scrum — о разделе, Организационная иерархия и деловая переписка, Ежедневные стендапы и коммуникация, Первые 90 дней тимлида, Роль тимлида — ожидания, риски и выбор траектории, Эффективное управление разработчиками.