Чи може бути корисно скласти додаток, починаючи з GUI?

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

Моє обгрунтування полягає в тому, що, будуючи принаймні прототип GUI, ви отримуєте краще уявлення про те, що має відбуватися за кадром, і тому ви в кращому стані для початку роботи над доменом і підтримуючим кодом.

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

Це може бути реальною ідеєю для реального проекту? Можливо, ми могли б додати GDD (GUI Driven Development) до стабільної абревіатури ...

Створення швидких прототипів графічного інтерфейсу - хороша ідея, і я чув, що він використовується в багатьох проектах. Ранні відгуки справді цінні. Однак це має свої небезпеки:

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

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

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

"Моє обгрунтування полягає в тому, що, будуючи принаймні прототип GUI, ви отримуєте краще уявлення про те, що має відбуватися за кадром, і тому ви в кращому стані для початку роботи над доменом і підтримуючим кодом."

Це, на мій погляд, неправильний погляд на бізнес-шар та ВЕЛИКИЙ спосіб знайти поганий, незрозумілий дизайн. Шар даних, який добре розроблений для повного вираження даних, може бути використаний у будь-якому інтерфейсі. Рівень даних, призначений для роботи для певного інтерфейсу, може не пристосовуватися ні до чого іншого, навіть до незначних доповнень функцій до цього інтерфейсу.

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

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

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

Я думаю, що @ Péter правильно вважає, що побудова прототипів GUI - це гарна ідея. Я хотів би доповнити можливі підводні камені, що забезпечують користувальницьку роботу на заднім шляху, тобто зосереджуючи увагу на онтологіях, архітектурі та інфраструктурі спочатку та негайному досвіді користувача останнім часом:

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

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

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

Взагалі модель повинна бути розроблена перед переглядом. Після того, як у вас є логічне підґрунтя вашої програми, ви можете створити один або кілька представлень цієї моделі (наприклад, ви можете відображати дані в таблиці або в графіку). Зазвичай модель важливіша за GUI. Особливо це стосується розвитку підприємств, де графічний інтерфейс зазвичай робиться стандартним способом.

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

Це актуально і для розробки веб-служб або інших API - тільки там він відомий як " договір перший " дизайн.

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

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

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

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

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

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

Мені це зовсім не погано звучить, якщо людина, що дивиться на графічний інтерфейс, розуміє, що це просто оболонка і буквально кнопки та процеси не працюють (киньте нове NotImplementedException ();;)).

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

Що стосується управління, намалюйте їм велику кругову діаграму з 3-х порцій, позначте їх "M", "V" та "C". Дайте V приблизно 20% і поясніть решту пирога "TBC";).

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

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

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

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

Не забувайте, що після розробки вам може знадобитися налаштувати інтерфейс. Я чую повідомлення про невдалу заміну інтерфейсу каси для п’ятиступенькового процесу оформлення замовлення. Набагато простіший інтерфейс не надав користувачам належного відчуття безпеки та мав значно нижчий рівень завершення. Слухайте Speed ​​Bumps: Чарівний інгредієнт у маркетингу .