В этом году стукнуло уже 10 лет, как я разрабатываю умные контракты на Solidity под EVM. В связи с этим решил написать статью и устроить очередной холивар про выбор фреймворка в зависимости от типа проекта, который предполагается разрабатывать. Статья в меньшей степени актуальна для разработчиков (тут не будет глубоких технических разборов и измышлений на тему tool1 быстрее tool2 на N ms) и в большей степени для руководителей, которые принимают решение о выборе технологического стека перед стартом web3-проекта и сбором команды исходя из соображений бизнеса и рационального использования ресурсов (да, это тоже зачастую важно и я готов сегодня пострадать за эту истину на костре из минусов за эту ересь).
Экономия ресурсов, разделение труда и bus factor
В большинстве сценариев при выборе технологического стека не следует раздувать команду из-за слишком разрозненного стека (стоит отметить что это далеко не всегда достижимо, но вполне реалистично в значимой части проектов). Так по закону Брукса время выполнения проекта не обратно пропорционально числу программистов, поэтому при разработке следует стараться действовать как можно меньшими командами при прочих равных.
При этом следует сохранять устойчивость команды к bus factor, что в самом примитивном виде сводится к простому дублированию каждой роли в команде вплоть до двух девопсов в небольшой команде на случай, если с одним из них что‑то случится. Тем не менее снижение риска bus factor возможно не только за счёт примитивного…
