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

37

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

Роберт Паундер
источник
4
О каких рамках вы говорите? Вы имеете в виду какую-то специализированную бизнес-среду, которая предназначена для решения очень специфичных для конкретной области задач для конкретной отрасли? (например, медицинский, ядерный, оборонный, авиационный и т. д.). Или вы говорите об универсальных средах, предназначенных для решения технических проблем?
Бен Коттрелл
1
универсальные фреймворки, предназначенные для решения технических проблем
Роберт Паундер
2
Небольшой масштаб из-за нехватки времени (я нахожусь в работе, возможно, уточню позже): я пишу систему, которая генерирует электронные письма на основе дизайнов. - Если бы я писал это в Laravel, я бы, вероятно, использовал бы «лезвие» шаблонизатора для разработки электронных писем, что значительно упростило бы проектирование системы с точки зрения потока. Однако мне бы пришлось написать шаблонизатор, если бы я делал это с использованием обычного PHP, или найти другую подходящую альтернативную систему шаблонов. Это добавило бы к процессу проектирования, к которому относится и этот вопрос.
Роберт Паундер
3
На этот вопрос будет получено множество совершенно разных ответов, потому что и «каркас», и «дизайн» - это слова, перегруженные несколькими значениями в нашей отрасли. Кроме того, даже для одного определения структуры как «универсальных сред, предназначенных для решения технических проблем», это будет зависеть от конкретной среды - некоторые платформы являются более самоуверенными, чем другие.
Станниус
1
Было бы очень плохо, если бы его сбил автобус, когда он задумался о разработке колесного общественного транспорта.

Ответы:

51

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

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

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

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

Короче

  • Дизайн для ваших пользователей
  • Выберите подходящие инструменты для реализации вашего дизайна
  • Используйте ваши инструменты так, как они предназначены для использования

Дальнейшие мысли:

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

Берин Лорич
источник
3
Затем вам нужно провести переговоры с клиентом. Объясните, что вы можете и не можете делать с наложенными ими ограничениями. Предложите, как это может измениться, если вы выберете X framework. Возможно, они не хотят меняться и хотят жить с ухудшенным опытом. Или они могут решить, что вы знаете, что делаете, и доверяете вам. Это зависит от клиента. В конце дня вы управляете своими ожиданиями.
Берин Лорич
4
Кажется, здесь есть некоторая путаница между различными уровнями дизайна: системный дизайн и детальный дизайн. Для меня этот вопрос касался подробного проектирования (метод реализации), а не системы (интерфейсы, параллелизм, объем данных, пользовательский интерфейс, тип пользователя).
Гусдор
2
Если вопрос оборачивается «техническим дизайном», то язык и ОС могут иметь некоторые выводы в дизайне. Но все же дизайн не является реализацией. Если вы думаете о возможностях Frameworks, это не дизайн, это внедрение. Если вы основываете свои дизайнерские решения на сильных сторонах фреймворка, подготовьтесь к тому, чтобы страдать от его слабости. И когда слабость отвечает требованиям, у вас возникает огромная проблема. Крупнейшие компании не создавали свои каркасы для удовольствия.
Laiv
1
@Laiv Отличный комментарий! Действительно, это «некоторые и некоторые». Пистолет для гвоздя и винтовой пистолет оба могут крепить вещи, один из них более обратим, чем другой, а также работает медленнее и сложнее. Каждый выбор людей неизбежно является компромиссом. Вы платите свои деньги, и вы рискуете.
1
@RobertPounder, это инструмент, который должен быть определен при разработке системы. Я понимаю, как фреймворки могут влиять на дизайн, но они не должны диктовать это.
Берин Лорич
27

Фреймворки естественным образом влияют на дизайн определенных модулей и подсистем (таких как интерфейс GUI). Как уже упоминалось в другом ответе, вам будет трудно, если вы столкнетесь с выбранными вами рамками.

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

Скорее всего, вы будете использовать много разных фреймворков для решения разных проблем; по мере того как ваша система становится все более сложной, вы должны быть осторожны, чтобы не создавать «Большой шарик грязи» . Где возможно, держите вашу систему модульной и слабо связанной. Некоторые фреймворки лучше оставить за абстракциями, написав оболочки и адаптеры, которые «скрывают» специфичные для фреймворка рабочие процессы от других компонентов. Инструментарий GUI, как правило, обслуживает только интерфейсные функциональные возможности GUI, поэтому эти модули GUI следует хранить отдельно от остальной системы.

Каркасы общего назначения (такие как каркасы пользовательского интерфейса, каркасы уровня данных и т. Д.) Не существуют, чтобы предписывать полную архитектуру вашей системы - в большинстве случаев они могут предписывать разработку компонента или модуля; например, некоторые технологии GUI ориентированы на определенные шаблоны MV *.

Общая архитектура вашей системы должна в первую очередь зависеть от требований вашего бизнеса . Может оказаться, что вы сильно полагаетесь на конкретный инструмент (например, инструмент межплатформенного обмена сообщениями или среду ORM), чтобы связать все воедино, но если вы инкапсулировали среду в абстракцию, такую ​​как класс «сервис», вы менее вероятно, что вы столкнетесь с этой системой, когда столкнетесь с ее ограничениями.

Постарайтесь учесть следующее:

Бен Коттрелл
источник
Иногда кажется, что некоторые авторы фреймворка вообще не против того, чтобы их пользователи писали код приложения в сочетании с фреймворком.
ПРИХОДИТЕ ОТ
2
@COMEFROM - Разработчики поощряют тесную связь вашего кода с фреймворком, потому что они предполагают, что вы выбрали их фреймворк для решения тех же проблем, для которых они его изначально проектировали.
JeffO
Вы немного отошли от темы, переходя от принципов проектирования к принципам кодирования, но я понимаю, что вы говорите, что если бизнес-требование состоит в том, чтобы использовать определенную среду? (думаю, что аутсорсинг компании и внутренние разработчики знают только один язык) Я думаю, мне следовало сделать это более понятным в оригинальном посте.
Роберт Паундер
1
@RobertPounder Реальная мысль, к которой я стремился (возможно, не очень хорошо), заключается в том, что иногда люди склонны использовать определенные платформы в качестве «основы» для всего своего приложения, что неизбежно ведет к бизнес-логике и другим несвязанный код неуместно сливается с этой структурой - например, бизнес-логика в сочетании с элементами управления пользовательским интерфейсом только потому, что в то время она была быстрой и легкой. Это очень легко сделать, так что с чем-то опасаться
Бен Коттрелл
2
Я должен не согласиться с @nocomprende здесь; Не все будущие требования могут быть предсказаны, но иногда системы переписываются просто потому, что предыдущее программное обеспечение слишком сложно расширять / поддерживать .
SeldomNeedy
7

Да, вы должны как можно точнее придерживаться того, что фреймворк «говорит» вам делать.

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

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

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

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

FP
источник
Возможно, вам следует пересмотреть свой ответ из-за изменений в вопросе. Ваш ответ на самом деле не отвечает на вопрос ОП.
17
1
@Laiv Я не понимаю, как это не отвечает на вопрос, хотя это может не соответствовать вашему мнению по теме, это все еще ответ. Вы можете написать свой собственный ответ, чтобы показать противоречивый характер рассматриваемой темы.
FP
Извините, если я не очень хорошо объяснил. Я не так хорошо говорю по-английски, как хотелось бы. Я просто хотел сказать, что, ИМО, вопрос и ваш ответ говорят о разных вещах. Если вы думаете, что нет, это нормально. Я не буду спорить об этом. Вот и все.
Laiv
1
Это абсолютно так. Это похоже на то, как работают предметно-ориентированные языки и похожие идеи. Ваши продукты формируются с помощью инструмента (Framework), а не наоборот. Рамки "выигрывает". Если вы не можете выйти за него замуж, тогда выберите другой. (Подсказка: идеальных рамок не существует. Просто
1
Ваш дизайн должен влиять на то, какую рамку вы выберете (если есть!), А не наоборот.
RubberDuck