Proste zasady tworzenia projektów informatycznych od zera

Spotkałem się z wieloma, różnymi regułami jak powinny być tworzone projekty aplikacji informatycznych. Niestety, większość okazała się totalnie niedopasowana do projektu. Zadałem więc sobie jedno pytanie: dlaczego tak się dzieje, że postępując według dobrych praktyk, problemy w projektach zaczynają się piętrzyć, a koszt rozwiązania zadania rośnie? Zauważyłem kilka podstawowych błędów.

Mariusz Walczak. Tech lead w Softfin. Absolwent Warszawskiej Wyższej Szkoły Informatycznej. Pasjonat inżynierii oprogramowania, swoje aplikacje tworzy w PHP i językach opartych na ES6/7. Prywatnie miłośnik futrzanych czworonogów, oraz winiarstwa i nalewkarstwa.

Oto one:

Wybieramy zestaw dobrych praktyk, zanim dowiemy się o co chodzi

Niestety ma to miejsce i teraz. Byłem na projekcie w jednoosobowym zespole scrumowym, ale nie byle jakim. Miałem retrospekcje i planowanie, a w zasadzie byłem ja i właściciel projektu. To nie była moja decyzja i na szczęście szybko się zmieniła, po prostu osoba, która ją podjęła, zrobiła to automatycznie, trzymając się zasady: jest projekt, to lecimy scrumem. W tym konkretnym przypadku projekt tracił, gdyż tygodniowo 10h było przepalanych na spotkania, które w ogóle nie miały sensu.

Innym problemem jest to, że od razu żenimy się z jakąś technologią. Sam popełniałem ten błąd. Jak projekt to symfony, jak front to Angular. Teraz widzę, że to było złe myślenie, bo zanim jeszcze poznałem o co chodzi, to już skazywałem się na walkę z tymi frameworkami.

Innym problemem jest z góry ustalanie, w jakiej architekturze napiszemy projekt — właśnie w ten sposób powstają aplikacje, które mają piękną rozbudowaną architekturę, a są zwykłą wizytówką. Pisałem kiedyś projekt, który miał dwa backendy: backend 1 był pośrednikiem pomiędzy serwerem aplikacji, a serwerem danych. Backend 2 był serwerem danych do aplikacji. Ogólnie wszystko pięknie, ale po kilku miesiącach pisania tej dużej pokraki okazało się, że obsługujemy sześć stron typu landing-page, które w zasadzie można było postawić na WordPressie w jeden dzień. Aplikację pisało ponad stu programistów, analityków, architektów, administratorów, a praca pochłonęła ponad 10 mln zł.

Podsumowując w skrócie ten punkt: po prostu za szybko podejmujemy decyzję, jak będzie ten projekt budowany.

Zobacz też

Praca w IT Macierz dojrzałości, czyli jak usprawnić proces tworzenia oprogramowania w całej organizacji

Nie rozumiemy celu aplikacji jaką mamy stworzyć

Programista musi zrozumieć cel napisania aplikacji. Nie musi rozumieć jak aplikacja będzie działać w 100%. Powiem to na trochę niecodziennym przykładzie. Druga wojna światowa, amerykanie stawiają czoła doświadczonym, niemieckim żołnierzom w Ardenach. Mimo że zostali spisani na straty — utrzymali się. Nie rozumieli do końca jak jest z tą taktyką na froncie. Wiedzieli jednak, że jeżeli się poddadzą, zostaną zastrzeleni, spaleni żywcem albo zadźgani, więc bili się z pełną zaciekłością do ostatniego tchu, bo rozumieli cel tej walki.

Tak samo jest z projektem. Jeżeli wiemy, że aplikacja zarabia na płatnych ogłoszeniach, to nie musimy rozumieć całego systemu. Wiemy co jest w nim najważniejsze i co musi działać, choćby nie wiem co.

Brak należytego kierowania projektem

Często jest tak, że osoba, która prowadzi projekt nie do końca wie jak to robić. Przez to zespół nie wie co ma robić, bo co chwila coś się zmienia. Panuje wtedy wewnętrzny chaos, który zawsze źle się kończy.

Każdy projekt potrzebuje osoby, która powie programistom, co mają robić, na czym się koncentrować, a co jest mniej ważne. Osoba ta ma za zadanie pilnować, by założenia projektu zostały spełnione. Brak takiej osoby powoduje to, że ludzie na projekcie wezmą na siebie swój kawałek tortu, z którym im najwygodniej i będą pilnować go, aby nikt im go nie zabrał. Wtedy wiele tematów pozostaje bez opieki, dochodzi też do sprzeczek, bo każdy ma różne wizje. Przez brak lidera, projekt jest skazany na porażkę.

Brak architektów

Dwa razy miałem w projekcie kogoś, kogo można nazwać architektem. W wielkim skrócie, architekt ma olbrzymią wiedzę, narzuca pewne standardy i pilnuje, by były one utrzymywane. To osoba, która rozplanowuje aplikacje tak, aby to co ważne działało, to co często zmienia się było szczegółem, a to co mniej istotne, było zrobione na koniec. Ogólnie to osoba, która buduje aplikacje, poprzez własną pracę, delegowanie zadań, oraz adaptacje do warunków w jakich projekt będzie budowany.

Brak architekta bardzo często doprowadza, do wielu problemów. Najgorsze jest to, że te problemy pojawiają się po pewnym czasie, np. po trzech miesiącach, kiedy projekt jest na zaawansowanym etapie. Brak architektów prawie zawsze powoduje, że im dłużej mamy do czynienia z rozwijaniem projektu, tym więcej czasu poświęcamy na każdą zmianę. Dobry architekt nie doprowadzi do tego typu sytuacji i wzrost nakładu pracy będzie minimalny.

Oferty pracy z

Niesłuchanie programistów

Często programiści zwracają uwagę, że coś się nie uda, że padnie baza, że takie rozwiązanie zajedzie serwer, że klient nie będzie zadowolony, bo aplikacja będzie wolna. Szefostwo jest głuche na tego typu sygnały, bo klient nasz pan i musi mieć wszystko. Wtedy mamy do czynienia z tykającą coraz głośniej bombą.

Szefostwo bardzo często nie słucha szeptów ze studni, dla niego liczy się zysk, a programiści jakoś poradzą sobie z napotkanymi problemami. No właśnie nie zawsze, wtedy klient co prawda dostaje co chce, ale nagle jest wiele problemów, nie działa to tak jakby sobie to wyobraził i pojawia się duży problem.

Jak dobrze zrealizować projekt

No dobrze, mamy kilka głównych problemów przy tworzeniu projektów od zera, to jak robić te problemy, aby było wszystko dobrze?

Na projekty, które nie są jednostrzałowcami, czyli takimi, które robi się w miesiąc i z góry wiadomo, że nie będą rozwijane, a ich długość życia u klienta wynosi dwa miesiące, to mój sposób się sprawdzi, choć jest przerostem formy nad treścią. Lepiej będzie wyglądało jeżeli nasz projekt jest nastawiony na kilka miesięcy pracy i klient szybko chce coś zobaczyć.

Zbieramy informacje

Zbieramy informacje odnośnie tego, co klient w ogóle chce mieć. Na podstawie tego tworzymy diagramy użycia i wysyłamy do klienta, gdy on je zaakceptuje. To możemy ruszać z pracami.

Faza I

W tym momencie dzielimy ludzi na dwie grupy, lub czas na dwa etapy. Zaczynamy jednocześnie prace deweloperskie i analizy. Celem analiz jest stworzenie modelu danych, wyszukanie jak najwięcej wyjątków nieścisłości oraz jaką formę mają mieć dane. Część deweloperska na tym etapie będzie polegała na tym, aby wszystkie przypadki użycia już zacząć implementować.

No tak, ale co zrobić, kiedy nie znamy modelu danych, nie wiemy jakiej bazy użyjemy, z jakiego frameworka skorzystamy? A może by tak nie żenić się z frameworkiem, bazą danych i innymi rzeczami tak od razu? Co za różnica czy dany element będzie miał 7 pól do wyświetlenia, czy 4? Wiemy, że trzeba go wyświetlić, można więc napisać to tak, że niezależnie od ilości pól będzie się on wyświetlał prawidłowo. Podobnie z edycją, czy usuwaniem — mechanizm jest odgórnie znany. Także my możemy sami te mechanizmy implementować i powinniśmy to zrobić.

Faza II

Po zakończeniu tej fazy, powinniśmy mieć już rozplanowany model i uszczegółowione wszystkie przypadki użycia. Jeśli chodzi o aplikacje, powinna ona mieć zaimplementowane przypadki użycia. Teraz przechodzimy do implementacji ich wszystkich. Dopiero po zakończeniu tego zadania możemy przejść dalej.

Faza III

Na początku tej fazy mamy wszystkie przypadki użycia już zaimplementowane. Teraz znając już dokładne wymogi, możemy podjąć decyzje odnośnie frameworka, czy używamy jakiegoś, czy może sobie darujemy, bo to co mamy jest wystarczające. Możemy podjąć decyzję jakiej bazy użyć. Najważniejsze teraz to, by model danych zaimplementować do naszych przypadków użycia.

Czemu tak wiele decyzji z pozoru kluczowych jest dopiero tutaj, bo dopiero na tym etapie mamy pełen obraz projektu, już wiemy jakie są jego wady, zalety, niuanse.

Wcześniej tego nie wiedzieliśmy, mieliśmy tylko mglisty ogląd na to co nas czeka. Pamiętajmy, że dopiero przepracowanie na projekcie jakiegoś czasu daje nam ten ogląd, nawet gdybyśmy znali dokumentacje na pamięć to i tak będziemy mieli tylko mgliste pojęcie, bo wiele rzeczy wyjdzie z czasem.

Faza IV

Na tym etapie dopieszczamy aplikacje, aby wszystko dobrze się wyświetlało, aby model był dobrze zintegrowany z przypadkami użycia. To jest etap, który klient może zobaczyć i testować. Na tym etapie aplikacja wychodzi ze stadium larwalnego, do stadium utrzymaniowego. Tutaj już dostajemy nasze ukochane zadania, typu rysunek się źle wyświetla, albo strona się nie ładuje, jak 50 razy klikam w ten guzik itd.

Zobacz też

Backend Co jest najtrudniejsze w byciu developerem? Seniorzy odpowiadają (cz.3)

Podsumowanie

Cała sztuczka w tej metodzie, polega na wyizolowaniu szczegółów aplikacji, od jej prawdziwego celu, czyli przypadków użycia. Dla klienta nie będzie ważne, czy to spring, czy symfony, czy hateoas, czy soap. To są tylko szczegóły. Osobiście lubię uszczegóławiać wszystko to, co jest często zmieniane, czyli sprawiam, że zmiana tego nie będzie mi rozsypywać systemu. Gdy skoncentrujemy się na przypadkach użycia i zaczniemy je implementować, dowiemy się o co chodzi w naszej aplikacji. Mając pełen ogląd na wszystko i już zbudowany jej core, jaki klient zaakaceptuje, podejmujemy decyzje odnośnie szczegółów. Dopiero teraz żenimy się z frameworkiem, lub bazą, albo nie żenimy, to zależy od nas.

Najgorsze co może być, to walka z ułomnościami i ograniczeniami frameworka, zamiast wykonywanie zadań. Frameworki dają na początku fajnego kopa, wszystko szybciej powstaje, ale po roku czy dwóch, zaczynają być uciążliwe, bo mamy na głowie kilka zadań jakie są albo ledwie co wykonywalne, albo w ogóle nie wykonywalne z powodu frameworka.

Dodatkowo ten schemat nie powoduje tego, że programiści czekają na analityków. W zasadzie można już wszystkie przypadki użycia zaimplementować bez modelu danych. Skracamy dzięki temu czas potrzebny na deweloperkę, oraz uniezależniamy się od decyzji, na które nie mamy dużego wpływu, czyli uszczegóławiamy, to co machinalnie uznalibyśmy za najważniejszy element aplikacji.

Zdjęcie główne artykułu pochodzi z pexels.com.