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


30

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

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

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

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

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 или большой опыт
  • Склонны ко мне более систематичны в подходе к решению проблем
  • Не против потратить дни, чтобы найти тот объект, который протекает
  • Попробуйте и инструменты для решения проблем


2
SMH, это причина, почему я говорю людям, что я разработчик программного обеспечения, а не веб-разработчик.
pllee

10
Как эти обобщения относительно разработчиков переднего и заднего плана связаны с вопросом?
Эрик Реппен,

Front End Dev! = Back End Devs, хотя в большинстве случаев переходы ч / б их продолжаются.
Абхинав Гауниял

Я думаю, что единственный правильный ответ здесь будет «Это зависит ...»
Оливер Вейлер

Ответы:


43

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

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

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

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


Я думаю, что это более краткое объяснение. Но было бы лучше сделать бэкэнд первым, потому что я думаю, что проще создать фронт, если у вас хорошо структурированный бэкэнд.
drexsien

3
Если они думают, что интерфейс - это все, вы могли бы упомянуть Google ...
l0b0

1
Вот почему вы должны создать макет GUI, который вы показываете клиенту, и сказать «Это то, что вы хотите, чтобы программа делала?», И как только это будет решено, вы выбрасываете его и начинаете создавать бэкэнд.
Габлин

1
+1. @andsien: Если вы уже получили свое мнение, почему вы спросили? По моему опыту, Пол прав, разработка, ориентированная на особенности, почти всегда является лучшей стратегией.
Док Браун

3
@andsien: «проще создать интерфейс, если у вас хорошо структурированный интерфейс». ИМХО это опасное недоразумение. Проблема в том, что вы не знаете, является ли ваш бэкэнд хорошо структурированным, пока не используете его для создания функций для внешнего интерфейса.
слеске

9

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

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

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

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

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

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

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

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

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

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

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

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

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


7

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

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

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

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

Кроме того, сравнение внешних разработчиков с внутренними разработчиками в 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-разработчики * / кашель *


Мое единственное сожаление, что я не могу +1 ответить на ваш вопрос более одного раза. Жаль, что мне пришлось прокрутить вниз 2 ответа на этот вопрос, чтобы, наконец, найти тот, где указано, что спрашивать о порядке, в котором должны развиваться спереди и сзади, - неправильный вопрос. Я также согласен с вашим мнением о степени CS. И последнее замечание "поздних шароваров".
Шиван Дракон

5

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

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

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

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

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


1

API сначала

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

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

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

0

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

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

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

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

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


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

1
@andsien - ты говоришь о проектировании или строительстве? Я бы не стал создавать внешний интерфейс без предварительного проектирования внутреннего интерфейса.
JeffO

ops моя вина, я думаю о строительстве ... спасибо за это, Джефф.
drexsien

0

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


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

@ErikReppen У меня был такой опыт много раз - я хотел показать клиенту «пользователь будет вводить данные в текстовое поле», а клиент видит «поле формы будет ровно 400 пикселей в ширину, а страница будет иметь бледно-синий цвет». фон с текстом Arial 11pt ... "Но я все же думаю, что лучше, чем никогда не показывать интерфейс. В противном случае можно построить целую систему, которая конфликтует с неустановленными предположениями в их основном случае использования.
октября

Вы можете продемонстрировать интерфейс, но сохранить его простым и понятным. Убери их от фотошопа до полной глупости, если только они не потребуют, чтобы это было продано им. И в этом заключается проблема. Это то, чего они ожидали, но чаще всего они чертовски глупы, чтобы расставлять приоритеты по отношению к пикселям, «фактически заставляя наших клиентов делать то, что мы от них хотим».
Эрик Реппен

эээ, разве не поэтому у нас есть CSS? (хотя я действительно чувствую вашу боль). У меня всегда и преднамеренно есть уродливый, но функциональный FE, и я даю понять, что мы обсуждаем варианты использования, рабочий процесс ... и могу подтвердить это позже. (но истинный ответ - требования-> база
данных-

0

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

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

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

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

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

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

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


«Вы не можете спроектировать FE для манипулирования BE без предварительного проектирования этого BE». Ах, да, вы можете - это называется «прототип». Это может быть ценным первым шагом при запуске новой системы.
слеске

что это за прототип? Никакой пламенной войны, она просто всплыла у меня в голове. Я понимаю, что такое прототип, но, возможно, потому что я пришел из другой области, я просто всегда вижу это как: получить требования, превратить их в варианты использования и дизайн. Если ваш d / b не прибит к гвоздю, вы сделаете ненужную переделку, поэтому сначала разберитесь с этим, а затем выясните, как с ним работать (в соответствии с требованиями). YMMV ... продолжение ...
Mawg

Это, возможно, не черно-белый, иначе вопрос не задавался бы, но БЫТЬ первым, всегда IMO. На самом деле, я делаю то же самое прямо сейчас для клиентов, у которых есть только смутное нечеткое чувство вместо требований (я никогда не должен был их трогать, но это совсем другая история :-)
Моуг

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

Я подозреваю, что мы можем говорить одно и то же по-разному (+1)
Mawg
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.