Оптимизируй для перемен, а не для скорости: почему DX теперь главная метрика
Скорость кода — вчерашний день. Сегодня побеждает тот, кто быстрее адаптируется, а не считает микросекунды.
Разработчики, готовьтесь к ереси: оказывается, гнаться за каждой миллисекундой в рантайме — не всегда лучшая стратегия. Автор блога EchoOff предлагает переключить фокус с производительности приложения на... производительность разработчика. Да-да, тот самый DX, который мы так любим пиарить, но редко внедряем.
Сравнение с IKEA тут напрашивается само собой: можно собрать шкаф за час, но если инструкция на китайском, а ключ шестигранный — через полгода он развалится. Так и с кодом: быстрый, но негибкий — это бомба замедленного действия. Автор предлагает оптимизировать под изменения: писать код, который легко рефакторить, а не тот, который выполняется за 0.01 мс.
Главный аргумент: бизнес меняется быстрее, чем вы успеваете профилировать. Пока вы вылизываете ботлнеки, конкуренты уже выкатили фичу на кривом, но рабочем коде. И да, тот самый «технический долг» — это не всегда зло, если он окупается скоростью изменений. Конечно, если вы не пишете софт для космического корабля, где каждая наносекунда на счету.
Практический совет: начните с CI/CD, который не ломается от одного коммита, и модульной архитектуры, где замена библиотеки не требует переписывания всего проекта. И помните: ваш код живёт дольше, чем ваш стартап (особенно если стартап — пет-проект).
Комментарий студии METABYTE: Мы тоже когда-то гнались за идеальным кодом, пока не поняли, что клиенту нужен работающий продукт вчера. Теперь мы оптимизируем под изменения — и CI/CD у нас не падает даже после пятничного коммита.