В своей заметке «We are destroying software» автор под ником antirez с горечью описывает, как современные практики разработки превращают когда-то простое и увлекательное занятие в сложную, переполненную зависимостями структуру. Я постараюсь развить эту мысль и добавить своё видение на проблему, поделившись наблюдениями и техническими деталями, которые слишком часто остаются за кадром.
🧩 «Убиваем» софт, не учитывая взрывающуюся сложность
Когда-то в программировании было больше места для простых решений и прямых зависимостей. Да, это не значит, что всё было «идеально» и не содержало своих подводных камней. Но сейчас мы наблюдаем особый вид комбинаторного роста сложности, когда коду всё время «накручивают» новые фичи, не обращая внимания на архитектурную целостность.
- Сложные сборочные системы (build systems): Maven, Gradle, CMake, Bazel, Meson и другие системы сборки. Конечно, они решают важные задачи, но слишком часто «затягивают» проект в болото конфигураций, плагинов и обилия параметров. В итоге разработчик тратит кучу времени на настройку самого инструмента, вместо того чтобы сосредоточиться на проблеме, которую решает.
- Цепочка зависимостей: Когда приложения включают в себя сотни внешних библиотек, каждая из которых, в свою очередь, имеет свои зависимости. Мы становимся свидетелями того, как простая утилита в пару килобайт превращается в «монстра» на мегабайты, от которого легко отваливается любая совместимость.
💡 «Не изобретай колесо» как тормоз для обучения
Очень легко сказать джуниору: «Не изобретай велосипед» («Не reinvent the wheel!») и заставить его с нуля освоить «де-факто стандартные» решения. Но ведь именно самостоятельное создание простых реализаций (пусть даже уже известных) помогает глубже понять, как всё устроено. Со временем это приводит к новым открытиям: появлению библиотек или инструментов, которые способны лучше решать конкретную задачу, чем очередная «библиотека по умолчанию».
Моё мнение:
Да, не стоит писать свою реализацию сортировочной функции там, где уже существует оптимизированная стандартная. Но в образовательных целях иногда лучше сделать «свой велосипед», чтобы овладеть фундаментальными знаниями. В долгосрочной перспективе это окупается лучшим пониманием кода.
🔄 Постоянные переписывания и отсутствие обратной совместимости
Автор пишет о постоянных призывах всё «переписать на новом фреймворке» и забыть о старых API. И действительно, если старые библиотеки, инструменты и форматы не поддерживаются, разработчикам приходится тратить уйму усилий на повторную реализацию функционала — часто без реальной выгоды.
- Переписывание «рабочего» софта бывает оправдано, когда меняется фундамент (например, переход с 32-бит на 64-бит системы или принятие новых стандартов безопасности). Но гораздо чаще это «выкидывание кода» происходит из-за желания работать «на новом хайпе»: Go, Rust, очередной web-фреймворк, React → Vue → Angular → Svelte, и т.д.
- Ломать API без необходимости — один из верных способов создать хаос. Будущее проекта становится неопределённым, а длительная поддержка (LTS) превращается в суровый квест.
🌐 Погоня за «де-факто стандартами» и библиотеками
Когда мы выбираем очередной популярный фреймворк (да ещё и в увесистой «монорепе»), мы часто недооцениваем, насколько дорого обойдётся интеграция. Бывает, что лучше написать небольшой модуль «под задачу» — он будет быстрее и безопаснее. Но корпоративная культура и мода выталкивают нас на «общепринятые» инструменты, которые кажутся «золотым стандартом» лишь потому, что их используют многие.
💬 Культура комментариев и миф о «чистой» инженерии
В заметке звучит идея, что мы «уничтожаем» комментарии, считая их бесполезными. Действительно, есть экстремальная точка зрения: «хороший код самодокументирован». Но на практике — особенно в сложных системах — трудно обойтись без пояснений логики в виде комментариев, примеров о том, почему код написан именно так.
Программирование — это не только инженерия. Это ещё и часть творчества, в котором есть место для эксперимента, эстетики кода и личного стиля. Если мы сократим всё до формальных UML-диаграмм и бездушных инструкций, мы потеряем сам дух «хакерства» и веселья.
⚖️ Невозможность «масштабирования вниз»
Согласитесь, сегодня порой сложно поднять простой HTTP-сервер, не установив огромный рантайм, сотню зависимостей и не написав километров конфигурационных файлов. Как заметил автор, «простые вещи должны быть лёгкими» — но мы сами создаём инфраструктуру, где простейшая задача становится тяжелой из-за многоуровневой абстракции, которой нет конца.
🚀 Проблема скорости vs качества дизайна
Культура «DevOps» и «быстрых релизов» в какой-то степени хороша, но когда разработчиков постоянно подгоняют и требуют «фичи вчера», это неизбежно ведёт к пошаговому накоплению технического долга. Неготовые решения выкатываются в продакшн, обещания «потом рефакторим» сбываются нечасто, и в итоге система превращается в нагромождение патчей.
Мой совет:
Если ваша организация ориентирована только на скорость, без мыслей о долговечной структуре кода и реструктуризации, последствия догонят вас очень быстро. Важно находить баланс, включая время на рефакторинг.
🙌 Итог: как вернуть радость «хакерства»?
Проще всего пожаловаться на всё и отмахнуться, но мы можем предпринять конкретные шаги:
🔎 Развивайте культуру «легковесности». Прежде чем подключать третью по счёту библиотеку, спросите себя: «Могу ли я решить эту задачу проще?»
💾 Сохраняйте совместимость. Если есть потребность менять API, подумайте о версиях и адаптерах. Пользуйтесь «semver» или аналогичными схемами.
🛠️ Поддерживайте независимость. Минимизируйте критические зависимости, которые удерживают вас «на игле» одного вендора или громоздкой экосистемы.
💬 Пишите комментарии там, где без них непонятно, почему код делает что-то особенное. Это не убьёт «чистоту» кода, а убережёт коллег от мучений.
Ссылка на оригинальную новость
Современная разработка действительно порой убивает радость от написания кода. Но у нас ещё есть шанс сохранить баланс между инновациями и традициями, между сложностью и простотой. Бережное отношение к архитектуре, вдумчивое отношение к чужим и своим зависимостям, осознание важности комментариев и понимание, что «неизобретение колеса» не всегда благо — всё это поможет вернуть нам чувство кайфа от хакерства и сохранит культуру софтверного ремесла.