Statyczne typowanie to nie tylko sprawdzanie sporej klasy błędów automatycznie przez kompilator ale także lepsza statyczna analiza i niezawodne transformacje kodu. Siedząc nad zadaniami w projekcie w korpo zdecydowaną większość czasu spędzam na analizie i przerabianiu kodu, a nie na klepaniu nowego, więc bardziej liczą się takie rzeczy jak solidna nawigacja, refaktoring i wykrywanie błędów niż szybkość naklepania nowego kawałka kodu.
Kiedyś już podawałem wyliczenia dotyczące szybkość klepania kodu, ale przedstawię jeszcze raz. Sprawdźmy jak szybko trzeba klepać nowy kod, by naklepać milion linii kodu w ciągu 10 lat w 10-osobowym zespole (tzn 10 programistów) - jest to wariant bardzo optymistyczny (tzn moim zdaniem zakłada wysoką wydajność klepania kodu). Milion linii kodu podzielone przez 100 roboczolat (10 lat * 10 osób) daje 10 tysięcy linii kodu rocznie. Zakładając 200 dni roboczych daje to 50 linii kodu dziennie. Ile czasu może zająć samo dorzucanie 50 nowych linii kodu? Nawet zakładając, że jak prototypuję nowy kod to przepisuję go 3x to wychodzi 150 linii kodu na dzień. Te 150 linii mogę naklepać spokojnie w godzinę. Jak widać, w ogólnej perspektywie w wieloletnim projekcie szybkość klepania nowego kodu ma niewielkie znaczenie. Większe znaczenie ma szybkość wdrożenia się w projekt, przerobienia go zgodnie z nowymi założeniami i zapewnienia stabilności.
Szybkość klepania kodu liczy się jeśli na rynku otwiera się nowa nisza i chcemy być w niej pierwsi, zdążyć przed konkurencją. Wtedy mamy wyścig z czasem i np czytelność kodu ma drugorzędne znaczenie. Kod staje się syfny i prawdopodobnie trzeba go będzie w niedalekiej perspektywie czasowej zaorać. Z drugiej strony typowe korpo-projekty mają następujące cechy:
- trwają wiele lat (np > 10 lat, a w takim czasie ekosystem Node.js zdąży się przepoczwarzyć kilka razy)
- zespół programistów dynamicznie się zmienia, tzn ludzie ze stażem w projekcie odchodzą, a na ich miejsce przychodzą ludzie, którzy będą się w projekt dopiero wdrażać
- cały czas trzeba naprawiać błędy i dodawać nowe funkcjonalności
- założenia projektu się zmieniają i np okazuje się, że wolumen danych jest 10x albo 100x większy niż pierwotnie zakładano albo że trzeba wprowadzić konfigurowalność tam gdzie wcześniej opierano się na uproszczeniach
- przepisanie projektu od zera jest równoznaczne z klęską obecnego podejścia, więc modernizację systemu trzeba przeprowadzać stopniowo równolegle z poprawkami błędów i dodawaniem nowych funkcjonalności
Kiedyś ktoś tu podawał historie o sukcesie Node.js chyba w Netfliksie, który miał stawiać wiele mikroserwisów opartych o Node.js. Szczegółów chyba jednak wielu nie było. Niedawno natomiast w mojej firmie menedżer podniecał się innym zespołem, który podobno zarządzał kilkunastoma mikroserwisami i wdrażał nowe wersje co chwilę. Menedżerowi to zaimponowało, bo my co prawda też mamy kilkanaście mikroserwisów, ale wdrażanie nowych wersji jest nieco bolesne (nie wdrażamy sobie ich ot tak, tylko przygotowujemy zestaw paczek w sumie kilka dni). Na spotkaniu z gościem z tego zespołu okazało się, że ich kilkanaście mikroserwisów to nie jest jeden rozproszony system, a kilkanaście małych niezależnych aplikacji popierdółek (a skoro są niezależne to oczywiście nie będzie problemu z podbijaniem wersji pojedynczo i bez synchronizacji między aplikacjami). Wszelakie cudowne historyjki (hype) trzeba więc weryfikować i zadać sobie przede wszystkim pytanie jakie ktoś problemy rozwiązywał, a nie jak modne jest jego narzędzie.