Розробляючи систему, чи найкраще застосовувати дизайн у рамках, які ви будете використовувати?

Розробляючи систему чи додаток, який ви плануєте використовувати з певним фреймворком, чи найкраща практика проектувати систему без фреймворку на увазі, чи краще проектувати систему з розумом "добре, що рамки мали б простіший час з цим".

development-process systems

— Роберт Пундер
джерело

Про яку рамку ви говорите? Ви маєте на увазі якусь конкретну бізнес-структуру, яка призначена для вирішення дуже доменних проблем для певної галузі? (наприклад, медичні, ядерні, оборонні, авіаційні тощо). Або ви говорите про рамки загального призначення, розроблені для вирішення технічних проблем?

— Бен Коттрелл

рамки загального призначення, розроблені для вирішення технічних проблем

— Роберт Пуендер

Невеликий масштаб через брак часу (я працюю, можливо, розробимо пізніше): я пишу систему, яка створює електронні листи на основі дизайнів. - Якби я писав це в Laravel, я б, ймовірно, пішов би про використання їх шаблону "леза" для проектування електронних листів, що зробить проектування системи набагато простішим з точки зору потоку. Однак мені доведеться зайнятися написанням двигуна для шаблонів, якби я робив це PHP ванілі або знаходив іншу підходящу альтернативну систему шаблонів. Це додало б процесу проектування, про яке також йдеться в питанні.

— Роберт Пуендер

Це питання дасть купу абсолютно різних відповідей, оскільки і "рамка", і "дизайн" - це слова, перевантажені численними значеннями в нашій галузі. Крім того, навіть для єдиного визначення фреймворку як "загальнообов'язкових рамок, розроблених для вирішення технічних проблем", це залежатиме від конкретних рамок - деякі рамки більш виразні, ніж інші.

— stannius

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

Відповіді:

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

Досвід користувача
Функціональність
Як спілкуються фрагменти вашої програми (як із собою, так і із зовнішніми організаціями)

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

Вибравши відповідний набір інструментів (рамка - це інструмент), я рекомендую використовувати інструменти так, як вони призначені для використання. Чим далі ви відхиляєтесь від дизайну рамки, тим більше ви збільшуєте криву навчання для своєї команди і тим більше шансів, що щось піде не так.

Коротко

Дизайн для ваших користувачів
Підберіть відповідні інструменти для досягнення вашого дизайну
Використовуйте свої інструменти так, як вони призначені для використання

Подальші думки:

Після 20+ років інженерії програмного забезпечення та використання декількох рамок я засвоїв пару уроків. Усі рамки є двогранним мечем: вони і стримують, і дозволяють. Проблема з вирішенням вашої основи, перш ніж дивитися на велику 3, про яку я згадував вище, полягає в тому, що ви можете порушити хороший досвід користувача для посереднього (у кращому випадку). Або ви, можливо, будете змушені відходити від дизайну рамки, щоб досягти певної функціональності.

— Берін Лорич
джерело

Тоді вам потрібно провести певні переговори з клієнтом. Поясніть, що ви можете, а що не можете зробити з накладеними ними обмеженнями. Запропонуйте, як це може змінитися, якщо ви виберете X frame. Вони можуть не бажати змін і готові жити з деградованим досвідом. Або вони можуть вирішити, що ви знаєте, що ви робите, і вам довіряють. Це залежить від клієнта. Зрештою, ви керуєте їхніми очікуваннями.

— Берін Лорич

Тут, мабуть, існує певна плутанина між різними рівнями дизайну: дизайном системи та детальним дизайном. Для мене це питання ставило питання про детальну конструкцію (метод реалізації), а не про систему (інтерфейси, паралельність, обсяг даних, інтерфейс користувача, тип користувача).

— Гусдор

Якщо питання обертається "технічним дизайном", то мова та ОС можуть мати певні умовиводи в дизайні. Але все-таки дизайн - це не реалізація. Якщо ви думаєте про можливості Frameworks, це не дизайн, це реалізація. Якщо ви базуєте свої дизайнерські рішення на основі сильних рам, підготуйтеся до того, що будете страждати на його слабкість. І коли слабкість відповідає вимогам, у вас виникає величезна проблема. Найбільші компанії не будували своїх каркасів для задоволення.

— Лаїв

@Laiv Чудовий коментар! Дійсно, це "деякі і деякі". І цвяховий пістолет, і гвинтовий пістолет можуть скріплювати речі, один є більш оборотним, ніж інший, а також працює повільніше і складніше. Кожен вибір, який люди роблять, неминуче є компромісом. Ви платите свої гроші, і ви ризикуєте.

@RobertPounder, Це інструмент, про відповідність якогось рішення потрібно вирішити під час проектування системи. Я розумію, як рамки можуть впливати на дизайн, але вони не повинні його диктувати.

— Берін Лорич

Рамки природно впливають на дизайн конкретних модулів та підсистем (таких як інтерфейс GUI). Як згадується в іншій відповіді, вам буде важко, якщо ви опинитеся на боротьбі з обраними рамками.

Однак, ширше, вам слід уникати того, щоб якийсь єдиний фреймворк чи технологія диктували чи керували «великою картиною» вашої загальної архітектури системи. Більшість рамок прикладних програм загального призначення не заохочують це, тому якщо ви виявите, що ви пишете всю свою систему навколо однієї рамки, то, ймовірно, ви робите те, чого автори цієї рамки не мали наміру.

Ви, ймовірно, використовуєте багато різних рамок для вирішення різних проблем; Оскільки ваша система стає складнішою, ви повинні бути обережними, щоб не створити Велику кульку бруду . Де це можливо, тримайте систему модульною і нещільно пов'язаною. Деякі рамки можуть бути краще зберегти за абстракціями, написавши обгортки та адаптери, які "приховують" робочі потоки, що стосуються рамки, від інших компонентів. Набори інструментів GUI, як правило, обслуговують лише функціональний інтерфейс GUI, тому ці модулі GUI слід тримати подалі від решти системи.

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

Загальна архітектура вашої системи повинна орієнтуватися насамперед на ваші бізнес-вимоги . Ви можете сильно опиратися на певний інструмент (наприклад, інструмент проміжного програмного забезпечення для обміну повідомленнями або рамку ORM), щоб зв'язати все разом, але якщо ви зафіксували рамку в абстракції, такому як клас "служби", менше шансів на те, що ви будете обмежені цією рамкою, коли зіткнетеся з її обмеженнями.

Спробуйте пам’ятати про наступне для вашого дизайну великих зображень:

Мета створення модульного програмного забезпечення
Враховуйте розділення проблем при написанні кожного модуля та компонента
Розгляньте багаторівневу архітектуру, щоб розділити систему на шари
Не будуйте хиткі абстракції
Скорочення на це пов’язане питання : На що класифікуються DRY, KISS, SOLID тощо?

— Бен Коттрелл
джерело

Іноді здається, що деякі автори фреймворків зовсім не заперечують, щоб їхні користувачі писали код програми щільно в поєднанні з рамкою.

— ВІД

@COMEFROM - Щільне з'єднання вашого коду з рамкою розробникам буде заохочене, оскільки вони припускають, що ви вибрали їх фреймворк для вирішення тих самих проблем, що і для нього.

— JeffO

Ви трохи пішли з теми, переходячи від принципів дизайну до принципів кодування, але я розумію те, що ви говорите, що робити, якщо вимога бізнесу полягає в тому, щоб використовувати певні рамки? (гадаю, що компанія, яка перебуває в службі, і внутрішні розробники знають лише одну мову) Я думаю, що я повинна зробити це ясніше в оригінальній публікації.

— Роберт Пуендер

@RobertPounder Справжній момент, на який я намагався домогтися (можливо, не дуже добре), полягає в тому, що іноді існує тенденція в тому, щоб люди використовували певні рамки як «заземлення» для всього свого застосування - що неминуче призводить до логіки бізнесу та іншого невідповідний код невідповідно приєднаний до цієї рамки - наприклад, бізнес-логіка поєднується з елементами управління інтерфейсом просто тому, що на той час це було швидко. Зробити це дуже просто, тож варто насторожитися

— Бен Коттрелл,

Я повинен не погодитися з @nocomprende тут; не всі майбутні вимоги можна передбачити, але іноді системи переписуються просто тому, що попереднє програмне забезпечення надто складно розширити / підтримувати .

— SeldomNeedy

Так, ви повинні якомога ближче дотримуватися того, що рамки "підказують" вам робити.

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

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

Єдина вагома причина, з якої я можу подумати, чому ви "зламаєте" рамки, - це те, що вам абсолютно потрібно щось, чого він не може забезпечити, враховуючи його "за замовчуванням" конфігурацію / застосування принципів. Але тоді це може бути не правильною основою для початку.

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

— ПП
джерело

Можливо, вам слід переглянути свою відповідь через зміни запитання. Ваша відповідь насправді не відповідає на питання ОП.

— Лаїв

@Laiv Я не бачу, як це не відповідає на запитання, хоч це може не відповідати вашій думці по темі, це все-таки відповідь. Ви бажаєте написати власну відповідь, щоб відобразити суперечливий характер відповідної теми.

— FP

Вибачте, якщо я не пояснив себе добре. Я не так добре володію англійською мовою, як хотілося б. Я просто хотів сказати, що, ІМО, питання та ваша відповідь говорять про різні речі. Якщо ви думаєте, що вони цього не роблять, це нормально. Я не заперечуватиму це. Це воно.

— Лаїв

Це абсолютно все. Це схоже на те, як працюють доменні мови та подібні ідеї. Ваші вироби формуються інструментом (Framework), а не навпаки. Рамка "виграє". Якщо ви не можете одружитися, виберіть інше. (Підказка: немає ідеального фреймворку. Просто говорять.)

Ваша конструкція повинна впливати на обрані вами рамки (якщо такі є!), А не навпаки.

— RubberDuck