Як ви пояснюєте поділ турбот для інших?


33

Якби у вас був колега, який не розумів переваг розділення турбот або не зрозумів достатньо, щоб послідовно застосовувати їх у своїй щоденній роботі, як би ви їм це пояснили?


Знайшов кілька хороших прикладів у Вікіпедії: en.wikipedia.org/wiki/Separation_of_concerns
AliN11

Відповіді:


47

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

  1. скільки коду вам доведеться змінити
  2. як легко вносити зміни
  3. наскільки ймовірно, ви зламаєте існуючі функції, якими користуються інші клієнти
  4. скільки ви можете повторно використовувати існуючу модель / архітектуру

Розділення проблем допоможе вам отримати більш позитивні відповіді на ці питання.

  1. якщо весь код для певної поведінки програми відокремлений, вам доведеться лише змінити код, безпосередньо пов'язаний з вашою новою функцією. Який повинен бути менший код для зміни.
  2. якщо поведінка, яка вас зацікавила, акуратно відокремлена від решти програми, швидше за все, ви зможете помінятися новою реалізацією без необхідності повністю розуміти або маніпулювати рештою програми. Слід також простіше з’ясувати, який код потрібно змінити.
  3. Код, який вам не потрібно змінювати, є менш шансом зламатись, ніж код, який ви змінюєте. Тож розділення проблем допоможе вам уникнути поломки непов'язаних функцій, не дозволяючи вам змінювати код, який вони можуть викликати. Якщо ваші риси змішані разом, ви можете змінити поведінку одного випадково, намагаючись змінити інший.
  4. Якщо ваша архітектура спричиняє деталі технічної чи ділової логіки, то для внесення змін у реалізацію менше ймовірно, що потрібні нові архітектурні функції. Наприклад, якщо ваша основна логіка домену - агностична база даних, підтримка нової бази даних повинна бути настільки ж простою, як і заміна новою реалізацією шару збереження.

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

10

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

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


5

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


1

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

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


-3

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

Інший підхід полягає в тому, щоб поєднати всі ваші CSS-файли JavaScript і HTML в групу компонентів або модулів. Це означає, що ви можете внести зміни в один модуль, і це не повинно впливати на інші компоненти або модулі на сторінці, які він працює поряд із стороною, які не пов'язані між собою. Тут файли css, js та html об'єднуються в єдиний компонент, який можна перевірити одиницею. Таким чином, розділення проблем відбувається у вигляді окремих атомних компонентів, які можуть бути перевірені, а не розділення елементів розмітки, стилів та поведінки. Цей другий підхід більше підходить для створення більш складних веб-додатків.

редагувати. Оскільки я отримав негативну відповідь на цей коментар, я подумав, що перегляну його та спробую кваліфікувати частину свого pov. На жаль, будь-який зворотний зв'язок тут не особливо конструктивний, але я побачив цікаву дискусію в іншому місці, де розглядається React, поточна гаряча технологія в веб-розробці, приклад реального світу, і запитує, чи порушує вона розділення проблем або, зокрема, якщо вона порушує одну з принцип методології проектування об'єкта SOLID від Feather.

Технічна перспектива розробника JavaScript

NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own      architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.

Перспектива дизайнера UX / UI

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.

Командна перспектива

NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working    directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

Також на сторінці розміщено посилання на цікаву презентацію від Піта Ханта з Facebook, де він розповідає про компоненти, а не про шаблони, та про відокремлення проблем у мовному додатку, а не про розмежування проблем, тобто про шаблони, css та javascript тощо.

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

Отже, підводячи підсумок, відокремлення проблем може залежати від вашої ролі чи точки зору, як уже згадувалося де.


1
це, здається, не пропонує нічого суттєвого щодо питань, викладених та пояснених у попередніх 7 відповідях
gnat

Я просто вказую, що відокремлення проблем може застосовувати різні підходи залежно від контексту. Це наближається до реальної ситуації у галузі розробки програмного забезпечення, і я підкреслюю, що існують різні підходи до роботи над html-сторінками, які спочатку можуть здатися суперечливими.
Даніель
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.