Все средства хороши, кроме решения проблемы: почему разработчики боятся простоты
Разбираемся, почему инженеры предпочитают навороченные архитектуры вместо простого решения — и как это ломает проекты.
Вы когда-нибудь видели, чтобы разработчик вместо того, чтобы написать 10 строк кода, разворачивал микросервисную архитектуру с Kubernetes и event sourcing? Если да — вы не одиноки. В IT есть негласное правило: «Все средства хороши, кроме решения проблемы».
Опытный инженер Йосеф Кремин опубликовал эссе, где с хирургической точностью препарирует эту боль. Он замечает, что вместо того чтобы просто починить баг, команды предпочитают переписать всё на новом стеке, внедрить «правильный» паттерн или добавить абстракцию. Это напоминает ситуацию, когда вместо того чтобы поменять перегоревшую лампочку, вы решаете перепроектировать всю электропроводку в доме.
Почему так происходит? Ответ прост: решать проблему скучно и не престижно. Гораздо веселее обсуждать на созвоне, какой фреймворк круче, или перекладывать ответственность на «недостаточную гибкость архитектуры». А в итоге получаем overengineering, который живёт своей жизнью, а проблема так и остаётся нерешённой. Знакомая боль, коллеги?
Что с этим делать? Кремин предлагает вспомнить старый добрый принцип KISS (Keep It Simple, Stupid). Не надо городить огород из технологий там, где хватит одного скрипта. Простота — это не отсутствие навыков, а высший пилотаж.
Комментарий студии METABYTE: Мы тоже любим красивую архитектуру, но если клиенту нужно «просто починить кнопку», мы не будем разворачивать для этого блокчейн. Эффективность — наше всё, даже если это не добавит звёздочек на GitHub.