В 2020 году, в конце марта, меня пригласили писать бэк на Node.JS для сервиса видеоконференций. Тогда, во времена начала очередного витка мирового спектакля, резко возрос спрос на инструменты, позволяющие вести работу дистанционно. На прототип сервиса, до того простоявший несколько лет практически без дела, из ниоткуда свалился ежедневный трафик в 2000 человек, что породило необходимость начинать в ускоренном темпе развивать продукт и делать деньги.
Спойлер: миллионерами мы так и не стали.
По мере роста объема и связности кода, становилось все труднее держать логику целиком в голове и, соответственно, гарантировать, что после очередных внесенных изменений ни один из вариантов использования не отвалится. И вот, в один прекрасный момент, было решено начать покрывать код тестами. Так началась история поиска идеальной архитектуры.
Спойлер: тестами код мы тоже так и не покрыли.
Давид Хейнемейер Ханссон, создатель фреймворка Ruby on Rails, в своей статье Test-induced design damage утверждает, что те архитектурные изменения, которые необходимо внести в проект, чтобы сделать возможным написание unit тестов для контроллеров, настолько сильно бьют по остальным характеристикам кода, что лучше отказаться от этой идеи в пользу интеграционных тестов.
Реально ли придумать такую архитектуру, которая не заставляла бы чем-то жертвовать?