Zebrałem taką krótka listę dobrych praktyk. Żeby o nich nie zapomnieć i mieć ściągawkę na przyszłość. Są to ogólne zasady, które będą lepiej już gorzej pasować do większości scenariuszy. Aczkolwiek musisz pamiętać, że czasami występują odstępstwa od reguły. Jak zwykle w życiu trzeba dokładnie przemyśleć każdą decyzję.
Planowanie
Proces planowania na piśmie:
Nie muszę chyba nikogo przekonywać jak ważne jest planowanie. Dobry plan to połowa sukcesu. Plan powinien byś spisany to pozwoli udokumentować podejmowane decyzje. Wiem z doświadczenie, że po kilku miesiącach zapominamy dlaczego podjęliśmy taką, a nie inną decyzję architektoniczną/inżynieryjną. Dobrze mieć wtedy notatki i do nich wrócić, to się przydaje przy dyskusjach z klientem. Nie chodzi tutaj o sam plan, ale o dokładne spisanie wymagań i ich rozwiązań bo to tego się wraca. Plan powinien być połączony z wymaganiami i wpasowywać się do niego. To pomaga w lepszej organizacji.
Plany mogą mieć różną formę dobierz to co jest potrzebne w aktualnym etapie twojego projektu. Np. „Request for Comment” (RFC), „Engineering Requirements Document” (EDD), „Design Doc” lub „Architectural Decision Record” (ADR).
Standaryzacja
Bez względu na okoliczności warto trzymać, się wcześniej ustalonych standardów. Powinny one dotyczyć dokumentacji, kodowania, polityk ect. Warto uzgodnić jakich narzędzi będziemy używać i jak będzie wyglądać tworzenia diagramów architektonicznych (symbole). Taką standaryzację należy spisać, w centralnym miejscu żeby wszyscy w zespole mieli do niej łatwy dostęp. Czy wszyscy będą się do niej stosować ??? to już inna kwestia.🤩
Automatyzacja konfiguracji
Nie chcę ględzić za dużo, ale to bardzo ważne. Automatyzuj powtarzające się zadania. Każdy projekt w chmurze będzie potrzebował podobnych narzędzi/usług. Często tracimy czas na tworzenie czegoś co już raz gdzieś było zrobione. Warto mieć gotowce, szablony kodu do automatyzacji żeby tworzyć, konfigurować nowe i istniejące zasoby. Do tego celu możesz stworzyć centralne repozytorium gdzie będziesz trzymał różne utilsy czyli przydatne kawałki kodu.
PoC
W świecie technologii wszystko bardzo szybko się zmienia. Często nie wiem jak zachowa się dana technologia czy narzędzie w konkretnej sytuacji. Tutaj z pomocą przychodzi podejście tworzenia jednorazowych prototypów w celu walidacji pomysłów i uzyskania szybkiego potwierdzenia czy nasze rozwiązanie spełni wymagania klienta.
Sprawdzanie kodu:(Code review)
Jeśli dobrze masz ustawione polityki w DevOps to przed zrobieniem merga do głównego brancha (main), ktoś powinien zatwierdzić twój kod. W większych projektach powinny to być 2 osoby. Dzięki takiemu podejściu rozwiązanie jest lepszej jakości. Zgodnie z przysłowiem co dwie głowy to nie jedna w tym wypadku pomoże dowieść coś lepszego.
Staram się położyć coraz większy nacisk na „checklisty” chciałbym mieć pod ręką listę elementów na które powinienem zwracać uwagę. Mój umysł jest w stanie ogarnąć tylko jeden wątek to by oznaczało, że patrzę tylko na jeden problem np. błąd logiczny w kodzie. Niestety takie przejście przez kod raz to za mało, bo wyłapię tylko część problemów. Jeśli mam listę rzeczy do sprawdzenia to skanuję kod i koncentruję się tylko na pojedynczym elemencie z listy. Jeśli na liście są trzy rzeczy to trzeba sprawdzić kod 3 razy koncentrując się na jednym aspekcie.
Automatyczne formatowanie kodu
Każdy z nas ma różne preferencje co do formatowania kodu, co podoba się jednemu nie spodoba się drugiemu. Nie jeden konflikt z tego wyniknął😋 Możesz użyć rozwiązań automatycznego formatowania kodu na poziomie IDE lub rozwiązać problem za pomocą lintowania.
Lintowanie: Automatyczna kontrola kodu pod kątem błędów stylistycznych, które można sprawdzić za pomocą reguł. Wprowadzenie lintowania przed utworzeniem pull requestu może pomóc w zapewnieniu, że kod jest formatowany w jednolity sposób. U nas używamy Visual Studio Code i tutaj jest pylint.
Statyczna analiza kodu
Przeprowadzanie zaawansowanych kontroli kodu przed jego zatwierdzeniem, np. wyszukiwanie luk bezpieczeństwa lub wykrywanie funkcji do wycofania.
Różne typy analizy statycznej kodu:
- Code Styling Analysis
- Security Linting
- Error Detection
- UML Diagram Creation
- Duplicate Code Detection
- Complexity Analysis
- Secret Detection
- Comment Styling Analysis
- Unused Code Detection
- Framework Best Practices
Analysis
Przykładowe narzędzia
- PyLint – Code Quality/Error Detection/Duplicate
Code Detection - pep8.py – PEP-8 Code Quality
- pep257.py – PEP-27 Comment Quality
- pyflakes – Error Detection
- mccabe – Cyclomatic Complexity Analyzer
- dodgy – Secrets/Dodgy things detection
- pyroma – Setup.py validator
- vulture – unused code detection
- PyChecker – very similar to pylint
- MyPy – Uses PEP 484 to do type checking in
python (Requires python 3.5) - PySonar – Static type checking without PEP-484
Szablony dla nowych projektów
Firma może trochę zoptymalizować pracę i przygotować gotowe do sklonowania repozytoria z oczekiwaną strukturą folderów i załączonym plikiem README. Takie często używane komponenty możesz nazwać frameworkiem i używać go jako szablonu. Takie podejście znacznie przyspieszy pracę, a jak wiemy czasu jest zawsze za mało. Słowo framework może być zbyć mocne bo to oznacza solidny kawałek funkcjonalności, ale twym szablonem może być trochę kodu typu utils. Wystarczy przejrzeć powtarzające się kawałki kodu z kilku projektów i z tego zbudować szablon. Każda mała rzecz może pomóc.
Generowanie kodu dla wspólnych komponentów:
Jeśli da się przyspieszyć pisanie kodu to dlaczego nie. Na ten punkt trzeba szczególnie uważać w obecnej sytuacji gdy mamy całe mnóstwo asystentów tworzących kod za nas. Jeśli już używasz narzędzi typu AI to warto dokładnie sprawdzić co zostało wygenerowane. Nie ufaj do końca AI bo nie zawsze dostaniesz optymalny czy działający kod.😜 Zawsze analizuj czy jest to do wykorzystania na produkcji. Można go wykorzystać do tworzenia szablonów często używanych komponentów. Oczywiście na końcu to człowiek musi podjąć decyzję co z tego zostaje, a co trzeba przerobić.
Podejścia wieloplatformowe:
Ten paragraf może być nieco kontrowersyjny. Jeśli nie kontrowersyjny to może dotyczyć bardzo niszowych rozwiązań. Rozmawiamy w kontekście danych i tutaj rzadko robi się rozwiązania na wiele platform. Na początku projektu wybieramy narzędzie np Databricks czy MS Fabric i tak już zostaje. Czasami zdarza się, że klient chce rozwiązanie typu ’Cloud Agnostic’. To oznacza, że twoje rozwiązanie musi dać się łatwo przenieść do innej chmury np. z Azure do AWS. W rzeczywistości nie często się to spotyka. Może to być bardziej kosztowne i skomplikowane w utrzymaniu. I tu jest kwestia prawdopodobieństwa jak jest szansa że biznes to wykorzysta. Ja bym się skupił na jednej platformie i tej się trzymał, aż tak dużo ich nie ma. 😁
Integracja i wdrażanie (CI/CD)
Jak już naklepiemy coś ciekawego na Devie to warto by to przenieść na inne środowiska. W dużym skrócie taki proces przenoszenia kodu to CI/CD. Zwie się to po angielsku Continuous Integration and Continuous Deployment. Czyli ciągła integracja kodu oraz ciągłe wdrażanie. W solidnym projekcie jest to podstawa pracy developerskiej. Poszczególne elementy systemu trzeba połączyć w całość i wrzucić na odpowiednie środowisko. Podczas tego procesu warto również uruchamiać różne testy i sprawdzać jak nasze zmiany wpływają na całość rozwiązania.
Testowanie
- Testy automatyczne: Bardzo ważny chociaż czasami zaniedbany element pracy z danymi. Jest wiele rodzajów testów, jednostkowe, integracyjne, end-to-end, wydajnościowe, obciążeniowe. Najbardziej optymalne są testy automatyczne, tj takie przy których człowiek jest zbędny i można je uruchomić kiedy chcesz. Takie podejście zwiększa jakość i utrzymywalność kodu. Często prowadzi do skrócenia czasu potrzebnego na dostarczenie naszych notatników czy paczek.
- Test driven development: Taka specyficzna metodyka gdzie zaczyna się pisać test przed rozpoczęciem pisania właściwego kodu. Ma to swoje zalety i wady. Zaletą jest testowalny i lepszy kod, inaczej się myśli o jakieś funkcji kiedy musisz napisać test zanim stworzysz metodę Wada tej metody wychodzi na jaw kiedy piszesz coś bardzo skomplikowanego i nie jesteś pewniej jak to rozwiązać. Taki test często trzeba przerabiać. Wada tej metodyki to wydłużenie czasu pracy.
- Środowiska testowe: Wdrażanie kodu na środowiskach testowych w celu dodatkowych testów, zamiast bezpośredniego wdrażania do produkcji. Zaletą jest większa pewność, że kod jest poprawny, a wadą dłuższy czas dostarczenia kodu do produkcji i dodatkowa praca związana z utrzymaniem środowisk testowych. Jak już postawisz te środowiska to warto napisać trochę kodu który sprawdzi, że pasuje ono to innych środowisk. Pomimo tego, że automatycznie wdrażasz kod to zdarza się rozjazd środowisk i brak spójności. Warto mieć automatyczne sprawdzanie czy wszystkie środowiska są takie same.
- Testowanie z danymi produkcyjnymi: Testowanie z danymi produkcyjnymi może być bardzo użyteczne. Daje to większą pewność, i możliwość bardzo dokładnego zweryfikowania wyników. Czasami masz możliwość dostępu do danych produkcyjnych z deva lub z testa. Jeśli masz taką możliwość to jesteś na wygranej pozycji. Dzięki solidnym danym testy dadzą konkretne wyniki. Jeśli nie masz połączenia do proda, to może da się przerzucić trochę danych na dev czy test. Gra jest warta świeczki.
- Generowanie danych testowych: Jeśli nie masz dostępu do danych produkcyjnych to możesz wygenerować dane. Nie jest to najbardziej optymalne rozwiązanie, ale to pomoże w developmencie i testach. Jeśli nie masz innych opcji to rozwiąże twoje problemy chociaż częściowo.
- Testy obciążeniowe: Symulowanie dużego obciążenia systemów to bardzo ważny test. Warto wiedzieć jakie są limity twojego rozwiązania, kiedy „pęknie”. Przepuszczasz swój kod na większej ilości danych i mierzysz czas, jeśli trwa za długo to optymalizujesz.
Monitorowanie
- Monitorowanie i logi: Chciałbym tutaj podkreślić, że to bardzo ważny element każdego rozwiązania. Musisz mieć możliwość śledzenia tego co dzieje się w systemie bez dostępu do niego. Byłem w projektach gdzie nie mieliśmy dostępu do produkcji. A awarie się zdarzają i jakoś trzeba je naprawić. Tutaj wkracza monitoring i logi. W najważniejszych miejscach w kodzie dodajesz obsługę wyjątków i logujesz co się wydarzyło. Dzięki tym informacjom będziesz w stanie stwierdzić co dokładnie się wydarzyło. Gdzie trzymać logi to już osobny temat, w chmurze są dedykowane usługi do logów, czasami wystarczy zwykły storage.
Dokumentacja
- Dokumentacja: Z dokumentacją jest trochę jak z kodem nie piszesz tego dla siebie. Tworząc dokumentację myśl o osobie, która nic nie wie o twoim projekcie i będzie musiała wejść i coś naprawić. Musisz więc dostarczyć mapę co i gdzie jest robione. Oczywiście nie wszystko musi być w dokumentacji bo sam kod źródłowy to też dokumentacja. Z stamtąd można wyciągnąć resztę informacji.
Pewnie wszystkiego tu nie zawarłem, tylko najważniejsze punkty. Daj znać czy coś ważnego ominąłem?