Jaka jest różnica między prototypem a rozwiązaniem na poziomie produkcji?

To pytanie ma wyłącznie na celu naukę i zwiększenie mojego technicznego zrozumienia. Wiem, że nie ma idealnego rozwiązania i to pytanie może mieć niekończącą się listę rozwiązań, ale myślę, że dla każdego architekta bardzo ważne jest zrozumienie różnicy między wersją demonstracyjną a projektem na żywo.

W przeszłości stworzyłem wiele rozwiązań demonstracyjnych w .Net. Teraz zostałem przydzielony do architekta i wdrożenia rozwiązania sieciowego na poziomie produkcyjnym, więc chciałem zapytać - na bardzo wysokim poziomie, co jest potrzebne do przekształcenia wersji demo w rozwiązanie na poziomie produkcyjnym. Z mojego zrozumienia wymaga to (innego niż funkcjonalne wdrożenie wymagań klientów):

1. Testowanie jednostkowe każdej metody
2. Osiągnięcie ~ 100% zasięgu kodu
3. Rejestrowanie wszystkich wyjątków i możliwych skrótów - możliwe z AOP
4. Korzystanie z wzorca projektowania interfejsu, wstrzykiwanie zależności, być może przy użyciu frameworka, np. Spring.net
5. Korzystanie z liczników wydajności i profilerów do oprzyrządowania
6. Stosowanie odpowiednich zabezpieczeń - tj. Uwierzytelnianie systemu Windows (jeśli tego wymaga klient).
7. Zarządzanie transakcjami każdą metodą
8. Wykonaj kopię zapasową plików aplikacji sieci Web przed nowym wdrożeniem rozwiązania

Co jeszcze?

Moje pytanie jest bardziej związane ze stroną techniczną niż z funkcjonalnością / dokumentacją, ponieważ w przeciwnym razie przejdziemy inną ścieżkę :-)

Dziękuję Ci.

Myślę, że najważniejszą różnicą jest to, że celem prototypu jest:
1. Udowodnienie, że problem można rozwiązać w określony sposób LUB
2. Daj klientowi / kierownictwu poczucie, jak będzie wyglądał produkt

mając na uwadze, że celem systemu na żywo jest:
1. Rozwiązanie określonego problemu / rozwiązanie problemu.

Zauważ, że cele tych dwóch są całkowicie różne .
Dlatego moim zdaniem prototyp powinien zostać wyrzucony przed opracowaniem systemu na żywo .

Wynika to również z faktu, że prototyp jest zwykle „szybkim i brudnym” projektem, zrzucanym razem bez żadnych uwag, które słusznie wskazałeś w swoim pytaniu (takich jak testowanie, wydajność, bezpieczeństwo i wiele innych).
Lepiej więc zacznij nowy, właściwy projekt, niż próbować ulepszyć zły projekt.

Nie wszystkie z tych rzeczy są wymagane, w zależności od wymagań, lub może być o wiele więcej. Jeśli wiesz, co mam na myśli;) Testowanie jednostek i pokrycie kodu to dobre rzeczy, ale w zależności od tego, jak postępujesz w innych częściach procesu, może nie być wymagane. Niektórzy twierdzą, że ważniejszy niż profilowanie wydajności jest dobrze udokumentowany kod lub podręcznik szkoleniowy. To się zmienia!

Zdaję sobie sprawę, że patrzysz na stronę techniczną, ale mam nadzieję, że zrozumiesz mój punkt widzenia, różni się on w zależności od strony nietechnicznej. A przynajmniej powinno.

Korzystanie z liczników wydajności i profilerów do oprzyrządowania może być odpowiednie, ale może być nadmiernie nadmierne. Może nie być wymagane.

To, czego tu brakuje, nie uwzględnia kontekstu, zakresu i wymagań biznesowych projektu.

Mam na myśli kontekst i zakres - czy tworzysz coś, z którego firma będzie mogła korzystać wewnętrznie? W obliczu klienta? Używane przez użytkowników końcowych? Czy to w rzeczywistości jazzowa wersja Notatnika, czy nowy RDBMS od zera? To, co powinno zostać uwzględnione, będzie się znacznie różnić (masowo!) W zależności od projektu, na który patrzysz.

Przez wymagania biznesowe nie mam na myśli przypadków użycia oprogramowania, ale wymagania dotyczące zarządzania projektem / procesu produkcyjnego. Jeśli nalegasz, abyś potrzebował wszystkich tych rzeczy do projektu produkcyjnego, koszt zostanie odpowiednio odzwierciedlony (bardzo wysoki). Może to oznaczać, że budżet się skończył, spóźnia lub nawet nie daje zielonego światła, aby rozpocząć rozwój.

Być może ważniejsze niż posiadanie ustalonego zestawu kryteriów jest po prostu dobre ramy produkcji / rozwoju, widoczność i regularne wydania, aby w ten sposób można było ocenić jakość. Może się zdarzyć, że nikt nie będzie bzdurny na temat zasięgu kodu.

Co ciekawe, myślę, że punkty 1, 2, 4 i 7 powinny już zostać wykonane podczas koncepcji twojego prototypu, z tym wyjątkiem, że nie sądzę, że powinieneś testować każdą metodę w każdej klasie. Przetestuj kod krytyczny, a nie sprawdzaj, czy metody get / set zachowują się poprawnie.

W zależności od celu aplikacji, gdzie bezpieczeństwo stanowi duży problem, punkt 6 może być na tyle krytyczny, że trzeba go osiągnąć w prototypie. W zależności od celu twojej aplikacji, gdzie wydajność jest kluczem, punkt 5 może być krytyczny ... Wiesz o co mi chodzi. Moim zdaniem, punkty 3, 5 i 6 mogą być konieczne w prototypie, jeśli zostaną uznane za krytyczne (punkt 8 jest naprawdę ważny dla aplikacji produkcyjnych)

Edycja: wydaje się, że moja opinia różni się całkowicie od sJhonny'ego, ponieważ sugeruję, że uważam prototyp za podstawę / powłokę / szkielet twojego przyszłego rozwoju, więc dla mnie prototypu nie należy wyrzucać.

Oprócz tego, co już wspomniano, w projekcie produkcyjnym potrzebne są (między innymi):

0-Wybierz metodologię wdrażania

1-Sfinalizuj i opublikuj główne wymagania (w tym przypadki użycia itp.)

2-Popraw architekturę

3-Wybierz odpowiednie narzędzia

Baza danych 4-Design dla wydajności

5-Opracuj swój projekt klasy i projekt przepływu pracy

6-Określenie i wdrożenie strategii integracji baz danych / źródeł danych / kanałów

7-Zdefiniuj i zaimplementuj wymagania bezpieczeństwa

8-Organizuj fizyczną implementację (serwery, łączność, licencje itp.)

9-Planowanie wymagań dotyczących przechowywania i określenie miar wydajności

10-Wyprodukuj wszystkie artefakty i zainstaluj w środowisku produkcyjnym

11-Test

12-Dostarcz ostateczne rozwiązanie i zaimplementuj informacje zwrotne

Najważniejszą cechą rozwiązań jakości produkcji jest - moim zdaniem - solidność .

Niezależnie od tego, co się stanie, rozwiązanie rozsądnie radzi sobie z sytuacją, powiadamia tych, którzy muszą o tym wiedzieć, i kontynuuje działanie (jeśli błąd można naprawić).

Istnieją dwa rodzaje prototypów:

• Szybkie i brudne aplikacje „proof of concept”, które są „czyszczone” i stają się kodem produkcyjnym. Etap „sprzątania” jest albo koszmarem, albo etapem „zamiatania problemów pod dywan”, co powoduje ogromne zadłużenie techniczne.

• „Makiety” prototypów lub „szkieletów”. Mogą to być szkice interfejsu użytkownika w formie papierowej lub ołówkowej, a nawet interaktywne makiety wykonane w języku, w którym można szybko poskładać tego rodzaju rzeczy bez zastanowienia się nad tym, jak to pasuje. Powinien korzystać z fałszywych danych, bez prawdziwej architektury itp. Chodzi o to, że dają zainteresowanym stronom wyobrażenie o tym, jaki będzie system, aby można było sprecyzować swoje wymagania, ale NIE MOGĄ być używane jako część ostatecznego rozwiązania .

Wolę drugi rodzaj. Zostają wyrzuceni, ponieważ tak naprawdę nie ma wyboru.

Mówię, że zbuduj go jak projekt bez wersji demonstracyjnej, ale teraz możesz uwzględnić w projekcie to, czego nauczyłeś się z wersji demonstracyjnej. Początkowe kodowanie może być złe nawet po rozpoczęciu produkcji. Zresztą i tak będziesz musiał go zrefaktoryzować.

Prawdziwym problemem do rozwiązania jest ograniczenie czasu. Kiedy decydenci chcą, abyś kontynuował pracę nad wersją demonstracyjną, ma wrażenie, że duża część aplikacji jest gotowa, więc nie potrwa to długo. Słyszałem, że inni używają tej logiki, dlaczego wolą pokazywać szkice klientom zamiast zbyt realistycznych makiet. Zwróć uwagę na kod demonstracyjny, ponieważ mógł on wykryć problemy, o których nigdy nie pomyślałeś i prawdopodobnie nie udokumentowałeś w tym procesie. Musisz je teraz wziąć pod uwagę (zbyt uproszczone, ale tak, baza danych może być na przykład niedostępna).

Wszystkie prototypy i wersje demonstracyjne nie są sobie równe. Cały kod może być bezwartościowy lub niektóre części mogły zostać wykonane bardzo dobrze. Nie ma znaczenia, czy jest to demo, musisz znać różnicę. Nie po prostu wyrzuciłbyś aplikację Legacay i zacząłbyś od nowa, prawda? Zapomnij, że zapytałem.