Czy powinienem zbudować w pełni funkcjonalną aplikację czy gołe kości, a następnie powoli dodawać funkcje?

Pracuję w zakładzie produkcyjnym, który zlecił działowi IT stworzenie programu planowania produkcji w hali produkcyjnej (co jest bardzo potrzebne). Opierając się na innych doświadczeniach, lepiej byłoby poświęcić mniej czasu i zbudować podstawową strukturę, która będzie użyteczna, a następnie oprzeć ją na tym, dodając funkcje lub zacząć od stworzenia w pełni zaimplementowanego rozwiązania od samego początku. Jestem programistą dopiero od około roku i nie mam dużego doświadczenia w początkowym tworzeniu aplikacji tego rozmiaru. Opierałem się na pomyśle, że pierwszą rzeczą jest aplikacja typu barebones ze względu na ogromną potrzebę jakiegoś rodzaju cyfrowego harmonogramu, ale obawiam się, że dodanie losowych funkcji po tym może być trochę nieporządne. Gdybyś był w tej samej sytuacji, w którą stronę byś się pochylił?

Doświadczenie zdecydowanie prowadzi do zbudowania czegoś małego i prostego oraz dostarczenia go użytkownikom tak wcześnie, jak to możliwe. Dodaj funkcje i możliwości zgodnie z życzeniem użytkowników.

Szanse są bardzo duże (granice z pewnymi), że to, czego chcą / proszą, nie będzie przypominało tego, co sam zbudowałbyś bardzo (jeśli w ogóle).

Jeśli chodzi o rzeczy, które stają się nieporządne, gdy dodajesz do oryginalnej aplikacji: cóż, dlatego Agile (i większość podobnych metod) kładzie duży nacisk na testowanie i refaktoryzację. Refaktoryzacja oznacza czyszczenie kodu podczas wprowadzania zmian, a solidny pakiet testowy (uruchamiany za każdym razem, gdy wprowadzasz zmiany) zapewnia, że ​​jeśli / kiedy wprowadzisz błędy, będziesz o nich wiedział (prawie) natychmiast, tak więc kiedy wydasz coś do Twoi użytkownicy mają wystarczającą pewność, że to faktycznie działa.

Czy masz pojęcie, czy poważnie podchodzą do aplikacji, możesz nie chcieć budować ram itp. Itp.

Musisz jednak znaleźć równowagę. Zwinne programowanie sugeruje, aby na tym etapie skupić się na wymaganiach aplikacji, ale nie oznacza to, że musisz ograniczyć się, zaniedbując podstawowy projekt. Są rzeczy, które można łatwo postrzegać jako nadchodzące (i tak, doświadczenie odgrywa tutaj rolę) i inne, których nie możesz sobie wyobrazić na tym etapie (jestem prawie pewien, że ludzie, którzy poprosili o aplikację, też nie mogą ich sobie wyobrazić).

Nie znam szczegółów aplikacji do planowania, ale mogę sobie wyobrazić, że „rodzaj spotkań” to coś, z czym wkrótce się spotkasz. Być może ludzie nie pytają o to teraz, nie można oczekiwać takiej funkcjonalności.

Podejdę do tego przypadku w następujący sposób: zbudowałbym infrastrukturę (o której wspominasz), tworząc tabelę w bazie danych, aby przechowywać typy spotkań, ale nie zawracałbym sobie głowy tworzeniem interfejsu do dodawania lub wybierania typów. Chciałbym zaprogramować podstawowy typ i przejść do rzeczywistych funkcji. W końcu nikt nie prosił o podanie różnych rodzajów spotkań.

W przyszłości, jeśli ludzie wrócą do ciebie z prośbą o tę funkcję, masz strukturę i po prostu budujesz środek / przód.

Często nie masz wystarczających informacji, aby zbudować początkowo kompletny program. Testy i opinie klientów prawie zawsze ujawniają części twojego początkowego projektu, które nie były tak dobre, jak w teorii.

To powiedziawszy, jeśli problem jest dobrze zrozumiany i początkowo jesteś w stanie napisać kompletny program, jest to lepsze, ponieważ w przeciwnym razie ciągle refaktoryzujesz kod, a wynik rzadko jest tak czysty, jak solidny projekt, który był przestrzegany od samego początku.

Przynajmniej uważam, że ważne jest, aby zastanowić się, jakiego rodzaju program może być potrzebny. W ten sposób możesz go zaprojektować, aby takie funkcje można było łatwo dodać do istniejącej struktury.

Z własnego doświadczenia: zbuduj swój MVP (Minimum Viable Product), a następnie dodaj do niego funkcje na podstawie otrzymanych opinii. Łatwo jest uzyskać mnóstwo funkcji i nikt nie może z nich korzystać.

Ważna jest również wygoda użytkowania, z której korzystasz, aby rozwiązać problem. Sprawdź poprawność przepływu pracy utworzonego przez rzeczywistych użytkowników, a następnie dodaj kolejne funkcje. W ten sposób możesz skupić się na podstawowej wartości, którą budujesz.