Мы все слышали проповеди о безупречных кодовых базах. «Чистый код — это поддерживаемый код!» — хором повторяют они. «Место для всего и всё на своём месте!» — поучают они. Но что, если я скажу вам, что ваша кодовая база может быть здоровее с долей хаоса? Давайте разберёмся, почему иногда контролируемый беспорядок превосходит архитектурную аскетичность.
Кодовый «Тетрис»: когда организация не срабатывает
Рассмотрим этот фрагмент управления памятью на C++ из проекта симуляции физики:
int sz = 100;
int* p = (int*) malloc(sizeof(int) * sz);
int count = 0;
// ... 200 строк вычислений столкновений частиц ...
if (count == sz)
p = (int*) realloc(p, sizeof(int) * sz * 2);
p[count++] = x;
Этот код не выигрывает конкурсы красоты. Нет RAII. Нет умных указателей. Но в контексте он прекрасно работал для быстрого прототипирования гидродинамики. Команда в итоге завернула его в класс ParticleBuffer
… после того как доказала концепцию с помощью исследований, удостоенных Нобелевской премии, используя именно эту «грязную» версию.
Ловушка абстракции
Я однажды потратил три недели на создание идеального AbstractFactoryPipelineManager
, чтобы обнаружить:
- Сроки проекта сдвинулись на 6 месяцев вперёд.
- Наш вариант использования полностью изменился.
- Моя прекрасная абстракция теперь поддерживает ровно ноль активных путей кода.
Урок? Иногда изолента лучше архитектурных чертежей.
Когда стоит принять хаос
Стратегия продуктивного беспорядка:
- Выявление временных функций
(Тот маркетинговый эксперимент? Модуль праздничной акции? Пусть они будут некрасивыми.) - Приоритет скорости
Ранвей вашего стартапа больше заботится о рабочем коде, чем о принципах SOLID. - Содержать беспорядок
Создавайте «зоны карантина» с комментариями// ВРЕМЕННЫЙ
и директориямиexperimental/
.
Парадокс навигации
Как ни странно, некоторые «беспорядочные» кодовые базы становятся более удобными для навигации благодаря органическому росту. Я недавно работал с кодовой базой возрастом 10 лет, где:
- Все вызовы базы данных жили в
/lib/db-spaghetti
- Компоненты UI были в
/views/old-new-experimental
- В папке «utils» было 47 файлов, включая
helpers_final_v2.c
И всё же инженеры могли:
- Исправить производственные проблемы менее чем за 15 минут.
- Обучить новых сотрудников за 2 дня («Просто следуйте по хлебным крошкам!»)
- Вносить изменения, не опасаясь сломать удалённые системы.
Сравните это с гипермодульной кодовой базой, где простые изменения требуют:
- Обновления 17 интерфейсов.
- Модификации 9 файлов конфигурации.
- Умиротворения богов покрытия модульных тестов.
Искусство стратегического создания беспорядка
Набор для выживания для бойцов с грязным кодом:
- Тест из трёх вопросов
Спросите: «Поможет ли очистка этого ускорить выпуск?»
«Нужно ли его модифицировать нескольким инженерам?»
«Это вызывает активные ошибки?» - Документацию по «почему»
Этот уродливый регулярный выражение заслуживает комментария:// Сопоставляет номерные знаки ЕС, кроме люксембургского исключения 2023 года
- Запланируйте спринты «генеральной уборки»
Наша команда проводит «Пятницы археологии кода» с пивом и охотой на баги.
Примите своего внутреннего уборщика кода
Грязная тайна индустрии программного обеспечения: энтропия неизбежна. Как в комнате подростка, кодовые базы естественным образом стремятся к беспорядку. Умение заключается в том, чтобы знать, какие носки оставить на полу, а какие заплесневелые коробки из-под пиццы немедленно выбросить.
В следующий раз, когда у вас возникнет соблазн стать Мари Кондо программирования, спросите себя: «Приводит ли эта абстракция к радости… или просто создаёт больше работы?» Иногда самый поддерживаемый код — это тот, который уходит с вашего пути и позволяет вам выпускать продукт.
Какой у вас самый беспорядочный успех в коде? Поделитесь своими боевыми историями в комментариях — самый творчески хаотичный пример получает годовой запас виртуального стыда… и моё бесконечное уважение.