Первый frontend или реализация бэкенда? [закрытый]

Обычно я решаю, какие поля мне нужны в первом интерфейсе.

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

Конечно, как только я начинаю работать над интерфейсом, я думаю о дополнительных полях или изменениях для базы данных ... такова природа разработки.

Особенно когда с проектом работают новые люди, я бы предложил инкрементный подход.

Выберите функциональность, которая, как вы знаете, вам понадобится. Начните с базы данных (SQL), затем с кода бэкенда (PHP, возможно), затем с веб-фронтенда (HTML). Сделайте все как можно проще, чтобы реализовать этот один блок функциональности. Порядок действий не имеет значения, главное, чтобы работа велась над небольшим фрагментом за один раз.

Как только эта небольшая часть заработает, сохраните копию. Даже с контролем версий. Таким образом, вы всегда сможете вернуться к тому, что получилось, если завтра что-то испортите.

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

Я бы, наверное, планировал заранее на уровне базы данных, потому что любое изменение HTML влияет только на HTML... изменения в базе данных часто требуют изменений кода бэкенда, которые часто требуют изменений HTML, а переделывать все заново - это больно.

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

Существует два шаблона общего интерфейса/контракта:

1) Потребности потребителя/приложения -> интерфейс/контракт диктуется приложением, а следующий уровень написан для соответствия/адаптации к этим потребностям. Все уровни в настоящее время в основном управляются их потребителями. Плюс в том, что у вас, вероятно, будет наиболее эффективный и ограниченный набор необходимых методов, недостатком является то, что есть больше работы по адаптации системы к другим потребителям.

OR

2) Service Provider -> интерфейс/контракт продиктован сервисом, который предназначен для поддержки основного набора общих функций, которые могут обслуживать многие приложения, даже некоторые из них еще не известны. Приложение, которое потребляет поставщика, должно затем адаптировать возможности контракта к своим внутренним потребностям. Плюс в том, что сервис более многоразовый без модификаций,однако эти обобщенные методы, вероятно, будут менее эффективными для нужд любого конкретного приложения.

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

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

Как правило, после разработки уровня вы работаете на уровнях, где определены контракты, и следите за уровнями, на которых используются контракты.

Вопрос в высшей степени субъективный. В практической реальности, в которой мы живем, одна из них ограничена способностью клиента сообщать о своих требованиях таким образом, чтобы их можно было преобразовать в код (и, конечно, постоянно расширять требования). В средних и крупных компаниях есть бизнес-аналитики, которые выполняют большую часть этих обязанностей. Что касается уровня, с которого начать разработку, специалист по БД скажет DB, webguy скажет интерфейс и т. Д. Каждому в соответствии с их способностями.

Нет серебряной пули. Я рекомендую вам прочитать несколько основных парадигм, таких как Agile и водопад .

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