Na początku zawsze trudno jest zrozumieć duży i stary projekt. Ocena architektury to jedna z działań architekta. Zwykle trzeba pracować nad dużymi, starymi projektami, a wyniki należy przedstawić w ciągu tygodnia.
Jak ocenić projekt o wielkości 100k i więcej linii kodu w ciągu tygodnia, dostarczając jednocześnie naprawdę przydatne wyniki dla klienta?
Większość architektów i liderów technicznych spotkała się z podobnymi ocenami projektów. Może to wyglądać jak półformalny proces lub jako osobna usługa, jak to jest zrobione w naszej firmie, tak czy siak większość z was miała z tym do czynienia.
Oryginał w języku angielskim dla waszych nie rosyjskojęzycznych przyjaciół znajduje się tutaj: .
Podejście w naszej firmie
Opowiem wam, jak to działa w naszej firmie i jak postępuję w takich sytuacjach, ale możecie swobodnie zmieniać to podejście w zależności od potrzeb waszego projektu i firmy.
Są dwa rodzaje ocen architektury.
Wewnętrzna – zazwyczaj przeprowadzamy ją dla projektów wewnątrz firmy. Każdy projekt może poprosić o ocenę architektury z kilku powodów:
- Zespół uważa, że ich projekt jest idealny, co jest podejrzane. Mieliśmy takie przypadki i często w takich projektach nic nie jest idealne.
- Zespół chce sprawdzić swój projekt i swoje rozwiązania.
- Zespół wie, że jest źle. Mogą nawet wymienić główne problemy i przyczyny, ale chcą otrzymać pełną listę problemów i rekomendacji dotyczących poprawy projektu.
Zewnętrzna – jest to bardziej formalny proces niż ocena wewnętrzna. Klient zawsze przychodzi tylko w jednym przypadku, gdy wszystko jest źle – bardzo źle. Zwykle klient rozumie, że są globalne problemy, ale nie potrafi dokładnie określić przyczyn i podzielić ich na składniki.
Ocena architektury dla zewnętrznego klienta to bardziej skomplikowana sprawa. Proces musi być bardziej formalny. Projekty są zawsze duże i stare. Zawierają wiele problemów, błędów i nieklasycznego kodu. Raport z przeprowadzonej pracy musi być gotowy w ciągu kilku tygodni maksymalnie, gdzie powinny być główne problemy i rekomendacje dotyczące poprawy. Dlatego, jeśli poradzimy sobie z zewnętrzną oceną projektu, wewnętrzna będzie zostać tylko drobnostką. Rozważmy najtrudniejszy przypadek.
Ocena architektury projektu przedsiębiorstwowego
Typowy projekt do oceny to duży, stary projekt enterprise z wieloma problemami. Klient przychodzi do nas z prośbą o naprawę swojego projektu. To jak z górą lodową, klient widzi tylko czubek swoich problemów i nie zdaje sobie sprawy z tego, co znajduje się pod wodą (w głębi kodu).
Problemy, na które klient może narzekać i być ich świadomy:
- Problemy z wydajnością
- Problemy z użytecznością aplikacji (Usability)
- Długi czas wdrażania
- Brak testów jednostkowych i innych testów
Problemy, o których klient może nie mieć pojęcia, ale mogą występować w projekcie:
- Problemy z bezpieczeństwem
- Problemy projektowe
- Nieprawidłowa architektura
- Błędy algorytmiczne
- Niewłaściwe technologie
- Dług techniczny
- Nieprawidłowy proces rozwoju
Formalny proces oceny architektury
To formalny proces, którego przestrzegamy w firmie, ale możesz go dostosować do swoich potrzeb w zależności od swojej firmy i projektu.
Zapytanie od klienta
Klient prosi o ocenę architektury bieżącego projektu. Osoba odpowiedzialna z naszej strony zbiera podstawowe informacje o projekcie i dobiera potrzebnych ekspertów. W zależności od projektu mogą to być różni eksperci.
Architekt rozwiązań – główna osoba odpowiedzialna za ocenę i koordynację (często jest to jedyna osoba).
Eksperci specyficzni dla technologii – specjaliści .Net, Java, Python i inni techniczni eksperci w zależności od projektu i technologii
Eksperci chmurowi – mogą to być architekci chmurowi Azure, GCP lub AWS.
Infrastruktura – DevOps, administrator systemów, itd.
Inni eksperci – tacy jak eksperci big data, machine learning, inżynierowie wydajności, eksperci ds. bezpieczeństwa, liderzy QA.
Zbieranie informacji o projekcie
Powinieneś zebrać jak najwięcej informacji o projekcie. Możesz stosować różne techniki w zależności od sytuacji:
- Ankiety i inne sposoby komunikacji przez e-mail. Najmniej efektywny sposób.
- Spotkania online.
- Specjalne narzędzia do wymiany informacji takie jak: Google doc, Confluence, repozytoria itd.
- „Na żywo” spotkania na miejscu. Najbardziej efektywny i najdroższy sposób.
Co należy uzyskać od klienta?
Podstawowe informacje. O czym jest projekt. Jego cel i wartość. Główne cele i plany na przyszłość. Cele biznesowe i strategie. Główne problemy i oczekiwany wynik.
Informacje o projekcie. Stos technologiczny, frameworki, języki programowania. Wdrażanie on-premise lub w chmurze. Jeśli projekt jest w chmurze, jakie usługi są używane. Jakie wzorce architektoniczne i projektowe zostały zastosowane.
Wymagania niefunkcjonalne. Wszystkie wymagania związane z wydajnością, dostępnością, użytecznością systemu. Wymagania dotyczące bezpieczeństwa itp.
Podstawowe przypadki użycia i przepływy danych.
Dostęp do kodu źródłowego. Najważniejsza część! Musisz koniecznie uzyskać dostęp do repozytoriów i dokumentacji, jak zbudować projekt.
Dostęp do infrastruktury. Dobrze byłoby uzyskać dostęp do infrastruktury stage lub produkcyjnej, aby pracować z „żywym” systemem. To duża zaleta, jeśli klient ma narzędzia do monitorowania infrastruktury i wydajności. O tych narzędziach porozmawiamy w następnej sekcji.
Dokumentacja. Jeśli klient posiada dokumentację, to dobry początek. Może być przestarzała, ale to wciąż dobry początek. Nigdy nie wierz dokumentacji – sprawdzaj ją z klientem, na rzeczywistej infrastrukturze i w kodzie źródłowym.
Proces oceny architektury
Jak poradzić sobie z tak dużą ilością informacji w tak krótkim czasie? Przede wszystkim rozdziel pracę.
DevOps powinien spojrzeć na infrastrukturę. Lider techniczny na kod. Inżynier wydajności powinien zapoznać się z metrykami wydajności. Specjalista ds. baz danych powinien głębiej zbadać struktury danych.
Ale to idealny przypadek, gdy masz dużo zasobów. Zazwyczaj ocenę projektu przeprowadza jedna do trzech osób. Możesz nawet przeprowadzić ocenę samodzielnie, co często się zdarza, jeśli masz odpowiednią wiedzę i doświadczenie w wszystkich obszarach projektu. W takim przypadku powinieneś zautomatyzować wszystkie procesy, na ile to możliwe.
Niestety, musisz przeczytać dokumentację manualnie. Przy odpowiednim doświadczeniu będziesz mógł dość szybko ocenić jakość dokumentacji. Co jest prawdą, a co wyraźnie nie zgadza się z rzeczywistością. Czasami możesz napotkać taką architekturę w dokumentacji, która nigdy nie zadziała w rzeczywistości. To sygnał dla Ciebie, aby zastanowić się, jak to zostało zrealizowane w projekcie.
Przydatne narzędzia do automatyzacji oceny projektu
Ocena kodu to proste ćwiczenie. Możesz użyć statycznych analizatorów kodu, które pokażą problemy z projektem, wydajnością i bezpieczeństwem. Oto kilka z nich:
to doskonałe narzędzie dla architekta. Pokaże ci ogólny obraz, zależności między modułami oraz potencjalne obszary do refaktoryzacji. Jak wszystkie dobre narzędzia, kosztuje sporo, ale jednocześnie możesz skorzystać z 30-dniowej wersji próbnej.
to stary, dobry narzędzie. Narzędzie do statycznej analizy kodu. Umożliwia identyfikację złego kodu, błędów oraz problemów z bezpieczeństwem w ponad 20 językach programowania.
Wszyscy dostawcy chmury mają narzędzia do monitorowania infrastruktury. Pozwoli to prawidłowo ocenić efektywność infrastruktury pod kątem kosztów i wydajności. Dla AWS to . Dla Azure to po prostu .
Dodatkowe monitorowanie wydajności i logowanie pomoże zidentyfikować problemy z wydajnością na wszystkich poziomach. Od bazy danych z nieefektywnymi zapytaniami, backendu, po frontend. Nawet jeśli klient wcześniej nie zainstalował tych narzędzi, możesz dość szybko zintegrować je z istniejącym systemem, aby określić problemy z wydajnością.
Jak zawsze dobre narzędzia kosztują. Mogę polecić kilka płatnych narzędzi. Oczywiście możesz korzystać z open-source, ale zajmie to więcej czasu. A to należy zrobić z wyprzedzeniem, a nie w trakcie oceny architektury.
to narzędzie do oceny wydajności aplikacji
to usługa monitorowania w chmurze
Do testowania bezpieczeństwa jest wiele narzędzi. Tym razem polecę ci darmowe narzędzie do skanowania systemu.
to narzędzie do skanowania aplikacji internetowych pod kątem zgodności z normami bezpieczeństwa.
Zbieramy wszystko w całość.
Przygotowujemy raport
Rozpocznij swój raport od zebranych danych od klienta. Opisz cele projektu, ograniczenia, wymagania niefunkcjonalne. Następnie należy wspomnieć o wszystkich danych wejściowych, takich jak kod źródłowy, dokumentacja, infrastruktura.
Kolejny krok. Wymień wszystkie problemy, które znalazłeś ręcznie lub za pomocą narzędzi automatycznych. Duże raporty generowane automatycznie umieść na końcu w sekcji załączników. Tutaj powinny być krótkie i treściwe dowody znalezionych problemów.
Priorytetyzuj znalezione problemy w skali error, warning, info. Możesz wybrać swoją skalę, ale ta jest powszechnie przyjęta.
Jako prawdziwy architekt masz obowiązek dostarczyć rekomendacje dotyczące usunięcia znalezionych problemów. Opisz poprawki oraz wartość dla biznesu, jaką uzyska klient. Jak pokazać wartość dla biznesu od omawialiśmy wcześniej.
Przygotuj roadmap z małymi iteracjami. Każda iteracja powinna zawierać czas realizacji, opis, liczbę zasobów potrzebnych do poprawy, wartość techniczną i wartość dla biznesu.
Kończymy ocenę architektury i dostarczamy klientowi raport.
Nigdy nie wysyłaj raportu tylko mailem. Może nie zostać przeczytany lub zostanie przeczytany, ale nie zrozumiany bez odpowiedniego wyjaśnienia. Krótko mówiąc – bezpośrednia komunikacja pomaga wyeliminować nieporozumienia między ludźmi. Powinieneś umówić się na spotkanie z klientem i omówić znalezione problemy, kładąc akcent na te najważniejsze. Warto zwrócić uwagę klienta na problemy, których mógł nawet nie być świadomy. Takie jak problemy z bezpieczeństwem i wyjaśnić, jak mogą wpłynąć na biznes. Pokaż swoją roadmap z poprawkami i omów różne opcje, które są bardziej odpowiednie dla klienta. Może to dotyczyć czasu, zasobów, zakresu prac.
Podsumowując swoje spotkanie, wyślij klientowi swój raport.
Na zakończenie
Ocena architektury to skomplikowany proces. Aby przeprowadzić ocenę prawidłowo, musisz mieć wystarczające doświadczenie i wiedzę.
To możliwe – dostarczyć klientowi przydatne wyniki w ciągu tygodnia. Nawet jeśli robisz to samodzielnie.
Z mojego doświadczenia wynika, że wiele popraw działań utknęło w połowie, a czasami nawet nigdy się nie zaczęło. Ci, którzy wybrali złoty środek i dokonali tylko części ulepszeń maksymalnie korzystnych dla biznesu przy minimalnym nakładzie pracy, znacznie poprawili jakość swojego produktu. Ci, którzy nic nie robili, mogli za kilka lat całkowicie zamknąć projekt.
Twoim celem jest pokazanie klientowi maksymalnych ulepszeń za minimalną cenę.
Inne artykuły z tej sekcji można przeczytać w wolnym czasie.
Życzę ci czystego kodu i dobrych rozwiązań architektonicznych.
Nasza grupa na Facebooku — .
Źródło: habr.com
