ХОРОШИЙ КОД, НО ПЛОХАЯ АРХИТЕКТУРА

ХОРОШИЙ КОД, НО ПЛОХАЯ АРХИТЕКТУРА

Типичная сцена из growth-product: открыть старую форму и понять, что код вроде бы «норм», но продукт уже не читается. Не баги ломают систему первыми. Её ломает накопленная логика: быстрые исключения, временные костыли, фичи «на один релиз», которые потом становятся основой.

Это хороший пример, почему в JTBD важно смотреть не только на решение, но и на контекст появления решения. Люди редко «выбирают плохую архитектуру». Чаще у них есть job: быстро запустить, не сорвать релиз, закрыть запрос продаж, обойти ограничение платформы. И в моменте это рационально.

Проблема начинается позже: решение, которое было ответом на конкретный trigger, продолжает жить уже без него. 📌

Полезный вопрос для интервью:
что тогда было важнее — сделать правильно или сделать быстро?
И что именно заставило выбрать второй вариант?

Так обычно и появляется плохая архитектура: не из глупости, а из серии очень разумных решений в неправильном контексте.