Первая реализация интерфейса или бэкэнд?

Ответ 1

Хорошо, что у меня есть друзья веб-разработчиков, которые уверены в PHP и MysQL и веб-дизайнере, который также будет мне помогать. У меня есть идея веб-сайта, которая вызывает у меня некоторое время, и я хотел бы, чтобы она была реализована. Основная проблема заключается в том, что мои коллеги действительно хотят помочь мне, но мне хотелось бы, чтобы я приложил некоторые усилия и попытался сделать часть анализа (спецификации требований к программному обеспечению). Я уже проделал некоторую работу с Axure на Frontend и бэкэнд-каркасе, но знаю, что я чувствую себя немного глупо, поскольку я понимаю, что я должен был начать с разработки базы данных и других проблем. Чтобы выглядеть более профессионально с информацией о проекте, которую я буду готовить для своих коллег, я все равно хотел бы разбить ее на список, так что это будет что-то вроде этого:

• Конструкция базы данных (модель данных - диаграммы привязки объектов, модель процесса - диаграммы потоков данных);
• Бэкэнд-код;
• Кодирование Frontend;
• Пока это будет сайт электронной торговли, поэтому кодирование с нуля торгового картеля или реализация существующего.
• Создание связи с системой учета (например, quickbooks).

Можете ли вы критиковать (или добавить что-то) в мой список?

Большое спасибо.

Ответ 2

Я обычно решаю, какие поля мне нужны в первом конце.

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

ИЛИ

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

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

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

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

Ответ 6

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

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