Как организовать разработку клиент-сервеного приложения?

Question

[ewb]

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

У нас явно ощущаются пробелы в организации работы. Особенно в части апи, как место нашей "состыковки".

Может быть есть готовые рецепты, как организовать такую работу? Писать какие-то планы? Регламентировать апи заранее? Что-то ещё?

Отдельно отмечу, что работать приходится по сути без ТЗ, все в текучке.

Comments

[Everything_is_not_so_bad]

Похоже на Как идеально построено взаимодействие между фронтэнд и бэкэнд разработчиками?

[ewb]

Роман Мирр, спасибо!

Answer 1

[Владимир Коротенко]

Определите контракты апи хоть на уровне json файлов, бэкеелер будет пилить потихоньку, вы уже будете иметь заглушки. Как это документировать это уже ваши заморочки я бы передавал примерный джисон и граничные условия. У нас допустим используется swagger но так как я пишу отдельный компонент я и фронт и Бэк делаю сам

Comments

[ewb]

Спасибо! Думал примерно в таком же направлении, но виду несколько проблем:
1) так как работаем без ТЗ (с оглядкой на похожий сервис), пока сложно предсказать весь спектр методов апи и их наполнение, но ближайшие конечно можно

2) вероятнее всего будут изменения этого апи по ходу дела. Например написали мы конкракты для нескольких методов, бекендер пилит, я юзаю заглушки, а потом происходит какая-то вынужденная корректировка методов.

Answer 2

[rPman]

Вообще то это должен быть it архитектор, который должен определить все необходимое, и даже составлять прогнозы развития систему на будущее, особенно если инет подробного ТЗ.

Что в вашем проекте главнее? что задает тон разработки, бакэнд или фронтэнд? Если бакэнд по сути прослойка к базе данных, то пусть за api отвечает фронтэндер, ведь для его удобства его разрабатываете, если же у приложения сложная бизнеслогика и сложное использование и несколько клиентов, то скорее всего тон разработки api должен задавать бакэндер.

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

Comments

[ewb]

Спасибо за развернутый ответ!

Answer 3

[Saboteur]

UML