Jak wykonać wstępną recenzję Architektury

Question

Łatwo jest dostrzec błąd architektury po zakończeniu projektu. X dał nam problemy z bezpieczeństwem, lub Y dał nam dużo dodatkowej pracy. Zostały one schwytane w retrospekcjach, ale dobrze byłoby je złapać wcześniej.

Planujemy przeprowadzić przeglądy architektury przed rozpoczęciem kodowania.

Jednym ze sposobów jest po prostu poprosić architekta o przedstawienie projektu i sprawdzenie, czy możemy znaleźć błędy w projekcie.

Czy ktoś ma bardziej uporządkowane podejście, może z listą kontrolną "Czy myślałeś o" lub "Jak masz zamiar zrobić".

myślałem o czymś takim:

• Bezpieczeństwa
• Logging
• Data Access
• Wdrożenie
• Upgrade

Answer 1

Dodatkowe elementy, aby dodać do swojej listy, w przypadkowej kolejności:

• Performance - albo latency, przepustowość, skalowanie lub inne czynniki związane z danym wynikowym
• Supportability - Masz już rejestrowanie, ale co o instalacjach hydraulicznych w innych pomiarach diagnostycznych (Java-JMX, Windows-WMI/liczniki wydajności lub coś niestandardowego)
• Elastyczność - trudności w późniejszej zmianie architektury (zwykle jest to jedna z tych rzeczy, które są nadmiernie wykonywane i powodują więcej problemów niż to konieczne , ale dyskusja powinna być obecna podczas ewaluacji wzór)
• Model gwintowania/blokowania - czy jest jasne, w jaki sposób dane będą chronione? W jaki sposób będzie obsługiwane rywanie o zasoby?
• Wymagania dotyczące zasobów - zużycie pamięci na różnych poziomach użytkowania.Czy pasuje do twoich ograniczeń?
• Obsługa błędów - gdy coś w produkcie zawiedzie, czy architektura obsługuje czystą obsługę i powiadamianie o problemach?
• Zrozumiałe - Zbyt skomplikowane architektury są często zapominane podczas wdrażania. Jeśli większość zespołu, aw szczególności liderów, nie może zachować architektury, to filozofia i zasady, w głowach, architektura nie będzie miała znaczenia.
• Spójność. Czy starają się wykorzystać każdy możliwy wzór lub skupić się na regularnych, powtarzających się wzorach. Nie oznacza to, że wybieranie właściwego wzoru dla każdego problemu nie jest dobrą rzeczą, ale posiadanie wielu wzorców może wpływać na zrozumiałość i prowadzić do błędów w implementacji. Architekt powinien próbować zademonstrować wszystko, co wie (lub najnowsze fajne rzeczy) w każdym projekcie.
• Testowalny - Czy projekt pomaga lub szkodzi wysiłkom w zakresie testowania (systemu i integracji). Czy testowanie może być zautomatyzowane, czy będziesz polegać na armii testerów, aby stale powtarzać testy regresji, aby wiedzieć, że Twój zespół nie złamał produktu?
• Czy architektura rzeczywiście rozwiązuje problem, który próbujesz rozwiązać, i który mieści się w zakresie problemu? Nie twórz drapacza chmur, gdy dupleks będzie wystarczający.

Answer 2

Należy używać znanych wzorców, a może nawet architektury frameworks w celu zmniejszenia co-jeśli.

Po zakończeniu projektu stosunkowo łatwo jest dostrzec błędy architektury, ale to leży w naturze tego, co robimy.

Uważam, że dobrą praktyką jest ciągłe przeprowadzanie recenzji architektury. To nie jest krok, który po prostu "wykonasz".

Answer 3

Dla ważnego projektu jedną rzeczą, którą robimy, jest dokument opcji rozwiązania. Robisz "burzę mózgów", zbierasz informacje, rozmawiasz z MŚP, rozmawiasz z kimkolwiek, kogo potrzebujesz i tworzysz tabelę dla różnych opcji z zaletami, wadami, nieokreślonymi kosztami i szacunkami. Tak, to ćwiczenie jest napowietrzne, ale wiele z tych problemów, które opisujesz, będzie znane, jeśli to zrobisz.

Na koniec zaleca rozwiązanie do zarządzania z powodów i ewentualnie schemat architektury wysokiego poziomu do wizualizacji rozwiązania.

Answer 4

Oczywiście istnieje wiele książek na ten temat (E.G., 97 rzeczy, które powinien znać architekt). Możesz znaleźć obszerną listę aksjomatów here i sugeruję, abyś wybrał te, które mają sens dla twoich projektów dla twojej listy kontrolnej.

Answer 5

Zmiana jest stała, upewnij się, że Twoja architektura jest elastyczna.
Interfejs użytkownika usprawnia działanie użytkowników.
Podziel się z tobą całą wiedzą na temat archotektury.
Wypróbuj przed wdrożeniem.
Nie nadużywaj wzorów.