Сначала передний конец или сначала задний. Из двух, что является хорошей практикой проектирования системы?

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

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

Благодарность!

Вот заключение статьи, которую я нашел в Интернете некоторое время назад. Просто хочу поделиться

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Front-end против back-end разработчиков (мое мнение)

Мое личное мнение

Опять же, это вопрос обучения, некоторые обширные обобщения:

Разработчики интерфейса

• Как правило, не имеют степени CS или степени CS из школы 3-го уровня.
• Работа на языках, похожих на базовые (см. PHP на базовом уровне)
• Иметь визуальные навыки в преобразовании документов Photoshop в CSS / HTML / и т. Д.
• Высокий допуск для итеративного программирования, благодаря языкам без типов

Back end разработчики

• Иметь степень CS или большой опыт
• Склонны ко мне более систематичны в подходе к решению проблем
• Не против потратить дни, чтобы найти тот объект, который протекает
• Попробуйте и инструменты для решения проблем

Если вы начнете сзади и пойдете вперед, вы рискуете неправильно понять клиента. Поскольку вы будете создавать вещи, которые они не могут легко увидеть и понять, они не могут очень легко участвовать в проверке того, соответствуете ли вы требованиям. Это означает, что вы можете потерять много работы.

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

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

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

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

Одним из представлений является статическая структура данных. В этом представлении есть как минимум три измерения: архитектурные уровни («спереди назад»), варианты использования и действующие лица, а также затраты или риски реализации.

Одним из представлений является динамическая структура обработки. В этом представлении также есть как минимум три измерения.

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

Я мог бы продолжать, но суть в следующем.

Front-end против back-end разработчиков (мое мнение)

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

• Используйте Случаи и Актеры

• Логическая модель данных для поддержки этих вариантов использования

• Процесс, который выполняется как часть варианта использования

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

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

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

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

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

Но что бы вы ни делали, не позволяйте дизайну одного диктовать дизайн другого. Так лежит безумие.

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

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

Разработчики интерфейса

Как правило, не имеют степени CS или степени CS из школы 3-го уровня.

Поднятие рук. Сколько людей со степенями CS были обучены передовым методам на переднем крае? Или как не испортить JavaScript? Или как справиться с проблемами CSS из IE6-IE9? Учебная индустрия, в которой работает академия, слишком толстая и раздутая, чтобы справляться с постоянно меняющимися технологиями, поэтому в колледжах ей уделяется очень мало «серьезного» внимания. Это было превосходно для поздних расцветов, таких как я.

Работа на языках, похожих на базовые (см. PHP на базовом уровне)

Потому что PHP это технология на стороне клиента? Или потому, что JavaScript, который был вдохновлен прежде всего Scheme, имеет больше общего с Basic, чем с Visual Basic, который больше не является постоянной задачей на переднем крае и никогда не был, но все еще доступен для веб-приложений .NET на заднем плане? Я думаю, что в этом блоге сравниваются веб-разработчики с открытым исходным кодом, обучающие себя самообучаемым, и веб-разработчики, использующие популярные корпоративные технологии. Я столкнулся с невыносимым и компетентным в равных долях с обеих сторон этого конкретного боя, но он все еще там.

Иметь визуальные навыки в преобразовании документов Photoshop в CSS / HTML / и т. Д.

Больше внимания к деталям, чем «визуальное мастерство», которое немного шире. Не у всех нас есть эстетические навыки дизайна вообще. Но да, большинству из нас приходится изучать этот материал на уровне младшего, и на самом деле это очень важно для написания хорошего пользовательского интерфейса, который не использует молотки JS, когда это делают скальпели CSS.

Высокий допуск для итеративного программирования, благодаря языкам без типов

Вот почему вы хотите, чтобы фрагменты, которые я упоминал ранее, были на месте в первую очередь Переходим по нажатым кнопкам, вы производите / извлекаете товар. Мы упаковываем и доставляем их. Нет никаких причин для того, чтобы эти вещи каким-либо образом были тесно связаны друг с другом. Также на самом деле строгая типизация не должна мешать итеративному процессу, если вы не используете ООП, как это обычно делает большинство людей, которые любят надменно относиться к языку, не имеющему технических классов. Но даже если они воняют, внешнему интерфейсу нужна только предсказуемая точка доступа, и вы можете делать все, что захотите, на внутреннем сервере, если вы не делаете глупостей, таких как динамическое написание JavaScript, который не является JSON или тесно связать успешное поведение бэкэнда со структурой HTML "просто так". * кашель * Java-разработчики * / кашель *

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

Я рекомендую вам рассмотреть подход TDD, когда один из них проводится (приемочные и модульные) тесты.

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

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

Для этого подхода рекомендуется читать растущее объектно-ориентированное программное обеспечение, руководствуясь тестами .

API сначала

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

Объединить с итеративным подходом и должно выглядеть так:

1. Разработайте простой API
2. Обе команды разрабатывают и тестируют на основе API
3. Интеграционный тест
4. Покажите клиенту и получите обратную связь.
5. Улучшите API и повторите.

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

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

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

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

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

Да, я понял, что ОП спросил некоторое время назад. Начните с задней части, но поднимите переднюю часть, чтобы позволить пользователю увидеть то, что вы видите. Передняя часть, как бы то ни было, это просто навороты. Бэк-энд - это то, где деньги, и как только вы получите эту прямую, FE - это просто соус по мясу.

Расширяя мой комментарий:

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

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

Как начать с FE, без BE? ИП для чего ??? Определите свою базу данных! Это то, что ИП манипулирует.

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

Тем не менее, я 1) подчеркиваю, что это только грубый макет, для обсуждения морских свиней, и 2) намеренно делает его уродливым, но функциональным , так что те, кто не понимает, могут придираться и сказать мне, чтобы сделать это поле ввода точно 400px Широкий и синий фон.

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