Комментарии 10
По идее бэкендеру дизайн должен быть безразличен, поэтому UserStory от аналитика во много раз лучше чем экран от дизайнера. API эндпоинты может расписать например тимлид... Или джун попрактиковаться. Важно соблюсти зону ответственности: картинка дизайнеру, фронт мобайл девелоперу, API бекендеру.
У этого конвейера все равно должна быть обратная связь. Встречные предложения по оптимизациям, благодаря которым можно прийти к лучшему и оптимальному решению. Бекенд разработчик может усмотреть в дизайне переусложненные моменты и указать на них.
Это работа аналитика, а бэкендер работает по тз от тимлида. Тимлид в свою очередь ставит задачи на основе совещаний с участием аналитика, проджекта, тимлида фронтенд разработки и продакт овнера, если таковые есть.
Откуда бэкендер может знать какую фичу захотел себе бизнес...
Конечно это все в идеальном мире.
Если жестко разделить работу между:
аналитиком, который не будет сам писать этот код,
тимлидом, который видит только User story, но не видит дизайн-макеты, которые будут реализовывать фронтендеры
и разработчиком, который делает то, что сказали предыдущие 2 человека без права изменений,
То что же в итоге получится? На сколько вообще этот процесс будет гибким? На сколько качественным получится продукт?
Мы за качество и командную работу. Если в работу идут дизайн макеты, то по ним сразу понятен не только внешний вид, но и взаимодействие пользователя с интерфейсом. Максимально эффективно в момент старта работ над этой функцией привлечь все стороны процесса: и аналитика, и фронтендера, и бэкендера.
Аналитик расскажет, как это будет использоваться и зачем это нужно, фронтендеры прикинут, какие методы в какой момент будут дергать, а бэкендеры -- какие данные откуда будут брать и как обрабатывать. На выходе получается оптимальное решение, а не "ну это до меня решили, придется делать как сказали, а не как по-нормальному"
Так что в идеальном мире как раз все участники знают, какую фичу захотел бизнес, зачем он ее захотел, почему мы реализуем именно так и это наиболее оптимальная реализация исходя из всех вводных
Всё хорошо, только вся команда, а не только джуны, аккуратно в письменном виде на форумном движке. Кто-то принял решение? Сразу указал причину, прогноз и следствием каких событий это произошло. Нарисовали формочку? Указали причину, следствие, прогноз. Создали задачу на тестирование? Указали причину, следствие, прогноз. Взяли задачу на выполнение? Снова всё указать. И тогда шансы на успех проекта резко возрастают, если проверять всё будут люди с хорошим анализом. И как можно лаконичнее, вот какая вода в тексте, вот такая же вода и в коде - тысячи строк кода и полное отсутствие хоть какого-то особого смысла в них. Если это наследственный проект.
Можно к вам стажёром?)
Стажеров мы набираем с нашей школы. Следите за будущими запусками!
https://metaclass.kts.studio/
Если интересует именно backend разработка.
https://metaclass.kts.studio/beginner_backend
и где можно поучить про архитектуру и проектирование? Основы Мартина знаю, разве только перечитать.
Учебное проектирование для джунов: как учить и зачем