Вы путаете архитектуру со структурой папок в проекте.
Грех за мной, но к сожалению, нынешнее представление об архитектуре несколько смазанное. Тем более если говорить о фронте - в случае которого, если разработчик приплел хоть что-нибудь, мало-мальски похожее на стандарт - считай достижение.
FSD, FBT, FBF - всего лишь паттерны организации кода
Nope. FSD - самопровозглашённая архитектурная методология, что следует и из названия (design), и из утверждения на их сайте (опять же, мнение): Feature-Sliced Design (FSD) is an architectural methodology for scaffolding front-end applications. (https://feature-sliced.design/docs)
Про FBT, FBF первый раз слышу. Буду признателен за ссылочки на материалы по теме.
Был AngularJs
AngularJs был.
Далее, Angular 2 - отличный пример строгой архитектуры со всеми вытекающими. Там и CLI, и вся экосистема вокруг фреймворка. Это отдельный мир, который на аутсорсе встречается крайне редко, в угоду Vue и React. В статье чуть упомянул про либу vue-class-components, которая, по сути, если захардкориться - делает из Vue ангуляр, но только в плане связки UI—бизнес-логика. Все остальные преимущества ангуляра эта штука не дает и смысла не имеет.
Такой подход неплохо работает на небольших проектах.
В дальнейшем пойти от простого к сложному, при необходимости проще, чем изначально заложить плохую архитектуру (опять грешу) и плясать вокруг с 15 разрабами, не понимающими что происходит. Таковы реалии. Не всегда закладывание первоначальной логики отходит на понимающих людей и в таком случае предложенное в статье решение позволит снизить риски в долгосрочной перспективе.
Вы, явно не поняв суть статьи про "совмещение хорошего качества кода и скорости разработки", вытянули из контекста фразы, внаглую их перефразировав и даже взяв в "кавычки" аки цитата. Затем на основе своих собственных надумок и неудачного опыта с командой сомнительного уровня (я так понимаю, прецедент единственный) сделали вывод.
Суть статьи как раз в том, чтобы такого, что было с вами не допускать.
Если подкрепите свой пример фактическим сравнением уровня аутсорс-команды с которой вы работали с вашей собственной командой из стартапа - можно будет сделать объективные выводы.
А так получается, что вероятнее всего код, который вам прислали - не понравился вашему разработчику, и он в силу отсутствия опыта в решении подобных проблем и отсутствии человека, экспертиза которого позволила бы судить о ситуации непредвзято от третьего лица — не нашел иного выхода кроме переписывания - что по сути крайняя мера.
Грех за мной, но к сожалению, нынешнее представление об архитектуре несколько смазанное. Тем более если говорить о фронте - в случае которого, если разработчик приплел хоть что-нибудь, мало-мальски похожее на стандарт - считай достижение.
Nope. FSD - самопровозглашённая архитектурная методология, что следует и из названия (design), и из утверждения на их сайте (опять же, мнение): Feature-Sliced Design (FSD) is an architectural methodology for scaffolding front-end applications. (https://feature-sliced.design/docs)
Про FBT, FBF первый раз слышу. Буду признателен за ссылочки на материалы по теме.
AngularJs был.
Далее, Angular 2 - отличный пример строгой архитектуры со всеми вытекающими. Там и CLI, и вся экосистема вокруг фреймворка. Это отдельный мир, который на аутсорсе встречается крайне редко, в угоду Vue и React.
В статье чуть упомянул про либу vue-class-components, которая, по сути, если захардкориться - делает из Vue ангуляр, но только в плане связки UI—бизнес-логика. Все остальные преимущества ангуляра эта штука не дает и смысла не имеет.
В дальнейшем пойти от простого к сложному, при необходимости проще, чем изначально заложить плохую архитектуру (опять грешу) и плясать вокруг с 15 разрабами, не понимающими что происходит. Таковы реалии. Не всегда закладывание первоначальной логики отходит на понимающих людей и в таком случае предложенное в статье решение позволит снизить риски в долгосрочной перспективе.
Вы, явно не поняв суть статьи про "совмещение хорошего качества кода и скорости разработки", вытянули из контекста фразы, внаглую их перефразировав и даже взяв в "кавычки" аки цитата. Затем на основе своих собственных надумок и неудачного опыта с командой сомнительного уровня (я так понимаю, прецедент единственный) сделали вывод.
Суть статьи как раз в том, чтобы такого, что было с вами не допускать.
Если подкрепите свой пример фактическим сравнением уровня аутсорс-команды с которой вы работали с вашей собственной командой из стартапа - можно будет сделать объективные выводы.
А так получается, что вероятнее всего код, который вам прислали - не понравился вашему разработчику, и он в силу отсутствия опыта в решении подобных проблем и отсутствии человека, экспертиза которого позволила бы судить о ситуации непредвзято от третьего лица — не нашел иного выхода кроме переписывания - что по сути крайняя мера.