Na początku zawsze trudno jest zrozumieć duży i stary projekt. Architektura jest jednym z działań oceny architekta. Zwykle trzeba pracować z dużymi, starymi projektami, a wyniki muszą być dostarczone w ciągu tygodnia.
Jak ocenić projekt składający się z 100 tys. lub więcej linii kodu tygodniowo, a jednocześnie dostarczać wyniki, które są naprawdę przydatne dla klienta.
Większość architektów i kierowników technicznych spotkała się z podobnymi ocenami projektów. Może to wyglądać na półformalny proces lub oddzielną usługę, jak to ma miejsce w naszej firmie, w ten czy inny sposób większość z Was sobie z tym poradziła.
Oryginał w języku angielskim dla znajomych, którzy nie mówią po rosyjsku, znajduje się tutaj: .
Podejście naszej firmy
Opowiem Ci jak to działa w naszej firmie i jak ja postępuję w podobnych sytuacjach, ale z łatwością możesz zmienić to podejście w zależności od potrzeb swojego projektu i firmy.
Istnieją dwa rodzaje oceny architektury.
Wewnętrzny – zazwyczaj robimy to dla projektów wewnątrz firmy. Każdy projekt może wymagać oceny architektury z kilku powodów:
- Zespół uważa, że ich projekt jest doskonały i jest to podejrzane. Mieliśmy takie przypadki i często w takich projektach wszystko jest dalekie od ideału.
- Zespół chce przetestować swój projekt i rozwiązania.
- Zespół wie, że sytuacja jest zła. Mogą nawet wymienić główne problemy i przyczyny, ale chcą pełnej listy problemów i zaleceń dotyczących ulepszenia projektu.
Zewnętrzny jest procesem bardziej formalnym niż ocena wewnętrzna. Klient przychodzi zawsze tylko w jednym przypadku, gdy wszystko jest źle - bardzo źle. Zwykle klient rozumie, że istnieją problemy globalne, ale nie potrafi poprawnie zidentyfikować przyczyn i rozłożyć ich na elementy składowe.
Ocena architektury dla klienta zewnętrznego jest bardziej złożonym przypadkiem. Proces powinien być bardziej formalny. Projekty są zawsze duże i stare. Mają mnóstwo problemów, błędów i krzywego kodu. Maksymalnie w ciągu kilku tygodni powinien być gotowy raport z wykonanych prac, który powinien zawierać główne problemy i zalecenia dotyczące usprawnień. Jeśli więc mamy do czynienia z zewnętrzną oceną projektu, to ocena wewnętrzna pójdzie gładko. Rozważmy najtrudniejszy przypadek.
Ocena architektury projektu przedsiębiorstwa
Typowy projekt do oceny to duży, stary projekt korporacyjny, w którym występuje wiele problemów. Przychodzi do nas klient i prosi o naprawę jego projektu. To jak z górą lodową, klient widzi tylko wierzchołek swoich problemów i nie ma pojęcia, co kryje się pod wodą (w głębi kodu).
Problemy, które Klient może reklamować i o których może wiedzieć:
- Problemy z wydajnością
- Problemy z użytecznością
- Wdrożenie długoterminowe
- Brak testów jednostkowych i innych
Problemy, których klient najprawdopodobniej nie jest świadomy, ale mogą pojawić się w projekcie:
- Problemy bezpieczeństwa
- Problemy projektowe
- Zła architektura
- Błędy algorytmiczne
- Nieodpowiednie technologie
- Dług techniczny
- Zły proces rozwoju
Proces przeglądu architektury formalnej
Jest to formalny proces, który przestrzegamy jako firma, ale możesz go dostosować w zależności od firmy i projektu.
Prośba od klienta
Klient prosi o ocenę architektury aktualnego projektu. Osoba odpowiedzialna po naszej stronie zbiera podstawowe informacje o projekcie i dobiera niezbędnych ekspertów. W zależności od projektu mogą to być różni eksperci.
Rozwiązanie Architekt – główna osoba odpowiedzialna za ocenę i koordynację (i często jedyna).
Gromadź konkretnych ekspertów – .Net, Java, Python i inni specjaliści techniczni w zależności od projektu i technologii
Eksperci w chmurze – mogą to być architekci chmur Azure, GCP lub AWS.
Infrastruktura – DevOps, administrator systemu itp.
Inni eksperci – np. big data, uczenie maszynowe, inżynier wydajności, ekspert ds. bezpieczeństwa, kierownik ds. kontroli jakości.
Zbieranie informacji o projekcie
Należy zebrać jak najwięcej informacji o projekcie. W zależności od sytuacji możesz zastosować różne techniki:
- Kwestionariusze i inne metody komunikacji drogą pocztową. Najbardziej nieskuteczny sposób.
- Spotkania on-line.
- Specjalne narzędzia do wymiany informacji takie jak: Google doc, Confluence, repozytoria itp.
- Spotkania „na żywo” na miejscu. Najskuteczniejszy i najdroższy sposób.
Co powinieneś otrzymać od klienta?
Podstawowe informacje. O co chodzi w projekcie? Jego cel i wartość. Główne cele i plany na przyszłość. Cele i strategie biznesowe. Główne problemy i pożądane rezultaty.
Informacje o projekcie. Stos technologii, frameworki, języki programowania. Wdrożenie lokalne lub w chmurze. Jeśli projekt jest w chmurze, z jakich usług korzysta. Jakie wzorce architektoniczne i projektowe zastosowano.
Wymagania niefunkcjonalne. Wszystkie wymagania związane z wydajnością, dostępnością i łatwością obsługi systemu. Wymagania bezpieczeństwa itp.
Podstawowe przypadki użycia i przepływy danych.
Dostęp do kodu źródłowego. Najważniejsza część! Zdecydowanie powinieneś uzyskać dostęp do repozytoriów i dokumentacji dotyczącej sposobu budowania projektu.
Dostęp do infrastruktury. Byłoby miło mieć dostęp do sceny lub infrastruktury produkcyjnej, aby pracować z systemem na żywo. Dużym sukcesem jest, jeśli klient posiada narzędzia do monitorowania infrastruktury i wydajności. O tych narzędziach porozmawiamy w następnej sekcji.
Dokumentacja. Jeśli klient posiada dokumentację, jest to dobry początek. Może i jest przestarzały, ale to wciąż dobry początek. Nigdy nie ufaj dokumentacji - przetestuj ją z klientem, na prawdziwej infrastrukturze i w kodzie źródłowym.
Proces oceny architektury
Jak można przetworzyć tak dużą ilość informacji w tak krótkim czasie? Przede wszystkim należy zrównoleglić pracę.
DevOps powinien przyjrzeć się infrastrukturze. Wprowadzenie technologiczne do kodu. Inżynier wydajności, aby wyświetlić wskaźniki wydajności. Specjalista od baz danych powinien głębiej zagłębić się w struktury danych.
Jest to jednak idealny przypadek, gdy masz dużo zasobów. Zazwyczaj projekt ocenia jedna do trzech osób. Możesz nawet samodzielnie przeprowadzić wycenę, co często ma miejsce, jeśli posiadasz odpowiednią wiedzę i doświadczenie we wszystkich obszarach projektu. W takim przypadku musisz maksymalnie zautomatyzować wszystkie procesy.
Niestety trzeba będzie zapoznać się z dokumentacją ręcznie. Mając odpowiednią ilość doświadczenia, można szybko zrozumieć jakość dokumentacji. Co jest prawdą, a co wyraźnie nie pokrywa się z rzeczywistością. Czasami w dokumentacji możesz zobaczyć architekturę, która nigdy nie będzie działać w prawdziwym życiu. To skłania Cię do zastanowienia się nad tym, jak zostało to zrobione w rzeczywistości w projekcie.
Przydatne narzędzia do automatyzacji oceny projektów
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:
jest doskonałym narzędziem dla architekta. Pokaże Ci szerszy obraz, zależności między modułami i potencjalne obszary refaktoryzacji. Jak wszystkie dobre narzędzia, kosztuje dobre pieniądze, ale możesz skorzystać z 30-dniowej wersji próbnej.
- stare, dobre narzędzie. Narzędzie do statycznej analizy kodu. Umożliwia identyfikację złego kodu, błędów i problemów związanych z bezpieczeństwem w ponad 20 językach programowania.
Wszyscy dostawcy usług w chmurze dysponują narzędziami do monitorowania infrastruktury. Umożliwi to właściwą ocenę efektywności posiadanej infrastruktury pod kątem kosztów i wydajności. W przypadku AWS tak jest . Dla Azure jest to łatwe .
Dodatkowe monitorowanie i rejestrowanie wydajności pomoże znaleźć problemy z wydajnością na wszystkich poziomach. Zaczynając od bazy danych z nieefektywnymi zapytaniami, poprzez backend, a skończywszy na frontendzie. Nawet jeśli klient nie instalował wcześniej tych narzędzi, można je dość szybko zintegrować z istniejącym systemem, aby zidentyfikować problemy z wydajnością.
Jak zawsze, dobre narzędzia są tego warte. Mogę polecić kilka płatnych narzędzi. Oczywiście możesz użyć oprogramowania typu open source, ale zajmie to więcej czasu. Należy to zrobić na początku, a nie w trakcie procesu oceny architektury.
– narzędzie do oceny wydajności aplikacji
– usługa monitorowania systemów chmurowych
Dostępnych jest wiele narzędzi do testowania bezpieczeństwa. Tym razem polecę Ci darmowe narzędzie do skanowania systemu.
– narzędzie do skanowania aplikacji internetowych pod kątem zgodności ze standardami bezpieczeństwa.
Złóżmy wszystko w jedną całość.
Przygotowanie raportu
Rozpocznij raport od danych zebranych od klienta. Opisz cele projektu, ograniczenia, wymagania pozafunkcjonalne. Następnie należy wymienić wszystkie dane wejściowe: kod źródłowy, dokumentację, infrastrukturę.
Następny krok. Wypisz wszystkie problemy znalezione ręcznie lub przy użyciu zautomatyzowanych narzędzi. Umieść duże, automatycznie wygenerowane raporty na końcu w sekcji aplikacji. Należy przedstawić krótki i zwięzły dowód wykrytych problemów.
Nadaj priorytet problemom znalezionym na skali błędu, ostrzeżenia i informacji. Możesz wybrać własną skalę, ale jest to skala ogólnie przyjęta.
Jako prawdziwy architekt masz obowiązek przedstawić zalecenia dotyczące rozwiązania wykrytych problemów. Opisz ulepszenia i wartość biznesową, jaką otrzyma klient. Jak pokazać wartość biznesową z omawialiśmy wcześniej.
Przygotuj plan działania z małymi iteracjami. Każda iteracja powinna zawierać czas wykonania, opis, ilość zasobów potrzebnych do ulepszenia, wartość techniczną i wartość biznesową.
Dokonujemy oceny architektury i przekazujemy klientowi raport
Nigdy nie wystarczy wysłać raportu pocztą. Można go w ogóle nie przeczytać lub nie można go przeczytać i zrozumieć bez odpowiedniego wyjaśnienia. Krótko mówiąc, komunikacja na żywo pomaga eliminować nieporozumienia między ludźmi. Należy umówić się na spotkanie z klientem i porozmawiać o znalezionych problemach, skupiając się na tych najistotniejszych. Warto zwrócić uwagę klienta na problemy, z których być może nawet nie zdaje sobie sprawy. Na przykład kwestie bezpieczeństwa i wyjaśnij, w jaki sposób mogą one wpłynąć na działalność biznesową. Pokaż swój plan działania z ulepszeniami i omów różne opcje, które są bardziej odpowiednie dla klienta. Może to być czas, zasoby, ilość pracy.
Jako podsumowanie spotkania wyślij raport do klienta.
Na zakończenie
Ocena architektury to złożony proces. Aby prawidłowo przeprowadzić ocenę, należy posiadać odpowiednie doświadczenie i wiedzę.
Już w tydzień jesteśmy w stanie zapewnić klientowi przydatne dla niego i jego biznesu rezultaty. Nawet jeśli zrobisz to sam.
Z mojego doświadczenia wynika, że wiele ulepszeń zostało pobranych w trakcie, a czasami nigdy się nie uruchomiło. Ci, którzy wybrali dla siebie złoty środek i dokonali tylko części najbardziej przydatnych dla biznesu ulepszeń przy minimalnych kosztach pracy, znacząco poprawili jakość swojego produktu. Ci, którzy nic nie zrobili, mogli po kilku latach całkowicie zamknąć projekt.
Twoim celem jest pokazanie klientowi maksymalnych ulepszeń za minimalną cenę.
Inne artykuły z działu możesz czytać w wolnym czasie.
Życzę czystego kodu i dobrych decyzji architektonicznych.
Nasza grupa na Facebooku - .
Źródło: www.habr.com