Что такое лучший рабочий процесс для веб-приложений?

Question

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

Мой проект будет состоять из серверной части с PHP и MySQL.На стороне клиента будут XHtml, CSS и jQuery.Также будет использоваться AJAX.

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

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

Answer 1

Сначала начните с данных. Данные на стороне сервера - это постоянное и неотъемлемое ядро ​​приложения. Если эта модель данных неверна, у вас ничего нет.

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

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

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

Тогда вы можете подумать о модели данных, предоставляемой веб-сервисами Ajax.

Это также можно проверить, чтобы доказать, что JSON делает правильные вещи. Это тестирование часто бывает довольно сложным, потому что именно на это опирается интерфейс GUI. Это должно быть правильно.

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

Answer 2

Рабочий процесс, который вы описываете, - это то, что я использую для своих собственных (сольных) проектов.

Мне нравится встречаться посередине. Сначала я занимаюсь моделированием данных и одновременно начинаю создавать прототипы интерфейса. Деловые правила приходят последними и собирают все вместе.

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

Answer 3

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

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

Answer 4

Я не могу сказать вам, что является абсолютно лучшим, но что работает для меня ...

• Поговорите с деловыми людьми, чтобы понять, чего они хотят.

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

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

---

pets
----
id
name
species
# etc...

---

• Затем внедрить базу данных. Я использую Rails-миграции. Вы можете написать DDL вручную.

• Если у вас есть модели или DAO или что-то в этом роде, я бы реализовал их следующим образом, с модульными тестами.

• Тогда я обычно работаю через сущность приложения за сущностью. Получите представление и контроллеры, работающие. Быстрое переключение между кодом тестирования и кодом реализации.

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