Żeby odbiór artykułu był zgodny z moim założeniem, zacznijmy od przykładu.
To jest Fugas lub IED – improwizowany ładunek wybuchowy, przygotowany gdzieś w garażu, w kraju, o którym pewnie nawet nie słyszeliście, przez człowieka, który prawdopodobnie nawet nie potrafił czytać.
A to Spike – kosztujący 100 tysięcy dolarów za sztukę, ultranowoczesny system przeciwpancerny – pocisk kierowany.
Odpowiedz sobie na pytanie: co byś wybrał?
Prawdopodobnie zachwycimy się techniczną doskonałością Spika, oprogramowaniem systemu naprowadzania, które z łatwością jesteśmy w stanie zintegrować z każdym innym systemem naprowadzania, czy to lotniczym czy naziemnym. Prawda, niestety, jest taka, że końcowy użytkownik potrzebował czegoś, czego może użyć osoba po pięciu minutach szkolenia, a nie po ciężkim czterotygodniowym kursie w wyspecjalizowanej jednostce wojskowej…
Doskonałość
Mam wrażenie, że trochę się zastaliśmy. Uważamy DDD, CQRS, mikroserwisy i wszystkie inne sugestie wywodzące się z szeroko rozumianej “czystej architektury” za nasz cel. Wszystko, co piszemy, niezależnie od okoliczności, musi być idealne. Przypominają mi się dwa przykłady zasłyszane na konferencji. Pierwszy, gdy młody programista stanął przed zadaniem dodania obsługi żółtego światła w module sterującym sygnalizacją na skrzyżowaniu. To, co zespół wycenił na dwa dni pracy, nasz młody programista implementował dwa tygodnie. Gdy przyszło do oceny kodu przez jego kolegów okazało się, że dołożył kolejne abstrakcje, fabryki, testy.
Na pytanie dlaczego nie skopiował po prostu kawałka kodu stwierdził rezolutnie:
- A co jak będziemy dokładać kolejny kolor?
Ale klient zamawiał światła drogowe, nie dyskotekowe oświetlenie.
Kolejnym przykładem jest prosty panel użytkowników. Jeżeli jedynym wymaganiem klienta jest zarządzanie użytkownikami, to możemy napisać prostego CRUDa, wykorzystując bazę MySQL oraz kilka klas w PHP, zachowując oczywiście podstawy programowania obiektowego i tym samym przygotować rozwiązanie w kilka godzin. Czemu nie zaproponowałem by wrzucić wszystko w jeden plik? Oczywiście, takie rozwiązanie zadziałałoby, ale byłoby niechlujnie, pokazujące brak poszanowania dla klienta. Osoba uciekająca nie do takich metod nie powinna zasługiwać na prestiż a co za tym idzie na wysokie wynagrodzenie. Promuję wykorzystywanie odpowiednich rozwiązań pod założone cele.
Co w sytuacji, gdy przy dodawaniu użytkownika trzeba sprawdzić odpowiednią licencję, przypisać do grup, wysłać maila powitalnego i obciążyć konto zaliczką? Czy nadal możemy postąpić tak jak w poprzednim przypadku? Oczywiście możemy, ale nie jest to dobrym pomysłem. Dlaczego? Ponieważ właśnie stworzyliśmy system, który robi… wszystko.
Lepiej wykorzystać to co oferują odpowiednie narzędzia. Może trzeba rozbić to na mikroserwisy? Wysyłka wiadomości i pobieranie opłat nadają się do tego idealnie. Ale czy musimy robić to synchronicznie i kazać klientowi czekać? Może użyć do tego CQRS i robić to asynchronicznie?
Dług technologiczny
Każdy z nas to kiedyś zrobił, poszedł na skróty. Zaciągnął dług technologiczny. Ale czy musimy go spłacać? Czy musimy w tym momencie dodawać taski i planować poprawki w kolejnych sprintach?
To oczywiście… zależy :P
Chcesz rozwijać dany element? To jak najbardziej tak.
Nie chcesz? Działa? Nie ruszaj! Nie rób refaktoryzacji na siłę.
Każda refaktoryzacja powinna być wykonywana na podstawie konkretnych przesłanek. Dlaczego chcemy zmienić konkretny kawałek? Jaki będziemy mieli z tego zysk? Czy nowe funkcje będą szybciej dostarczane? Czy kod będzie wykonywał się szybciej? Refaktoryzacja tylko po to żeby usunąć nieładny kod nie ma sensu.
Wartość
Jesteśmy sporym kosztem dla klienta. Oczywiście te pieniądze nam się należą, bo przecież jesteśmy w końcu programistami. Teraz musimy się zastanowić, za co klient płaci?
Z naszego punktu widzenia to oczywiście za superkalowalną aplikację, napisaną w otwartej czystej architekturze z wykorzystaniem najnowszych technologii. Wprowadzimy odpowiednie abstrakcje, użyjemy DDD, rabbitaMQ. Jednym słowem wszystkiego, z czego można skorzystać w ramach CVDD (CV driven development). Oczywiście zrobimy to, bo musimy się przecież rozwijać :)
Czekaj, stop!
Podoba Ci się to co tworzę? Jeśli tak to zapraszam Cię do zapisania się na newsletter:Jeśli to Cię interesuje to zapraszam również na swoje social media.
Jak i do ewentualnego postawienia mi kawy :)
Ile klient za to zapłaci? Pewnie miliony.
Tylko czy klient przychodzi do nas, żebyśmy to my mogli spełnić naszą wewnętrzną potrzebę rozwoju?
Podsumowanie
Dlatego musimy sobie uświadomić, że kiedy dostarczamy rozwiązania dla klientów, muszą one robić dokładnie to, czego klient potrzebuje i muszą robić to niezawodnie. Kolejną rzeczą, która gdzieś się zagubiła jest to, że jesteśmy inżynierami, nasze rozwiązania muszą działać w prawdziwym świecie. Mam wrażenie, że przechodzimy w skrajności w skrajność: albo stajemy się artystami tworzącymi programistyczną Mona Lisę albo specjalistami tworzącymi po linii najmniejszego oporu. Uciekło nam, że CQRS, czysta architektura, podział na warstwy są narzędziami do osiągnięcia celu, a nie celem samym w sobie.
Autorem wpisu jest Łukasz Krawczyk, programista z kilkuletnim doświadczeniem, specjalizujący się w integracji i optymalizacji systemów informatycznych. A nade wszystko – czujny obserwator procesu dostarczania oprogramowania.
Mateusz Mazurek
Bardzo ciekawy wpis!
Warto zauważyć, że w niektórych zespołach nacisk na perfekcyjny kod jest bardzo mocny i jednocześnie męczy. Docenia się to jednak z czasem, gdy projekt ma kilka lat i pracuje kilkudziesięciu dev jednocześnie.
Wszystko ma dwie strony! :)
Pozdrawiam, Mateusz.
Dokładnie. Improwizacja kończy się w momencie przejścia produktu na produkcję. Dlatego warto poświęcić trochę czasu na przepisanie usługi. Później, na to nie będzie czasu, bo trzeba będzie ciągle coś gdzies reperować.
Niestety czasami odczuwam z góry, ze mam oddać produkt który ma działać ale nie do końca ma być w pełni dostosowany dla użytkownika. Ma działać i ma zrobić efekty. Czuje ograniczenie czasowe i budżetowe to wykonania produktu perfekcyjne :)) tutaj niestety trzeba pogodzić dwa aspekty… kasa i niewiedza klienta a rzeczywistość;/
Myślę że nie ma nic złego w tym ze trzeba godzić te rzeczy:) skąd pieniądze na nasze wypłaty muszą sie brac:)
Bardzo fajny wpis. Zgadzam sie z tym ze perfekcjonizm nie za bardzo pomaga w programowaniu. Wyobrazam sobie ze bardzo wiele projektow nie ujrzalo swiatla dziennego wlasnie z powodu wyczerpania zasobow przez perfekcjonizm .
Pozdrawiam 🤓👍.
W przypadku IED istnieje większe prawdopodobieństwo że zabije autora.
Generalnie trzeba być pragmatycznym.