Start projektu to jeden z najważniejszych etapów w jego cyklu życia. W związku z tym kluczowe jest to, aby podczas tego etapu popełnić jak najmniej błędów. Popełnienie istotnego błędu na samym początku projektu może spowodować, że jego konsekwencje będą odczuwalne przez bardzo długi czas, a w skrajnych przypadkach przez cały cykl życia projektu.

W tym artykule podzielę się swoimi spostrzeżeniami co do aspektów, którym warto poświęcić nieco uwagi przy starcie projektu. Stwierdzenia zawarte w tym artykule są bardzo subiektywne i bazują na moich doświadczeniach i przemyśleniach. Dlatego też, szczególnie zachęcam do dyskusji w sekcji komentarzy.

Przede wszystkim zbierz wymagania

Dobrze przeprowadzone zbieranie wymagań nie tylko pozwoli na szybsze ukończenie fazy MVP, ale też pomoże nakreślić dokładniejszą roadmapę dla przyszłych iteracji. Im więcej dowiesz się na tym etapie, tym lepiej dla Ciebie.

Najgorsze co może Cię spotkać na tym etapie, to bardzo ogólnie zarysowane wymagania. Pamiętaj, że osoba zlecająca stworzenie aplikacji może mieć w głowie już wizję na aplikację, a ta wizja może znacząco odbiegać od Twojej.

Posłużę się przykładem:

Potrzebuję strony internetowej dla warsztatu stolarskiego, na której znajdą się zdjęcia moich prac oraz formularz pozwalający na kontakt ze mną.

Przed przystąpieniem do pracy warto przemyśleć i doprecyzować kilka istotnych aspektów:

• czy wspomniany formularz ma być zwykłym formularzem kontaktowym, czy formularzem z prośbą o wycenę?
• jakie pola powinny znaleźć się w formularzu? Warto zastanowić się, czy branża stolarska słynie z komunikacji mailowej, czy raczej lepszym rozwiązaniem będzie dodanie pola na numer telefonu;
• jeśli formularz ma być formularzem wyceny, to czy ów warsztat ma zdefiniowany katalog produktów, czy też specjalizuje się w niestandardowych zleceniach? W zależności od wariantu liczba i przeznaczenie pól może się różnić;
• zlecający nic nie wspomniał o innych możliwościach kontaktu tj. mail, telefon, adres czy mapa dojazdu do warsztatu. Standardem jest, że takie dane znajdują się na tego typu stronach;
• czy zlecający chce mieć możliwość modyfikowania treści strony samodzielnie, czy też zależy mu na otrzymaniu gotowej strony beż możliwości jej modyfikacji?
• jaką zlecający ma wizję co do szaty graficznej zamawianej strony?
• czy zmawiający ma już swoją identyfikację wizualną?
• czy na stronie ma być np. sekcja ze wpisami ściągającymi ruch organiczny na stronę?

Takich pytań można zadać sporo więcej, a już te kilka powoduje, że pozornie banalny projekt już się komplikuje. Daje to do myślenia szczególnie w kontekście dużo większych aplikacji i systemów, przy których podobnych pytań mogą być dziesiątki, a nawet setki. Im więcej doprecyzujesz przed rozpoczęciem pracy, tym lepiej dla Ciebie i zlecającego. Oczywiście nie da się przewidzieć i zaplanować wszystkiego.

Testuj od samego początku

Osobiście traktuję testy na równi z kodem produkcyjnym, a czasami wręcz uważam je za ważniejsze od kodu produkcyjnego. Odłożenie pisania testów w czasie może zakończyć się na kilka sposobów:

• testy zostaną dodane do istniejącej aplikacji bez większych komplikacji.  Uważam prawdopodobieństwo zaistnienia takiego scenariusza za czysto teoretyczne;
• dodanie testów do istniejącej aplikacji spowoduje gigantyczną i bardzo czasochłonną refaktoryzację;
• testy nie zostaną dodane de facto nigdy (podejście „kiedyś się doda, ale obecnie są ważniejsze tematy na tapecie”).

Zarówno scenariusz nr 2, jak i 3 nie brzmią zachęcająco. Dlatego też warto przemyśleć temat testów już na samym starcie projektu. Więcej o testach automatycznych i zaletach z nich płynących dowiesz się z artykułu wprowadzającego do tematyki testów automatycznych oprogramowania.

Warto również wykorzystać serwis ciągłej integracji (Continuous Integration — CI) np. CircleCI czy TravisCI w celu zautomatyzowania procesu uruchamiania testów automatycznych po dokonaniu zmian.

Dokumentacja

Nie każdy lubi pisać dokumentację. Jeszcze mniej osób lubi pracować z nieudokumentowanym kodem lub wracać do nieudokumentowanego kodu po dłuższym czasie. W przypadku większych projektów utrzymywanych przez większe zespoły dobra dokumentacja jest czymś wręcz obowiązkowym.

Ponadto, dokumentacja pozwala na dzielenie się wiedzą w zespole i zmniejsza szansę na tzw. bus factor (ilu członków zespołu musiałby przejechać autobus, by projekt nie mógł być rozwijany dalej). Dokumentacja przydaje się również podczas wprowadzania do projektu nowych osób oraz rotacji osób zaangażowanych w projekt.

Architecture Decision Records — ADR

Szczególnie wartościową formą dokumentacji są Architecture Decision Records — ADR. Dokumenty ADR opisują ważne decyzje architektoniczne podjęte w projekcie w danym kontekście i z konsekwencjami tych decyzji.

Dobry ADR wyróżniają następujące cechy:

• zawiera powód podjęcia decyzji — przykładowo, wybór silnika bazy danych dla aplikacji można uargumentować koniecznością przechowywania danych użytkowników;
• jeden ADR powinien dotyczyć jednej decyzji;
• zawiera czas podjęcia decyzji/utworzenia dokumentu;
• wyjaśnia podjętą decyzję w kontekście wymagań biznesowych;
• zawiera alternatywne rozwiązania wraz z powodem ich odrzucenia, a także z mocnymi stronami alternatywnych rozwiązań.

Szablony oraz przykłady dokumentów ADR znajdziesz na końcu artykułu w linkach w źródłach i materiałach dodatkowych.

Aktualizacja zależności

Jest to pozornie nieistotny temat, który jeśli zostanie zaniedbany, może w dłuższej perspektywie może powodować spore problemy. Nieaktualne zależności przede wszystkim wystawiają aplikację, na ataki z wykorzystaniem podatności wykrytych w nieaktualnej zależności.

Drugim problemem wynikającym z nieaktualnych zależności jest sama czynność ich aktualizacji. Załóżmy, że projekt ma kilka lat, a zależności nie były nigdy aktualizowane. Część z nich otrzymała wiele aktualizacji i o ile zaktualizowanie zależności o jedną wersję wyżej najpewniej nie zajmie zbyt dużo czasu, tak aktualizacja o kilkadziesiąt wersji wzwyż może skutkować dużym i nieoczekiwanym nakładem pracy.

Problem aktualizacji można rozwiązać poprzez zautomatyzowanie tego procesu. Najprostszym rozwiązaniem tego typu (jakie znam) jest Dependabot. Uruchomienie i konfiguracja tego narzędzia są bardzo szybkie. Samo rozwiązanie nie jest idealne i ma pewne bolączki, które ujawniają się szczególnie w przypadku dużych aplikacji i aplikacji opartych o monorepo, niemniej jednak Dependabot jest dobrym punktem wyjścia. Z kolei dla mniejszych projektów powinien być całkowicie wystarczający.

Dobór technologii

Podczas doboru technologii warto zwrócić uwagę na kilka aspektów:

• dokumentacja — przy doborze technologii technologię poprzez zapoznanie się z dokumentacjami różnych rozwiązań zapewne docenisz wartość dobrej dokumentacji. Pamiętaj, że w trakcie rozwoju swojego projektu będziesz często wracał do dokumentacji. Sam fakt istnienia dokumentacji nie jest wystarczający, ponieważ kiepska, myląca czy niekompletna dokumentacja bywa gorsza od braku dokumentacji.
• community i utrzymanie — wybór rozwiązania, wokół którego nie ma zbudowanej społeczności może być problematyczny w momencie, gdy napotkasz niecodzienny problem. Najzwyczajniej, będzie niewielka grupa osób, do której będzie można zwrócić się o pomoc. Duże community zwiększa szansę na łatanie błędów i dodawanie usprawnień. Warto również zwrócić uwagę, na to, jak sami twórcy podchodzą do technologii. Zastanowiłbym się kilka razy, zanim wykorzystałbym technologię, która nie jest już wspierana przez twórców lub jej EOL (end of life) jest przewidziany w niedalekiej przyszłości.
• dojrzałość i stabilność — wiem, że tzw. Hype-Driven Development oraz CV-Driven Development bywa kuszący, ale zachęcam do oparcia się tej pokusie. Przede wszystkim, oprogramowanie ma działać (stabilnie!), i ma przynosić dochody. Chęć wypróbowania nowych technologii może być realizowana w projektach pobocznych lub po upewnieniu się, że rozwiązanie działa stabilnie i jest pozbawione istotnych mankamentów. Niemniej jednak to ostatnie wymaga pewnej ilości czasu. W kwestii doboru technologii sugeruję konserwatywne podejście i dobór dojrzałych i sprawdzonych technologii. Chociażby z uwagi na punkt poprzedni — nowa technologia z definicji ma mniejsze community, ponieważ nie zdążyło się ono jeszcze ukształtować.
• licencja — w calu uniknięcia problemów natury prawnej warto się upewnić, że wykorzystujemy technologię zgodnie z licencją.
• podaż specjalistów na rynku — wiąże się to pośrednio z punktami o dojrzałości i community. Moim zdaniem, nawet najlepsza technologia nadaje się do kosza, jeśli nie ma na rynku obeznanych w niej specjalistów. Już samo znalezienie specjalisty w niszowej technologii generuje gigantyczne koszty, nie wspominając o jego wynagrodzeniu i dalszym utrzymaniu projektu.

KISS i YAGNI

Przy starcie projektu warto mieć na uwadze zasady KISS i YAGNI. Czasami nie ma sensu od samego początku projektować rozwiązań „na zaś” oraz tzw. „przydasiów”. Dodawanie kodu, technologii czy rozwiązań „na kiedyś” może się zakończyć tym, że wspomniane „kiedyś” nigdy nie nadejdzie. Nie oznacza to, że nie należy myśleć długoterminowo, wręcz przeciwnie. Przykładowo, istotnym aspektem, któremu warto poświęcić uwagę od samego początku, jest skalowalność. W tym przypadku, celowe złamanie zasady YAGNI jest według mnie w pełni usprawiedliwione. Przy rozważaniu dodawania rozwiązań do projektu w kontekście zasad KISS i YAGNI należy także rozważyć koszt dodania omawianego rozwiązania w przyszłości.

Automatyzacja FTW

Automatyzacja pewnych procesów na wczesnym etapie jest przeciwieństwem YAGNI. Będziesz tego potrzebować, i to bardzo. W dłuższej perspektywie zautomatyzowanie pewnych czynności oszczędzi ogrom czasu i usprawni pracę. Przykładowymi czynnościami, jakie można zautomatyzować są:

• uruchamianie testów automatycznych poprzez wykorzystanie CI;
• release aplikacji dzięki Continuous Deployment (CD);
• aktualizacja zależności;
• skanowanie aplikacji pod kątem CVE;
• release paczek do repozytoriów tj. npm, Maven repository, Docker Hub, etc.;
• generowanie powiadomień/alertów na podstawie odczytów z metryk z aplikacji;
• monitoring aplikacji.

Lista czynności możliwych do automatyzacji jest ogromna i tak naprawdę ogranicza nas jedynie wyobraźnia.

Podsumowanie

Tak jak już pisałem we wstępie, artykuł ten jest bardzo subiektywny. Dlatego rozumiem, że nie każdy może się zgodzić z tym, co jest w nim zawarte. Raz jeszcze zachęcam do dyskusji w komentarzach. Jak zwykle zachęcam też do zapoznania się ze źródłami i materiałami dodatkowymi.

Źródła i materiały dodatkowe

• Thinking Architecturally – Nataniel Schutta
• Czym jest Minimum Viable Product?
• Podstawy testów automatycznych oprogramowania
• Modern Software Over-Engineering Mistakes
• Architecture decision record (ADR)
• Template for documenting Architecture alternatives and decisions
• Architectural Decision Records (ADRs)
• Patoarchitekci – #13 ADR, czyli Architecture Decision Record
• Dependabot
• Hype Driven Development
• Hype Driven Development
• Are You a Hype-Driven Developer?
• Diffusion of Innovation Theory
• SOLID, KISS i DRY

Zaobserwuj mnie na LinkedIn!

LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zaobserwuj mój profil na LinkedIn, by być na bieżąco!
Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.

Udostępnij wpis

Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!

📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.

Chcesz docenić moją pracę? Postaw mi kawę!