Распространено ли разделять серверную часть и интерфейсную часть на две позиции в проектах веб-разработки?

При веб-запуске более распространено, чтобы инженер работал над интерфейсом и бэкэндом функции (в основном, отвечающим за всю функцию)? Или инженеры разделились между задним и передним планами?

Какие из них более выгодны и для каких ситуаций?

Я заметил, что недостатком одного инженера, отвечающего за всю функциональность, является то, что человек может быть особенно сильным только в разработке внешнего интерфейса или внутреннего интерфейса, но не в обоих, что иногда приводит к снижению скорости и качества.

Наличие сторонних и внутренних разработчиков на одной функции увеличивает скорость функции и качество, а также поощряет сотрудничество. Но меня беспокоит то, что 2 инженера работают над одной функцией, что может быть плохим использованием ресурсов, так как 1 инженер может быть размещен для работы над другой функцией.

Какова общая / лучшая практика для распределения ресурсов бэкэнда / внешнего интерфейса при небольшом запуске на ранней стадии? И как это изменится с ростом?

Вот моя мудрость из 14 лет опыта:

• если у вас есть стартап, не назначайте роли. Лучше надеяться, что вы собрали хорошую самоорганизующуюся команду. Если все знают друг друга, все знают, кто делает то, что лучше. Руководитель проекта будет стоять только на пути.
• позже различие между входным и задним числом имеет смысл. В бэкэнде качество первостепенное. Код должен быть быстрым, безопасным и безопасным для транзакций. Во фронтенде время внедрения имеет значение. И вы должны быть в состоянии положиться на хороший сервер. Различные цели переднего и заднего плана не работают хорошо вместе.
• бэкэнд должен существовать до того, как интерфейсный кодер начнет работать. В противном случае интерфейсный кодер будет слишком сильно тормозить.
• бэкэнд должен уметь быстро реагировать на требования переднего плана, чтобы не замедлять их

Лучший ответ от @Shark, но только последняя часть «Это зависит». По моему опыту, около 16 лет или около того, я видел оба варианта в различных конфигурациях. Будучи разработчиком полного стека, вот что я узнал:

* (BE = Back End, FE = Front End)

Общие предостережения о разработке сплит стека:

1. Методы гибкой разработки (распространенная стратегия в наши дни) рекомендует разработку функций, где функция представляет собой единый ценный функционал с точки зрения клиента. С этой точки зрения ваш разработчик должен реализовать и то, и другое.

2. Разделение стека вдоль границы сервера создает точку интеграции между двумя разработчиками. Если они не будут эффективно общаться и хорошо работать вместе, это приведет к значительному количеству ошибок, когда эти две функции объединятся.

3. Примените правило общения n (n-1) / 2 из Mythical Man-Month, и вы увидите, что разделение функций на две части между двумя людьми увеличит вашу общую рабочую нагрузку. Конечно, это правило применимо и к функциям, но разделение стека удваивает объем связи.

4. Дизайнер решит проблемы разработчиков BE, которые не могут создавать привлекательные интерфейсы с нуля. Это предполагает, что они, по крайней мере, знают html & css и могут создать интерфейс, соответствующий скриншотам, созданным дизайнером.

5. Функции, как правило, представляют собой изолированные компоненты, которые очень мало взаимодействуют с другими функциями. Это не всегда так, но обычно точка взаимодействия находится на низком уровне, как база данных или файловая система. Таким образом, разработчик полного стека не сильно мешает реализации этой функции. Но если разработчику FE придется подождать, пока разработчик BE завершит задачу, это добавит еще большую задержку сверх потери производительности в пункте 3.

6. Web2.0 еще больше стирает грань между FE & BE. Благодаря инфраструктурам MVC и целым приложениям, создаваемым на стороне клиента, теперь для реализации безопасных и эффективных приложений FE требуется большой объем знаний BE.

7. Моя самая большая претензия к этой практике заключается в том, что она ограничивает возможности всех участников проекта. Хотя это было обычной практикой в ​​начале 2000-х годов, это было сделано из-за необходимости, потому что найти разработчиков, которые могли бы сделать то и другое, было довольно сложно (просто из-за новизны, а не из-за некоторых внутренних трудностей в изучении обоих). десятилетие спустя у нас все еще есть «веб-разработчики», которые не знают CSS.

8. Моя вторая большая неприятность в том, что она может легко сегментировать команду разработчиков. Разработчик FE создает ошибку после модификации кода BE, и команда голосует, чтобы ограничить оптовую разработку кросс-стека. Принимая во внимание, что пересмотр кода и образование могут решить проблему, люди вместо этого становятся территориальными.

Преимущества / варианты использования разработки сплит стека:

1. API RESTful идеально подходят для этого разграничения, потому что нет FE. Часто компания сначала работает над RESTful API, а затем разрабатывает свои веб-приложения. В этом случае есть веские основания для сосредоточения команды BE на следующей основной версии, пока FE заканчивает приложение. Но опасность оттока по-прежнему существует - особенно если новая информация, обнаруженная на этапе разработки FE, требует нетривиальных модификаций BE API.

2. Несбалансированные рабочие нагрузки между FE & BE также являются хорошим примером для создания команды только для FE. Опять же, это очень ситуативный случай, когда, возможно, основная разработка выполняется с помощью настольного приложения, а компания пытается разработать «облегченный» веб-интерфейс.

3. Обучение новых / младших разработчиков. Если вы нанимаете стажера или младшего разработчика и хотите бросить их в углубление, это хороший вариант, чтобы инвестировать часть этих затрат на связь / интеграцию в систему одноранговой разработки.

Обеспокоенность по поводу принятого ответа @ Ralf на этой странице:

1. Первый пункт довольно смелый - и он быстро провалится, если у вас нет одной из этих «хороших самоорганизующихся команд». Даже если у вас есть эта команда, это в ваших интересах и в их интересах раздвинуть границы. И хорошие самоорганизующиеся команды не всегда мотивированы, чтобы сделать это.

2. Ваш второй пункт просто неверен. Современная веб-разработка требует, чтобы код FE был быстрым, безопасным, асинхронно безопасным, защищенным от XSS, кросс-браузерным и быстро развивался. Цели просто не конкурируют с BE, они фактически равны.

3. Третий пункт также является неверным предположением - разработка FE может начаться с чистого html / css / js без какой-либо фундаментальной работы BE. Оттуда это всего лишь тривиальная попытка разбить его на шаблоны для рендеринга BE. Часто лучше начинать с работы FE, потому что это даст заинтересованным сторонам ощущение тепла и нечеткости, чтобы увидеть визуальный прогресс заранее.

Вывод:

Если вы являетесь стартапом и у вас не так много времени или денег, чтобы работать, то не нанимайте FE или BE только разработчиков. Наймите высокопоставленных веб-разработчиков и хорошего UX / дизайнера, и они как можно быстрее запустят ваше приложение. Они стоят дороже, но гораздо продуктивнее, и вам понадобится меньше.

Я думаю, что вопрос не так.

Все стартапы, в которых я принимал участие, не имели архитектуры FE-BE only.

Большинство стартапов, которых я знаю, имеют:

• Ядро - актуальный продукт, который предоставляет интерфейс
• UI - БЫТЬ и ИП. BE использует API ядра.

API-интерфейсы не сохраняют состояния и легко подделываются - даже без необходимости в Core Developer. Черт, если бы мне пришлось начинать проект с нуля, я мог бы начать с целого пользовательского интерфейса, который работает исключительно на макетах - что будет хорошо для презентаций. Большая часть отзывов связана с пользовательским интерфейсом. Клиенты отмечают, что больше - (зависит от вашей целевой аудитории.)

Например, в Поиске Google есть основной компонент, который сканирует Интернет, индексирует его и т. Д., А пользовательский интерфейс Google - это совершенно другой мир. Это ядро ​​может легко поддерживать поиск не в WWW, а пользовательский интерфейс - нет.

Таким образом, ваш интерфейс «подключаемый», и у вас есть разделение интересов.

Вы ссылались на Знания о разработке, однако упускаете из виду аспекты управления проектами. В то время как основной команде может понадобиться 2 недели спринта, команда пользовательского интерфейса будет использовать CI - все загружается все время. Базовая команда будет нуждаться в обратной совместимости, а пользовательский интерфейс - нет.

Язык отличается. Вам, вероятно, понадобятся разработчики C для компонента Core - и все будет в порядке, если он будет работать на одной ОС, где пользовательский интерфейс будет написан на кросс-OS.

Тесты разные. Мир тестирования пользовательского интерфейса - один из самых сложных в разработке программного обеспечения. Большинство стартапов пренебрегают этим и потом сожалеют об этом решении. Вы не можете разделить BE и FE при тестировании. Это должно быть единое целое, которое справится с этим.

Open Source UI - одно из величайших преимуществ их разделения заключается в том, что вы можете открыть свой UI с открытым исходным кодом. Проект пользовательского интерфейса нуждается в поддержке с открытым исходным кодом.

Я не могу представить разработчика UI, который не может понять всю session функцию. Вы знаете - где вы входите и остаетесь в системе между различными запросами. Правда, они могут знать PHP, а не Java ... но концепция BE должна быть ясной (например, использовать зашифрованный cookie). Конкретный языковой барьер неправильный - каждый разработчик должен быть готов работать на любом языке. Кто бы мог подумать, что они напишут BE на JavaScript пару лет назад?

Если у вас есть 3 команды: Core, BE и FE, это пустая трата ресурсов imho. Как насчет БД? у вас должны быть администраторы баз данных? Почему разработчик BE должен знать DB, а разработчик FE не знать BE и DB? Там нет предела.

Если вам нужны эксперты, и вы будете, аутсорсинг их работает довольно хорошо. Они обычно предоставляют качественный код и делают это довольно быстро. Вы не обязательно хотите их в доме, потому что вы потеряетесь, если они уйдут. Кроме того, вы можете получить отличный совет онлайн сегодня. Передовые вещи могут потребовать другого подхода.

Таким образом, в результате получается очень тонкий BE в пользовательском интерфейсе, который может разработать каждый разработчик FE. Если у вас толстый BE в пользовательском интерфейсе, вам, скорее всего, требуются некоторые функции API, необходимые для ядра.

Всегда есть хотя бы один разработчик, который выделяется среди остальных. Учитывая такой тонкий FE, он / она может управлять предоставлением поддержки (не разрабатывать) другим разработчикам в коде BE. Мое мнение таково, что этот разработчик находится в очень хорошем положении и должен получать соответствующую награду (хотя не в зарплате, а в другом) Я также верю, что они смогут справиться с процессом сборки и построить правильно.

Эта модель дает вам большую гибкость в отношении разработки BE. В мире BE за последние пару лет было несколько изменений, поэтому я не рекомендую слишком сильно полагаться на стабильность BE. Ядро это отдельная история.

Остается вопрос: должны ли FE и BE быть одним и тем же проектом ? Вы должны отметить следующее

• Статические ресурсы лучше всего обслуживать с фронт-сервера. Поскольку серверы переднего плана (например, nginx) очень мощные, и поскольку вы можете использовать Cache для статических ресурсов, вы можете управлять одним развертыванием статических ресурсов (которое должно быть всем содержимым HTML, JS, CSS, изображениями).
• Внутренний код не имеет такой же роскоши, поэтому у вас должна быть распределенная система, которая также управляется фронт-сервером.
• Код FE можно использовать повторно со всеми новыми технологиями, поддерживающими JavaScript. Теперь вы можете писать настольные и мобильные приложения с помощью JavaScript.
• Процесс сборки совершенно другой - и даже может включать доставку исправлений, обновление, установку и т. Д.

Я могу продолжать, но я надеюсь, что ясно, что я думаю, что BE и FE должны быть одной командой, но, возможно, разными проектами.

Я думаю, что успешная реализация может быть несколько вещей. Если есть единственный разработчик, у которого есть сильный бэкэнд, но он также хорошо разбирается в пользовательском интерфейсе и во всех «интерфейсных» компонентах, то это может быть успешным. Это, как правило, не так (по моему личному опыту). Например, я считаю себя back-end разработчиком. Но я работаю над многими проектами самостоятельно. Работаю ли я над презентацией и надписью на стороне клиента? Конечно. Они выглядят так же хорошо, как настоящие талантливые дизайнеры и разработчики на стороне клиента? Точно нет.

Это все дать и взять. Но не позволяйте сотрудничеству двух разработчиков заставить вас колебаться. Есть проверенные и истинные способы максимизировать производство между разработчиком и дизайнером.

Другими словами ... это зависит