Фронт-энд первый или бэк-энд?

Question

Привет, я должен сделать небольшое приложение CMS в MS ASP.NET, используя WebForms. Я делаю все сам: внешний интерфейс, внутренний интерфейс и схема базы данных.

Теперь, когда я хочу разработать сайт, мне интересно, стоит ли мне начинать с фронтэнда или с конца.

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

Еще раз спасибо за ваше время.

Answer 1

Вы будете разрабатывать все уровни по ходу работы большую часть времени

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

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

Некоторые соображения

Следуйте гибкой разработке

1. Запишите некоторые требования в форме пользовательских историй (и следите заони), которые не дают никакой информации о странице, данных и т. д. Просто что-то вроде Как пользователь, я хотел бы иметь основную навигацию на моей странице .История такого рода позволит позднее вносить изменения в код / ​​страницы, при этом история не станет недействительной.
2. Сначала не спешите с чем-то полностью функциональным.Не перегружайте свой код.Потому что вы в конечном итоге будете вносить изменения = следуйте YAGNI.Например, сначала не полностью проектируйте свою БД.Делайте столько, сколько вам нужно, на каждую разрабатываемую историю.Но подумайте о будущих вещах, которые вам придется интегрировать в существующую кодовую базу.
3. Рефакторинг существующего кода сразу, когда вы видите, что что-то должно быть изменено.
4. Если у вас есть кто-то, чтобы проверить ваш кодПозволь им сделать это.Не разрабатывайте следующие истории, пока существующие ошибки не будут полностью устранены.Вы будете благодарны за это позже.
5. Если ваш код является полусложным, я предлагаю вам написать модульные тесты, чтобы будущие изменения кода не нарушали существующую функциональность.

Больше всего: учитесь по ходу дела и при этом меняйте существующий код.Поскольку вы изучаете эти технологии, я предлагаю вам сначала придерживаться простоты.Вы добавите более сложные вещи, когда это необходимо.Некоторые из них не будут сделаны вообще.Итак, в конце концов, вы поймете YIDNI (да, мне это не нужно).

Answer 2

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

Я волнуюсь о переднем конце в последний раз, вы всегда можете изменить это довольно легко

Answer 3

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

Answer 4

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

Answer 5

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

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