SoloProgramming?

Table of Contents

SoloProgramista vs SoloProgramming

Jak dobrze wiesz, w programowaniu jest wiele różnych sposobów rozwiązania problemu. Tworząc aplikację można zastosować mikroserwisy, monolity albo arkusz kalkulacyjny. Wybór konkretnego podejścia uzależniony jest od wielu czynników: budżetu, wielkości zespołu, przewidywanego obciążenia aplikacji itp. Na blogu znajdziesz podejście w moim odczuciu optymalne dla zespołu składającego się z jednego lub max. dwóch programistów, którzy nie posiadają dużego budżetu. Nazwałem je roboczo SoloProgramming. Jeśli natomiast pracujesz w międzynarodowej korporacji to jest duża szansa, że niektóre porady mogą nie być odpowiednie dla Ciebie (aczkolwiek wiele technik, które opisuję nadal się sprawdzi).

SoloProgramming jest uprawiany przez SoloProgramistę 😉 Jak możesz określić, czy nim jesteś? Oto parę wskazówek:

Jesteś sam
Minimalizujesz koszta
Nie lubisz testować
Wiesz, że czas jest cenny

Jesteś sam

Nie znaczy to, że nie możesz mieć żony ani kolegów:) Wręcz przeciwnie, żona czasem się przydaje 😉 Jednak, jeśli chodzi o tworzenie wymarzonej aplikacji, to tworzysz ją sam. Może pracujesz po godzinach, albo jesteś już na etapie rezygnacji z etatu i zakładania własnej działalności, bo masz pierwszych klientów. Nie ma znaczenia. Zakładam, że w obu przypadkach jesteś jedyną osobą, która musi ogarnąć cały projekt. A jest co ogarniać.

Analiza funkcjonalna aplikacji
Zaprojektowanie architektury
Wybranie stacku technologicznego
Kodowanie
Bug fixing (maintenance)
Zarządzanie infrastrukturą hostingową
Testowanie
Projektowanie UI
Kontakt z klientami/użytkownikami
Marketing
Fakturowanie klientów

Pewnie jeszcze coś by się znalazło (nie, nie mówię o tym, że rząd wprowadzając Nowy Ład nie ułatwia życie. Nie, nie mówię o tym ;)). Roboty jest naprawdę dużo. Dlatego trzeba ją minimalizować i optymalizować. Wszystko co można to automatyzujemy i upraszczamy. Nie ma innej opcji. Inaczej po pół roku kodowania i pierwszych błędach od użytkowników, nie będziesz wiedział w co ręce włożyć.

Wyobraź sobie, że Twój program już działa. Masz pierwszych klientów. Robisz wszystko samodzielnie, od kodowania, po bug fixing i marketing. Jeden z użytkowników potrzebuje nowy ficzer, więc ochoczo zaczynasz go implementować. Po dwóch dniach masz zgłoszenie o poważnym błędzie w aplikaci, który musisz szybko naprawić. Sprawnie przełączasz się na nowego brancha w gicie i lecisz z bug fixingiem – w końcu klient czeka. Tego samego dnia zauważyłeś, że certyfikat SSL właśnie wygasł i musisz Let’s Encryptem stworzyć nowy. A w międzyczasie dostałeś maila od klienta, że potrzebuje fakturę za zakup konta premium. Uwierz mi, takie sytuacje mogą być i będą.

Jak się przed tym bronić – automatyzując wszystko co można. Oczywiście nie chodzi o to, że jak pierwszy klient chce fakturę to od razu masz napisać mechanizm, który będzie wystawiał i wysyłał je automatycznie. Jeśli masz dwóch klientów, którzy płacą, to spokojnie możesz wystawić je ręcznie. Jednak gdy widzisz, że coraz częsciej robisz tą samą czynność, jest to sygnał, że czas na automatyzację. Certyfikat SSL może być przedłużany automatycznie, backup bazy także powinien wykonywać się bez Twojego udziału.

Przykład z życia

easyWSDL używają programiści z całego świata, co utrudnia rozliczanie zarobionych pieniędzy. Część klientów chce fakturę, inni nie. Każdy kraj ma inną stawkę podatku VAT. W UE rozliczamy inaczej niż poza wspólnotą. Początkowo moja żona na koniec miesiąca przygotowywała zestawienie dla księgowej. Trwało to co miesiąc ok 2h. Była to żmudna praca, która nie była wolna od błędów.

W końcu napisałem aplikację, która ściągała płatności z PayPala i wystawiała faktury. Czas poświęcony na tworzenie zestawienia zmniejszył się z 2h do 1 min. W tym rozwiązaniu był jeszcze problem stawek VAT, gdyż co jakiś czas one się zmieniały w różnych krajach. W takiej sytuacji faktura była wystawiona błędnie i trzeba było poprawiać i przepraszać klienta. Obecnie stawki VAT są też pobierane z Internetu, więc i ten problem został rozwiązany.

Korzystaj z gotowych komponentów (najlepiej bezpłatnych ;)) kiedy tylko masz okazję. Często programiści mają ochotę implementować wszystko samodzielnie, od loggera po własny mechanizm serializacji. I na pewno jest to bardzo satysfakcjonujące, gdy po tygodniu zagłębiania się w meandry C# i refleksji, żeby stworzyć mechanizm zapisujący obiekty do JSON, efekt jego działania jest o 5ms lepszy niż zewnętrzna biblioteka z Nugeta. Jednak na koniec dnia, te 5ms wydajności prawdopodobnie nie będzie miało znaczenia dla całego programu, a ilość czasu, którą będziesz musiał poświęcić jest ogromna. Każdy kod trzeba utrzymywać. Jeśli poświeciłeś tydzień na implementację, to dolicz do tego miesiąc na bug fixing tego komponentu. Im więcej zrobisz sam, tym więcej będziesz miał na głowie.

Minimalizujesz koszta

Wiele rzeczy możemy zdobyć na dwa sposoby: zrobić albo kupić. Obie opcje są dobre, a wybór konkretnej wynika między innymi z wielkości budżetu. Dla przykładu: jednym z etapów tworzenia aplikacji, jest wykonanie interfejsu użytkownika. Moim skromnym zdaniem, UI jest ważny – program musi dobrze wyglądać. Jeśli stać Cię, aby wynająć grafika czy eksperta od UI to powinieneś tak zrobić (zakładam, że podobnie jak ja, nie masz w tej materii dużego doświadczenia). Jednak jeśli nie zamierzasz zlecać to będziesz musiał zrobić to sam. A jest to zadanie trudne i pracochłonne. A mówimy tylko o jednym z wielu tasków. Rzeczy, które będziesz musiał zrobić własnoręcznie, jest więcej.

W Internecie wiele (większość) rzeczy możesz znaleźć za darmo. Ja w swoich projektach korzystam z następujących (bezpłatnych) elementów:

Narzędzia programistyczne (to zakładam, że jest jasne)
Ikony
Obrazki
Certyfikat SSL
Serwer mailowy, pod który można podpiąć własną domenę
Hosting (przynajmniej częściowo)
Narzędzie do dokumentacji
Obsługa płatności

Powyższa lista nie jest kompletna, jednak pokazuje, że jak poszukasz to znajdziesz prawie wszystko. Oczywiście nie zawsze to co znajdziesz jest idealne, może będziesz musiał się jakoś dostosować, albo w darmowej wersji będzie ograniczenie ilościowe.

Jak zatem ogarnąć UI w programie? Najprościej bierzesz Bootstrapa i lecisz. Możesz także znaleźć darmowy theme i na nim się oprzeć. Oczywiście korzystanie z popularnych frameworków ma swoje wady. Wiele stron jest na nich zbudowana więc wszystkie mają podobne elementy. Jednak dla SoloProgramisty nie jest to problem. Pamietaj, jesteś sam i arcydzieła raczej nie stworzysz. A dzięki gotowym rozwiązaniom, uzyskasz dobry efekt mniejszym nakładem pracy. W SoloProgrammingu liczy się stosunek kosztów do uzyskanego efektu.

Nie lubisz testować

Nie po to zostałeś programistą, żeby testować swój kod, prawda? Większość programistów tego nie lubi, a co więcej, nie potrafi tego robić. Testowanie to ciężka i monotonna robota. I nie mówię o przetestowaniu, czy ficzer, działa. Mówię o tym, że implementując jeden ficzer, możesz popsuć coś innego. Tak naprawdę, to przy każdym releasie powinieneś testować cały program. Zwłaszcza jak marzy Ci się wdrożenie CI/CD. W przypadku firm, które mają dział testerów, to testy manualne nie są aż takim problemem. Jednak w sytuacji SoloProgramisty – nie ma takiej opcji. Nie będziesz mieć ochoty ani czasu na przeklikanie całego programu za każdym razem, gdy coś zmienisz w kodzie.

Dlatego piszesz testy automatyczne od początku projektu. Interesują Cię przede wszystkim testy:

Jednostkowe
Integracyjne
E2E

Im więcej przetestujesz automatycznie, tym mniej będziesz musiał klikać – proste. W najbliższym czasie opiszę moje podejście do testowania aplikacji SaaS.

Przykład z życia

Głównym elementem aplikacji easyWSDL jest parser WSDL oraz generator kodu. Są to dość złożone moduły, obsługujące setki różnych przypadków. Gdyby nie pokrycie prawie 100% testami, NIE BYŁBYM W STANIE utrzymywać tego kodu. Użytkownicy zgłaszają błędy i często naprawa jednego powodowała popsucie innego scenariusza. Bez testów nawet bym o tym nie wiedział. A tak, to po każdej zmianie odpalam testy i mam 99% pewności, że obecne funkcjonalności nadal działają. Releasy mogę robić na bieżąco, naprawiam buga, odpalam testy i kod jest na produkcji.

Możesz zapytać: „Romek, jak mają się te rady do tworzenia pierwszego MVP, który z założenia ma być jak najprostszy?”.

A ja Ci odpowiem: „doskonałe pytanie drogi czytelniku” 🙂

A potem dodam: podejście, które opisuję zakłada, że samodzielnie chcesz stworzyć działający program. Nie wspominam o tym jak znaleźć pierwszych klientów, jak sprawdzić, czy pomysł wypali czy nie. Jeśli nie wiesz, czy ktokolwiek będzie używać Twojego programu, to powinieneś skupić się bardziej na badaniu rynku i tego typu czynnościach. Gdy już stwierdzisz, że chcesz ten program stworzyć, to podejście SoloProgramming Ci w tym pomoże.

Czas jest cenny

Ten punkt jest podsumowaniem powyższych. Doba ma ograniczoną ilość godzin, a stworzenie aplikacji, z której korzystają inni ludzie, jest bardzo pracochłonne. Co jeszcze może zrobić SoloProgramista, aby zaoszczędzić czas?

Wybrać odpowiedni stack technologiczny. Pewnie w tym momencie myślisz sobie: „byłem ostatnio na konferencji, gdzie prelegent pokazywał nowy super framework do tworzenia super skalowalnych aplikacji, przy której microserwisy są zabawką dla dzieci – fajnie byłoby się tego nauczyć„. Niestety z takim podejściem to może nauczysz się nowego frameworka, ale aplikacji nie zbudujesz.

Jeśli Twoim priorytetem jest ukończenie projektu, to warto wybrać stack technologiczny, z którym czujesz się dobrze. Przynajmniej 80% elementów (architektura, języki programowania, frameworki itp) powinieneś znać dobrze. Pozostałe 20% możesz się nauczyć – przynajmniej będziesz miał trochę radochy. Jednak, gdybyś wpakował się w sytuację, gdzie 80% dopiero poznajesz, to po miesiącu prawdopodobnie się zniechęcisz. Codziennie zamiast pisać program, będziesz z czymś walczyć: tutaj nie wiesz, dlaczego npm sypie błedami, aplikacja raz na 2 dni się zamyka, a w IDE jak zmienić opcje kompilatora.

Podobnie wybór architektury ma kolosalne znaczenie. Nie pakuj się w microserwisy czy inne zaawansowane rozwiązania. One są dobre, ale dla aplikacji, która ma obsługiwać tysiące klientów jednocześnie, a team składa się z 5 programistów NA KAŻDY microserwis. Gdy zaczynałem easyRenti, też miałem plan nauczyć się microserwisów. Poczytałem, pooglądałem tutoriale i zacząłem kodować. Po 2-3 miesiącach miałem dopiero ogarniętą autoryzację i tworzenie pierwszych obiektów domenowych (aplikacja kliencka jeszcze oczywiście nie istniała itp). Każde dodanie czegokolwiek do tej architektury wymagało sporo pracy i wysiłku. Opadłem z sił po 3 miesiącach. Po roku wróciłem do projektu i pierwszą rzeczą była aktualizacja Nugeta – lubię jak są nowe wersje pakiecików:) Niestety po tej operacji, moje zaawansowane microserwisy przestały działać. I pewnie byłbym w stanie to ogarnąć w przeciągu tygodnia, ale wtedy już wiedziałem, że albo nauka microserwisów, albo ukończony projekt.

Wybrałem projekt. Zastosowałem architekturę, którą dobrze znam, oparłem wszystko na platformie .NET i C# (stąd aplikacja kliencka to Blazor). Oczywiście samego Blazora nie znałem, więc miałem dużo radości z poznawania tego frameworka, jednak w pozostałych elementach czułem się jak ryba w wodzie. W przeciągu 5 miesięcy miałem pierwszą wersję aplikacji.

Podejście, które opisuję, nie jest w każdym przypadku najlepsze od strony wydajności kodu, czy skalowalności. Jednak oszczędza mnóstwo czasu i nerwów. A przede wszystkich sprawi, że będziesz w stanie doprowadzić projekt do końca.