Standardy deweloperskie w firmie 3e Software House mają za zadanie określenie kluczowych kroków, jakie muszą być wykonywane z zachowaniem odpowiedniej kolejności przez wszystkie zespoły projektowe, bez wchodzenia w detale i praktyki przyjęte jako uzupełnienie ogólnego standardu przez poszczególne zespoły, pozostawiając pracownikom pole na swobodę i indywidualność. Jednolite standardy deweloperskie w naszym przypadku tworzą proces, który przechodzi każda zmiana, a w skład którego wchodzą takie etapy jak:

1. Analiza

Inicjatorem każdego procesu zawsze jest potrzeba przeprowadzenia jakiejś zmiany, bez względu na to czy zmiana ma za zadanie usunąć błąd, czy wprowadzić do systemu nową funkcjonalność. Każda zmiana musi być opisana w sposób czytelny i niebudzący wątpliwości. Zadaniem tego etapu jest dostarczenie tego opisu. Nie dla każdej zmiany wymagane jest opracowanie pełnej dokumentacji, w wielu prostych przypadkach, wystarczający jest opis w systemie ticketowym. Jednak w przypadku bardziej złożonych zmian, potrzebne jest wsparcie analityka, który opracuje szczegółowy dokument analityczny. W tym celu zapewnienia odpowiedniej jakości tego etapu opracowaliśmy szablon dokumentu analitycznego, który zawiera listę kluczowych obszarów, jakie standardowo analityk powinien zweryfikować i opisać jeśli dana zmiana tego wymaga. Nasz szablon dokumentu obejmuje takie zagadnienia jak:

• opis domen projektowych
• opis ekosystemu
• opis komponentów projektu
• opis głównych funkcjonalności projektu
• opis klas użytkowników
• opis infrastruktury, z jakiej korzystać ma projekt
• szczegółowe opisanie wymagań biznesowych
• wymagania niefunkcjonalne, w tym dot. wydajności, bezpieczeństwa, utrzymania, jakości i aspektów prawnych.

Każdy z punktów posiada opis, oraz wytyczne, które są wskazówką dla analityka, wskazując na co szczególnie zwrócić uwagę. Na tym etapie posiadanie ustandaryzowanych obszarów podlegających analizie poprawia efektywność pracy analityków, ponieważ szablon dokumentu, sprawia, że analityk nie traci czasu na budowanie struktury dokumentu od zera, tylko zaczyna pracę od razu od uzupełniania szablonu. Po drugie taki szablon wymaga od analityka zwrócenia uwagi na poszczególne obszary, które na bazie doświadczeń zostały zakwalifikowane jako kluczowe. Jednocześnie dbamy o to, by szablony aktualizować adekwatnie do naszych doświadczeń i zmieniających się warunków.

2. Development

Główny etap procesu wytwarzania oprogramowania. Nasze standardy deweloperskie na tym etapie skierowane są głównie na odpowiednie użycie narzędzi oferowanych przez System GIT. Nasz projektowy standard obejmuje na tym etapie takie obszary jak:

• Wytyczne pracy z gałęziami GIT (FeatureBrach), polegające na tworzeniu dla każdej zmiany nowej, unikatowej i czytelnie nazwanej gałęzi kodu: Zasada ta jest szczególnie ważna w projektach, w których wydania budowane są w oparciu o dziesiątki mniejszych zmian. Przechowywanie zmian niezależnie pozwala na pełną swobodę ich realizacji bez ryzyka, że różne zmiany będą wzajemnie zaburzały swoje działanie na etapie tworzenia oraz pozwala (do pewnego momentu) to na elastyczność wyboru terminu wdrożenia danej zmiany i budowania paczek wersji.
• Zasady opisu zmian (poszczególnych commitów): Lata wytwarzania oprogramowania nauczyły nas, jak z pozoru błaha czynność, którą jest opisywanie commitów, wpływa na jakość i efektywność na etapie utrzymania aplikacji. Dobry opis celu zmiany jest szczególnie ważny, kiedy po miesiącach spędzonych nad rozwojem aplikacji trzeba wrócić do jakiegoś fragmentu kodu, przeanalizować jego działanie oraz jakie zmiany w jego obszarze zostały wprowadzone i dlaczego.
• Wymagania opracowywania testów jednostkowych: Jest to według nas jedna z fundamentalnych zasad tworzenia dobrego oprogramowania. Uważamy, że nie da się efektywnie rozwijać, żadnego projektu, który nie zawiera testów jednostkowych, przynajmniej dla głównych procesów. Testy jednostkowe, które na etapie tworzenia projektu mogą wydawać się zbędnym wysiłkiem, ale bardzo szybko zwracają się na etapie wprowadzania zmian. Bez nich zmiana w jednej funkcjonalności może spowodować zmiany w innych obszarach. Ręczna weryfikacja staje się bardzo kosztowna i prędzej, czy później błędy powstałe w ten sposób zaczną przeciekać na produkcję.
• Wytyczne posługiwania się CI/CD: W dzisiejszych czasach, kiedy aplikacje coraz częściej stają się modułowe, brak automatyzacji budowania i wdrożeń aplikacji staje się ogromnym ciężarem. Przeprowadzanie regularnych wydań aplikacji zbudowanej w oparciu o mikroserwisy staje się wręcz niemożliwe. Zespół projektowy nie powinien tracić czasu na ręcznie przygotowywanie wdrożeń, ponieważ długoterminowo takie prace te nie są ani efektywne, ani bezpieczne - nietrudno o pomyłkę wdrożeniowca, która może skutkować błędnym wdrożeniem produkcyjnym.
• Zasady mergowania zmian do deweloperskiej gałęzi i przeprowadzania code review: Utrzymanie dobrej jakości kodu powinno być podstawą każdej organizacji zajmującej się wytwarzaniem oprogramowania. Z tego powodu również nasze standardy kładą duży nacisk na code review. W tym celu opracowaliśmy proces, który przechodzi każda zmiana przed złączeniem z główną gałęzią repozytorium kodu. Zmiany realizowane na odrębnych gałęziach, kiedy funkcjonalnie są skończone, trafiają do przeglądu przez innych developerów (głównie seniorów) za pomocą Merg Request i dopiero po akceptacji są scalane z główną gałęzią deweloperską. Proces ten ma zminimalizować problemy jakościowe kodu oraz przedostaniem się do finalnej wersji tymczasowych, deweloperskich wywołań debugowych.

Wszystkie nasze projektowe standardy na tym etapie, mają za zadanie poprawę efektywności oraz jakości wytwarzanego oprogramowania, a także sprzyjają komunikacji i ułatwiają wdrożenia programistów w nowe projekty. Z drugiej jednak strony, dbamy o to, by pozostawić niektóre detale pod kontrolą zespołu i uszanować indywidualne preferencje deweloperów. To zespół danego projektu decyduje np. o zasadach formatowania kodu, jego statycznej spójności, oraz jakie wzorce projektowe zastosować do poszczególnych zmian.

3. Testy manualne

Każda zmiana musi być zweryfikowana przez testera. Taka weryfikacja ma dwa główne cele: Po pierwsze sprawdzenie, czy zmiana przygotowana przez zespół deweloperski realizuje wszystkie wymagania z opisu zmiany, a po drugie czy zmiana realizuje te wymagania prawidłowo. W 3e Software House etap testów manualnych realizujemy w dwóch fazach. Pierwsza weryfikacja obejmuje tylko indywidualną zmianę. W tej części zmiany są weryfikowane po kolei, gdzie sprawdzana jest jakość pojedynczej zmiany. W tym celu testerzy przygotowują scenariusze testowe na podstawie wymagań funkcjonalnych. Następnie scenariusze te są manualnie weryfikowane przez testerów i na ich podstawie przygotowywany jest raport wraz z ew. lista znalezionych błędów. W drugim zaś kroku weryfikowane jest całe wydanie, czyli wszystkie główne procesy, włącznie ze zmianami, jakie będą wdrożone na środowisko produkcyjne. Celem tego kroku jest weryfikacja, czy wprowadzenie zmian nie spowodowało regresji w teoretycznie niezmienianych funkcjonalnościach. Do weryfikacji tego etapu testerzy używają ogólnych zestawów scenariuszy testowych, które używane są przy każdym wdrożeniu. Obok testów jednostkowych jest to kolejny istotny moment, kiedy staramy się zabezpieczyć nasze oprogramowanie przed błędami regresyjnymi.

4. Wdrożenie produkcyjne

Ukoronowaniem procesu wytwarzania oprogramowania jest oczywiście jego wdrożenie na produkcję. Etap ten jest realizowany po otrzymaniu odpowiednich zgód, czy to od zewnętrznego klienta, czy to wewnętrznych z działu testów i supportu. Po otrzymaniu zgody, zmiana jest commitowana do głównej gałęzi GIT, z której skrypty przeprowadzą automatyczne operacje, takie jest statyczna analiza kodu, CI oraz CD. W przypadku projektów nieposiadających takiej automatyzacji, prace te są wykonywane ręcznie przez dewelopera.

5. Konserwacja

Finalnym etapem jest weryfikacja czy na serwerze produkcyjnym należy przeprowadzić prace konserwacyjne. Prace te obejmują m.in. usunięcie starych danych tymczasowy i backupów, przegląd indeksów w bazach SQL. Po wykonaniu ostatniego etapu procesu deweloperskiego zmiana zostaje przekazana do działu utrzymania.

Wdrożone wiele lat temu i wciąż rozwijane standardy deweloperskie znacząco przyczyniły się do poprawy i ustabilizowania jakości wytwarzanego przez nas kodu, oraz ułatwiły możliwości przepływu pracowników pomiędzy zespołami. Dzięki tym standardom również proces wdrożenia nowych deweloperów staje się nieco łatwiejszy, ponieważ już w pierwszych godzinach pracy nowy członek zespołu ma możliwość zapoznania się zasadami, jakie będą go obowiązywały. Uważamy, że zasady te nie mogą być wyryte w kamieniu i tak dynamiczna branża jak IT, wymaga ciągłej zmiany obowiązujących standardów. Z tego powodu wszystkie opracowane przez nas procedury poddajemy ciągłej ewaluacji i ulepszeniom.