Metodyki tworzenia oprogramowania

W procesie powstawania oprogramowania wykorzystuje dwie metodyki:

1. eXtreme Programming, XP
2. CI/CD

eXtreme Programing

Ta metodyka zakłada powstawanie systemu w sposób iteracyjny, organiczny. Cel końcowy projektu nie jest bardzo ściśle określony, ewoluuje w trakcie tworzenia, jest elastyczny.

Najważniejsze cechy

Iteratywność

Program tworzy się w iteracjach (krótkie, przyrostowe kroki programistyczne) – i co ważniejsze – planuje tylko następną iterację. Efektem każdej iteracji (kilka tygodni) powinna być wersja programu spełniającą założenia dla danej iteracji. Następnie planuje się co zrobić dalej.

Odpowiada to zasadzie Open Source: „release early, release often” (wczesne i częste wydania).

Nie projektować z góry

Nie można z góry przewidzieć, jaka architektura będzie najlepsza dla danego problemu. Dlatego należy ją tworzyć w miarę rozszerzania programu.

Testy jednostkowe

Testy jednostkowe pisze się zanim w ogóle zacznie się pisać kod – najlepiej na początku iteracji. Potem pisze się kod, który potrafi je wszystkie przejść. Takie testy dają zapewnienie (o ile testy są dobrze napisane), że to, co ważne, zostanie zaprojektowane, na to zaś, co nie jest ważne, programiści nie będą tracić czasu.

Ciągłe modyfikacje architektury

Architektura nie jest czymś, czego nie wolno ruszać. Jeśli modyfikacja architektury ułatwi przejście danej iteracji i nie zepsuje wyników testów uzyskanych na poprzednich, należy ją wykonać. Pod tę zasadę podlega także usuwanie wszystkich znanych błędów przed rozszerzeniem funkcjonalności.

Realizacja w praktyce

W iteracyjnym procesie powstawania systemu informatycznego ważną rolę pełni system kontroli wersji. W tym projekcie korzystam z GIT. Każda główna iteracja oznacza stworzenie nowej gałęzi(branch), w której nazwie znajduje się numer aktualnej iteracji (major version). Główna iteracja składa się z iteracji podrzędnych (minor version), które w git występują jako commit w ich nazwie występuje odpowiedni numer iteracji podrzędnej. W momencie uznania, że aktualna wersja (major version) spełnia wymagania ustalone na początku iteracji dokonuje operacji scalania merge aktualnej gałęzi z gałęzią główną master-branch. W tym momencie tworzona jest kolejna gałąź z nazwą odpowiadającą kolejnej iteracji i cykl się powtarza.

Pseudo kod powyższego opisu:

let majorVersion =0;
let minorVersion =0;
while(true)
{    
    git.newBrach(name: majorVersion) //tworzę nową gałąź
    wyznaczNowyCel();
    while(!czyCelZostałOsiągniety())
    {
        realizacjaCelu();
        git.commit(name: minorVersion);
        minorVersion++;
    }
    git.merge() // scalanie z master
    minorVersion=0;
    majorVersion++;
}

Poniższy screen obrazuje powstałą w ten sposób strukturę commits i branches. Niebieska linia przedstawia gałąź master, kolorami przedstawione są wszystkie gałęzie kolejnych iteracji

CI / CD

Jest to maksymalne zautomatyzowanie i przyspieszenie procesu przetworzenia kodu źródłowego do gotowego systemu informatycznego

Realizacja

Wykorzystuję do tego celu dwa narzędzia:

1. framework NextJS
2. platformę GitHub

NextJs

Umożliwia kompilacje kodu do postaci, która może być udostępniana przez serwer przeglądarkom internetowym. Projekt jest pisany w TypeScript, ponadto wykorzystuje komponenty React Ten cały kod musi zostać skompilowany do JavaScript/Html.

GitHub

Github jest platformą, która umożliwia:

1. hostowanie repozytorium Git <- to jest najważniejsze zadanie GitHub'a
2. hostowanie statycznych stron internetowych <- dokładnie tego potrzebuje w tym projekcie
3. dokonanie pewnych operacji w ramach GitHub Actions . To znaczy kompilację kodu źródłowego do postaci wymaganej przez serwer i przeniesienie tego (deploy) na serwer statycznych stron GitHub. Akcją jest wyzwalana przez jakiś triger, w tym przypadku jest to modyfikacja gałęzi master, to znaczy każdy push do tej gałęzi aktywuje akcję. Zadania w ramach akcji są zdefiniowane w repozytorium w katalogu .github/workflos w pliku z rozszerzenie .yml. Tutaj korzystam z gotowego pliku przygotowanego dla tego frameworka.

podsumowanie

Dzięki temu każde wypchnięcie gałęzi master na maszynie developera po krótkiej chwili skutkuję powstaniem nowej wersji aplikacji na serwerze użytkowym.