Comments 4
Прочитав статью, я вспомнил, почему мне не понравилось работать с аутсорс разработкой. Когда-то я работал в стартапе и у нас не хватало ресурсов, чтобы доставлять фичи. Мы заказали часть проекта в аутсорс компании. В итоге, весь код, при первой же возможности весь код, который нам написали аутсорс разработчики, был переписан. Потому что с точки зрения выполнения задачи, придраться было не к чему – все работало, как и задумывалось. Но код был такой, что поддерживать это всё было совершенно невозможно.
И читая про ваш подход "нормально будешь делать в продукте, а раз ты аутсорс, то делай так, чтобы отдать и забыть", я для себя понимаю, что заказывать разработку у вас бы не стал.
Вы, явно не поняв суть статьи про "совмещение хорошего качества кода и скорости разработки", вытянули из контекста фразы, внаглую их перефразировав и даже взяв в "кавычки" аки цитата. Затем на основе своих собственных надумок и неудачного опыта с командой сомнительного уровня (я так понимаю, прецедент единственный) сделали вывод.
Суть статьи как раз в том, чтобы такого, что было с вами не допускать.
Если подкрепите свой пример фактическим сравнением уровня аутсорс-команды с которой вы работали с вашей собственной командой из стартапа - можно будет сделать объективные выводы.
А так получается, что вероятнее всего код, который вам прислали - не понравился вашему разработчику, и он в силу отсутствия опыта в решении подобных проблем и отсутствии человека, экспертиза которого позволила бы судить о ситуации непредвзято от третьего лица — не нашел иного выхода кроме переписывания - что по сути крайняя мера.
Спасибо за статью!
Вы путаете архитектуру со структурой папок в проекте. В общем случае, способ организации кода в проекте !== архитектура. Архитектура определяет зависимости между элементами системы, способ же представления элементов системы не так важен и может не отражать архитектуры
С фронтом всё не так. Шаблонов и стандартов из коробки, которые пропагандировали бы крупные акулы вроде Laravel, нет
Как нет? Был AngularJs, который реализовал дизайн-паттерн MVVM. Angular 2 с MVC
Опять таки, не стоит путать архитектуру, которую предоставляет фреймворк из коробки со способом организации кода в проекте на этом фреймворке, который действительно никто не навязывает. FSD, FBT, FBF - всего лишь паттерны организации кода
это нужно для создания групп компонентов в пределах одной директории, а очевидная идея про «положить инпуты в /inputs, страницы в /pages...» не имеет практического смысла, так как это — не архитектурный подход, как многие думают, а просто дополнительная вложенность.
Все компоненты в одной папке, максимально плоская структура, никакой вложенности.
Это просто способ организации кода в проекте - folder by type. Такой подход неплохо работает на небольших проектах. При росте проекта уже тяжело становиться следить за кучей компонентов и лучше присмотреться к folder by feature, который позволяет выделить верхнеуровневые абстракции и разбить код на вертикальные слои
Откладывать же принятие решения о выделении дополнительного уровне вложенности, как вы предлагаете, на самом деле только ухудшит читаемость даже на начальном этапе разработки, а тем более, когда уже есть 15-20 сущностей
Вы путаете архитектуру со структурой папок в проекте.
Грех за мной, но к сожалению, нынешнее представление об архитектуре несколько смазанное. Тем более если говорить о фронте - в случае которого, если разработчик приплел хоть что-нибудь, мало-мальски похожее на стандарт - считай достижение.
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 разрабами, не понимающими что происходит. Таковы реалии. Не всегда закладывание первоначальной логики отходит на понимающих людей и в таком случае предложенное в статье решение позволит снизить риски в долгосрочной перспективе.
KISS your website или как написать уважаемый сайт на аутсорсе, глава первая