Ok, natknąłem się na to wiele razy, ale tutaj jest scenariusz z najgorszym przypadkiem, nieco przesadzony.
Klient mówi „hej, czy możesz zrobić z nas ten mały moduł do wykonania tego małego zadania”?
Ja: „Nie ma problemu”.
Opierając się na budżetach i ograniczeniach itp., Pomijam trochę architektury i nurkuję od razu i nie spocę się.
Następnie proszą o kolejny moduł. I kolejny. I kilka ulepszeń. A wszystko to dzieje się bardzo powoli, z biegiem lat. I zanim się zorientujesz, masz tę potworną aplikację, która jest okropnie zaprojektowana.
Co robisz, gdy zostaniesz poproszony o zrobienie czegoś małego? Nie wiesz, czy będzie rosło ... czy klient będzie ciągle prosił o dodatki (i nie zrobi tego).
Nie można przesadzić z architekturą, ponieważ jest to w końcu tylko niewielka aplikacja, a oni pójdą gdzie indziej, jeśli powiecie (w tym, że znam cały głos) „Na wszelki wypadek, zróbmy tę architekturę warstwami -O-line bezpieczeństwo i rozdzielanie obaw. W rzeczywistości chodźmy z narzędziem do wstrzykiwania zależności, które naprawdę sprawi, że będzie to fantastyczne bla bla bla ".
Powiedzą „tak, dobrze” i pójdą do kogoś innego.
Budżet, czas i postrzeganie są tak samo ważne jak architektura samej aplikacji.
Jak do tego podejść?
Sądzę, że pytanie naprawdę sprowadza się do: „Kiedy nie masz wszystkich informacji na temat ostatecznego wyniku czegoś, co wydaje się być małą aplikacją, jak możesz uniknąć (lub złagodzić) wczesne podejmowanie decyzji architektonicznych i projektowych, co będzie całkowicie innapropriate później?