Підхід до розробки: вихідний інтерфейс користувача або модель домену?

Хоча я ніколи не постачав нічого, використовуючи Smalltalk, мій короткий час граючи з ним, безумовно, залишив свій слід. Єдиний спосіб описати досвід - це MVC таким, яким він мав бути. По суті, все важке підняття вашої заявки робиться в бізнес-об'єктах (або доменній моделі, якщо ви так схильні). Стандартні елементи певним чином прив’язані до бізнес-об'єктів. Наприклад, текстове поле відображається в полі об’єкта (саме поле є об'єктом, тому це легко зробити). Кнопка відображатиметься до методу. Це все робиться за допомогою дуже простого і природного API. Нам не потрібно думати про прив’язку об’єктів тощо. Це просто працює.

Тим не менш, у багатьох нових мовах та API ви змушені думати ззовні. Спочатку з C ++ та MFC, а тепер із C # і WPF, Microsoft дістала, що світ розробників підключився до будівельників GUI, де ви будуєте свою програму, впроваджуючи обробники подій. . Розробка Java Swing не така вже й інша, лише ви пишете код, щоб самостійно створити елементи керування формою. Для деяких проектів ніколи навіть не може бути доменної моделі - лише обробники подій. Більшість моїх кар’єрів я займався цією моделлю.

Кожен спосіб змушує вас думати інакше. З підходом Smalltalk ваш домен розумний, а ваш GUI - німий. З підходом VisualStudio за замовчуванням ваш графічний інтерфейс розумний, тоді як ваша доменна модель (якщо вона існує) досить анемічна.

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

Отже, яким чином ви розробляєте / розробляєте свій код? Чому?

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

Для будь-якого підходу є плюси і мінуси. Модель домену вписується в кришталеві собори та пиріг на небі. Графічний інтерфейс підходить для швидких і брудних (іноді дуже брудних).

І для додаткового бонусу: Як ви переконаєтесь, що код є ремонтом?

Ні

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

Дозвольте мені зробити цифру, щоб зробити це поняття зрозумілим:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

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

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

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

Домен спочатку. Мені потрібно переконатися, що система правильна, перш ніж поставити на неї інтерфейс.

Нічого іншого не можна змусити працювати - крім простих випадків.

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

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

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

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

Це дійсно залежить від програми.

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

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

Часто запізнення, що стосується натискання невеликих ітеративних циклів у розвитку (Scrum, Kanban тощо), передній і задній кінці роблять паралельно. Йдеться про надання того, що вам потрібно для цієї ітерації; нехтуючи побудовою, якщо нам потрібен підхід . При паралельному підході обидва кінці залишаються набагато ближчими протягом усього розвитку, що може полегшити потребу в постійній зміні, коли передній і задній кінці зливаються. Це мій кращий підхід, коли це можливо.

Ви згадали ...

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

Не знаєте, що ви маєте на увазі під деякими ? І WPF, і SL відзначаються своєю функціональністю зв'язування. Це нескінченно. Якщо вас змушують розміщувати код у програмі View у програмі WPF на базі MVVM, тоді щось потрібно вирішити. Додані форми поведінки - це один із способів реалізувати поведінку, не втручаючись у події всередині Перегляду, а також багато інших підходів до забезпечення того, щоб Ваш Перегляд залишався в чистоті.

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

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

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

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

Зважаючи на це, ми дуже обережні, щоб тримати бізнес-логіку окремо від інтерфейсу користувача.

Я пам’ятаю, колись навіть провідний розробник кричав на мене, що архітектура Document / View вважалася застарілою, коли я запропонував нам припинити зв'язувати весь наш бізнес-код з інтерфейсом користувача (і ми використовували win32 в C ++ у той час, тому це програвання перетягування річ навіть не була нашою проблемою). Я просто ошелешив.

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

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

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

Звичайно, спочатку домен!

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

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