Каков наилучший рабочий процесс для веб-приложения?
Я собираюсь запустить веб-приложение. Прежде чем я начну, я хотел бы получить несколько советов относительно того, каков наилучший рабочий процесс/порядок для создания такого веб-приложения, как это.
Мой проект будет состоять из серверной части с PHP и MySQL. На стороне клиента будут использоваться XHtml, CSS и jQuery. Также будет использоваться AJAX.
Я уверен, что это может зависеть от определенных ситуаций, но, в целом, каков наилучший порядок разработки проекта с этими учетные данные?
Должен ли я сначала начать разработку на стороне сервера? Или мне следует начать с клиентской стороны? Или я должен делать и то, и другое одновременно? Как насчет базы данных - это должно быть первоочередной задачей? Тогда, может быть, даосы?
4 answers
Начните сначала с данных. Данные на стороне сервера являются постоянным, основным ядром приложения. Если эта модель данных неверна, у вас ничего нет.
Вы должны иметь возможность модульно протестировать модель данных, чтобы доказать, что у вас есть правильные атрибуты и отношения. Для этого не требуется многого. Несколько тестовых примеров для вставки, обновления и запроса.
Вы будете поддерживать эту модель данных с помощью внутренней обработки.
Это тоже должно быть модульным тестированием, чтобы продемонстрировать, что он работает и делает все правильно для вашей модели данных. Это будет немного сложнее, так как эта обработка является приложением.
Затем вы можете подумать о модели данных, предоставляемой веб-службами Ajax.
Это также можно проверить, чтобы доказать, что JSON делает правильные вещи. Это тестирование часто бывает довольно сложным, потому что именно на это опирается интерфейс графического интерфейса. Это должно быть правильно.
Затем, как только вы разработаете эту модель данных Ajax, вы сможете напишите интерфейсный графический интерфейс.
Рабочий процесс, который вы описываете, - это то, что я использую для своих собственных (сольных) проектов.
Мне нравится встречаться посередине. Сначала я занимаюсь моделированием данных и одновременно начинаю создавать прототипы интерфейса. Бизнес-правила приходят последними и сводят все воедино.
Я также нахожу это "вдохновляющим", когда у меня есть графический интерфейс для просмотра... это побуждает меня заставить его что-то сделать. Кроме того, графические интерфейсы, как правило, подвергаются наибольшему пересмотру, поэтому, начиная их на ранней стадии процесса, вы будете счастливы с готовым продуктом, и что он будет завершен к моменту реализации вашей бизнес-логики.
Если я работаю в крупной компании, которая не уверена в том, чего именно они хотят, я сначала начну с пользовательского интерфейса. Таким образом, они смогут понять, чего они хотят, прежде чем я вложу много времени в остальную часть системы.
С другой стороны, если я точно знаю, что нужно, то я начну с одной функции и буду продвигаться вверх по слоям, базе данных, контроллеру, представлению и ajax, пока эта функция не будет выполнена, а затем перейду к следующей функции. Таким образом, у меня будет меньше контекста для помните, и у клиента всегда есть что-то новое, с чем можно поиграть.
Я не могу сказать вам, что абсолютно лучше, но то, что работает для меня, это...
Поговорите с деловыми людьми, чтобы получить представление о том, чего они хотят.
Нарисуйте пользовательский интерфейс ручкой и бумагой. Поля представляют собой страницы. Кнопки и ссылки имеют стрелки, указывающие на другие страницы. Не нужны все микроскопические детали. Некоторые вещи подразумеваются.
Как только пользовательский интерфейс будет достаточно хорошо отображен, разработайте схему БД. Иногда я записываю все таблицы в текстовый файл, например это...
pets
----
id
name
species
# etc...
Затем реализуйте базу данных. Я использую миграции Rails. Вы можете написать DDL вручную.
Если у вас есть модели или DAO или что-то в этом роде, я бы реализовал их следующим образом с помощью модульных тестов.
Затем я обычно работаю с приложением сущность за сущностью. Заставьте представление и контроллеры работать. Быстрое переключение между кодом тестирования и кодом реализации.
Это общее последовательность, но все время происходят корректировки и так далее. Вам нужно будет вернуться к своему дизайну БД и развивать его по мере создания реальной функциональности.