Czy przydatne może być zbudowanie aplikacji zaczynającej się od GUI?

Trend projektowania i tworzenia aplikacji wydaje się zaczynać od „odwagi”: domeny, następnie dostępu do danych, następnie infrastruktury itp. GUI wydaje się zwykle pojawiać później. Zastanawiam się, czy najpierw może być przydatne zbudowanie GUI ...

Moim uzasadnieniem jest to, że budując przynajmniej prototypowy interfejs GUI, zyskujesz lepsze pojęcie o tym, co musi się wydarzyć za kulisami, a zatem masz lepszą pozycję do rozpoczęcia pracy w domenie i obsługi kodu.

Widzę problem z tą praktyką polegający na tym, że jeśli kod pomocniczy nie został jeszcze napisany, warstwa GUI nie będzie miała wiele do zrobienia. Być może budowanie fałszywych obiektów lub wyrzucanych klas (podobnie jak w testach jednostkowych) zapewniłoby wystarczającą podstawę do zbudowania GUI na początku.

Czy to może być realny pomysł na prawdziwy projekt? Może moglibyśmy dodać GDD (GUI Driven Development) do stabilnego akronimu ...

Budowanie szybkich prototypów GUI to dobry pomysł i słyszałem, że jest on wykorzystywany w wielu projektach. Wczesne opinie są naprawdę cenne. Ma jednak swoje niebezpieczeństwa:

• bardzo kuszące (dla menedżerów / użytkowników) jest dalsze używanie prototypowego kodu i budowanie na nim końcowej aplikacji, co może mieć bardzo złe długoterminowe konsekwencje (tak naprawdę stało się to w jednym z projektów, nad którymi pracowałem, i spowodowało „działający” produkt o nieistniejącej architekturze i wielu problemach związanych z konserwacją)
• dla przeciętnego użytkownika GUI to aplikacja . Tak więc, kiedy zobaczą ładnie wyglądający interfejs GUI, mają skłonność wierzyć, że większość faktycznej pracy została wykonana, więc mogą bardzo się denerwować, że „pozostała praca” ciągnie się tak długo: - /

Ograniczanie tych zagrożeń wymaga aktywnej dyskusji i ewentualnie edukacji użytkowników i / lub menedżerów.

Problem w tym, co widzę, polega na tym, że cel wydaje się całkowicie zacofany.

„Moim uzasadnieniem jest to, że budując przynajmniej prototypowy interfejs GUI, zyskujesz lepsze pojęcie o tym, co musi się wydarzyć za kulisami, a zatem masz lepszą pozycję do rozpoczęcia pracy w domenie i obsługi kodu”.

Jest to, moim zdaniem, niewłaściwy sposób patrzenia na warstwę biznesową i WIELKI sposób na znalezienie złego, niewykonalnego projektu. Warstwa danych, która jest dobrze zaprojektowana do pełnego wyrażania danych, może być używana w dowolnym interfejsie użytkownika. Warstwa danych zaprojektowana do pracy na potrzeby konkretnego interfejsu użytkownika może nie być przystosowana do niczego innego, nawet drobnych dodatków do tego interfejsu użytkownika.

Doświadczenie z systemami zaprojektowanymi tak, jak mówisz, doprowadziły mnie do wniosku, że większość projektów wykorzystujących tę metodologię kończy się krótko i / lub jest zbyt skomplikowana. Mają też tendencję do tworzenia sprzężenia między interfejsem użytkownika a warstwą danych, która nigdy nie powinna istnieć.

Należy wspierać niezależność warstwy danych i warstwy interfejsu użytkownika. Właśnie dlatego budowanie warstwy danych w taki sposób, aby po prostu reprezentowała całe dane, a nie do kierowania na konkretny interfejs użytkownika, po prostu działa lepiej na dłuższą metę.

Zbudowanie prototypu może być przydatne do zbierania wymagań i uzgadniania, ale należy je wyrzucić. W rzeczywistości nie używaj niczego z kodu prototypowego w prawdziwym produkcie.

Myślę, że @ Péter słusznie sugeruje, że budowanie prototypów GUI to dobry pomysł. Chciałbym uzupełnić potencjalne pułapki związane z zapewnieniem wrażenia użytkownika w sposób wsteczny, to znaczy skupiając się najpierw na ontologiach, architekturze i infrastrukturze, a także na bezpośrednim doświadczeniu użytkownika:

• Użytkownik, którego wysłałeś na koniec osi czasu programowania, unieważnia twoje oszacowania danych i sposób użycia aplikacji.
• Twoje skomplikowane projekty, które opracowałeś przedwcześnie, okazują się być samosprawnymi machinacjami, które w końcu są bardzo mało lub nie mają żadnego zastosowania.
• Twoja aplikacja może zostać doprowadzona do takiego stanu, w którym dostarczanie złych wrażeń użytkownikom stanie się normą.

Robisz odwagę, a następnie użytkownik dostaje to, co wyszło z twoich założeń, podczas gdy powinieneś martwić się tym, czego potrzebuje użytkownik i odpowiednio budować wnętrzności. Dlaczego ludzie uciekają się do robienia tego na odwrót, to po prostu dlatego, że prezentacja, z którą użytkownik wchodzi w interakcje, skąd zachowania aplikacji naturalnie się powiększają, jest najbardziej złożoną częścią systemu, która nigdy nie jest w pełni poznana lub ludzie po prostu czują się bardzo zadowoleni z budowania rzeczy unikając faktycznego zastanowienia się, dlaczego / dla kogo to budują. Wznoszenie ogromnej struktury, która jest strukturalnie solidna, jest dziecinnie proste, najtrudniejszą częścią jest zaspokojenie potrzeb funkcjonalnych (i estetycznych) wszystkich.

Dla każdego doświadczenia craptastic, dziwaczny przepływ, źle skolokowane informacje, brak oczywistej funkcjonalności, rzeczy, które są po prostu złe, przypadki, kiedy prosisz o pytanie „który geniusz wymyślił to ?”, Leży coś, co ignorujesz, negujesz lub ujawnił użytkownika jako główny element prac rozwojowych.

Zasadniczo model należy opracować przed widokiem. Po stworzeniu logicznej podstawy aplikacji możesz zbudować jeden lub więcej widoków tego modelu (na przykład możesz wyświetlać dane w tabeli lub na wykresie). Zazwyczaj model jest ważniejszy niż GUI. Jest to szczególnie prawdziwe w przypadku rozwoju przedsiębiorstwa, w którym GUI jest zwykle wykonywane w standardowy sposób.

Czasami jednak GUI jest naprawdę najważniejszą częścią aplikacji. Czasami chcesz spojrzeć na dane w nowatorski i konkretny sposób - i wziąć je stamtąd, a następnie opracować model. Na przykład CashCurve to taka aplikacja, w której chodzi o GUI, podczas gdy sam model danych jest standardową nudną rzeczą, którą każdy może wymodelować w ciągu kilku minut. (Oświadczenie: Nie jestem związany z CashCurve, tylko bardzo zadowolony użytkownik.)

Jest to istotne również przy projektowaniu usług internetowych lub innych interfejsów API - tylko tam jest znany jako „ pierwszy kontrakt ”.

Tak więc, jeśli chodzi o wszystko, nie ma reguły, co najpierw zaprojektować; czasami jest to model, a czasem GUI. Zasadniczo wybrałbym „najpierw zaprojektuj najważniejszą część”.

Podczas projektowania GUI należy wziąć pod uwagę pewne zastrzeżenia, na przykład ten użytkownik prawdopodobnie będzie miał problem ze zrozumieniem, że aplikacja jest daleka od ukończenia, gdy istnieje tylko prototyp GUI, ale inne odpowiedzi opisały to całkiem dobrze, więc nie będę wchodził w szczegóły.

Myślę, że jest to bardzo dobry sposób podejścia do projektowania aplikacji, szczególnie w zwinnym środowisku programistycznym. Większość udanych projektów, nad którymi pracowałem, rozpoczęła się od prototypu, który ostatecznie stał się rzeczywistością.

Musisz zrozumieć, że GUI jest oknem do systemu (np. Baza danych, system plików itp.). W sytuacji, gdy wymagania dotyczące projektu są tak niejasne jak kupa błota, nie będziesz miał piekła nadziei na znalezienie właściwego rozwiązania, zaczynając od backendu. Prawie zawsze dobrze poinformowany programista opracowuje pakiet API, który nie ma związku z interakcjami użytkownika.

Zaczynając od GUI, klient uzyskuje lepszy obraz tego, czego chce. W miarę postępu tego etapu opracowanie GUI (przy użyciu makiet i kodów pośredniczących) rodzi model domeny. Ten model domeny można następnie przenieść do zaplecza, a programiści zaplecza mogą rozpocząć opracowywanie logiki trwałości i transakcji.

I dlaczego chcesz wyrzucić protoype'a? Nie mamy do czynienia ze stadionami zbudowanymi z zapałek. Po prostu przekształć to cholerstwo w coś dobrego.

Nie brzmi dla mnie źle, jeśli osoba patrząc na GUI rozumie, że to tylko powłoka i dosłownie przyciski i procesy nie działają (wyrzuć nowy NotImplementedException ();;)).

Jeśli pozostaniesz przy użyciu architektury w stylu MVC, nie przewiduję żadnych przyszłych problemów konserwacyjnych lub konstrukcyjnych, ponieważ „Widok” w ogóle nie definiuje tego rodzaju rzeczy. „Kontrolery” i „Model” mogą pojawić się później z dowolną infrastrukturą wymaganą do skalowalności / potrzeb projektowych itp.

Jeśli chodzi o zarządzanie, narysuj duży wykres kołowy z 3 porcjami, oznacz je „M”, „V” i „C”. Podaj V około 20% i wyjaśnij, że reszta ciasta to „TBC”;).

W każdym systemie o rozsądnych rozmiarach to, co musi się stać za kulisami, jest luźno powiązane z tym, jak wygląda GUI. GUI da ci tylko niektóre wymagania. Często istnieje wiele komponentów, które nie mają GUI.

Po opracowaniu systemu mogą być wymagane dodatkowe interfejsy (w tym nowe GUI). Zrozumienie i wdrożenie wymagań biznesowych ma zasadnicze znaczenie dla powodzenia.

Podczas projektowania GUI i innych mechanizmów wejściowych i wyjściowych może pomóc walidacja modelu. Atrybuty, które nigdy nie są generowane, mogą nie być wymagane. (Mogą istnieć powody, aby je zachować, ale prawdopodobnie będą to wymagania audytu lub regulatora).

Jak wspomnieli inni, gdy masz już działający GUI, wielu klientów pomyśli, że skończyłeś. Możesz jednak nie mieć za sobą żadnej infrastruktury. Papierowe prototypy mogą być dobrym rozwiązaniem do sprawdzania poprawności układu i zawartości GUI.

Nie zapominaj, że po opracowaniu może być konieczne dostosowanie interfejsu. Słyszę raport o nieudanej zamianie interfejsu kasy na pięciostopniowy proces kasy. Znacznie prostszy interfejs nie dawał użytkownikom odpowiedniego poczucia bezpieczeństwa i miał znacznie niższy wskaźnik ukończenia. Słuchaj Speed ​​Bumps: magiczny składnik w marketingu .