Одинокий программист делает интерфейсный бэкэнд вместе или один за другим

Question

Я использую PHP с CodeIgniter (MVC framework).Мой вопрос довольно прост.Что, по вашему мнению, является лучшим подходом при работе с немного сложным веб-сайтом.

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

Я бы до сих пор просто начал строить одну страницу за раз.Работая над проблемами CSS, выполняя поведение (JavaScript) и back-end одновременно.

По вашему опыту, эффективнее ли front-end полностью справляться со всеми проблемами, выполнять все с ними.а потом работать на серверной логике?

А как насчет JavaScript?(Выполнять только JavaScript + валидацию, связанную с пользовательским интерфейсом, с внешним интерфейсом, а затем выполнять все вызовы AJAX и ответы на него с помощью внутреннего интерфейса ..?)

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

Я не делал MVC с PHP, но мой опыт работы с WPF / C # должен быть похожим. Я начал с архитектуры (я использовал контейнер DI, чтобы собрать все вместе), после этого я сделал первый ViewModel вместе с действительно упрощенным интерфейсом, чтобы проверить, все ли в порядке (да, TDD будет более подходящим, чем угодно ). Я продолжил это и не особо сосредоточился на пользовательском интерфейсе, если только мне не понадобилась кнопка или около того. Через некоторое время я закончил с ViewModel и сосредоточился на пользовательском интерфейсе, доводя его до совершенства.

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