Dlaczego nie lubię wchodzić w duże projekty

Ogarnianie większego projektu jest trudne. Wchodzisz w projekt robiony przez kogoś innego, dość słabo napisany. Ciężko zrozumieć, o co chodzi.

Dokumentacja jest szczątkowa. Zwykle jest jakiś przegląd architektury z lotu ptaka, ale już konkretów obsługi jakiegoś wewnętrznego API ciężko się doszukać. Owszem, w modułach widać jakieś JSDoc, ale zwykle są to informacje kompletnie bez znaczenia, ot nazwy i znaczenie parametrów w danej funkcji. Coś, co i tak już dostarcza TypeScript, jeśli jest w projekcie, więc nie ma potrzeby pisać tego w adnotacjach.

Ale gdyby mimo braku dokumentacji, był to projekt dobrze napisany? No nie bardzo, 2 pierwsze literki z SOLID idą się zwykle jebać pierwsze. Moduły odpowiadają często za ileś różnych rzeczy, a żeby coś zmienić, trzeba bezpośrednio modyfikować już napisane, długie pliki.

Okej, czasem nie jest tak źle, chociaż dobrze też nie jest. Jeśli widzisz gdzieś drobiny sensu, np. poszanowanie zasad projektowych, to okazuje się, że zostaje to okupione sporą dozą przeinżynierowania i wciskania wzorców dla samego wciskania wzorców. W przeinżynierowanym projekcie moduły nie mogą po prostu istnieć i wystawiać jakieś API. No nie, one muszą być częścią całego skomplikowanego mechanizmu, gdzie masz najbardziej wydziwione implementacje wzorców, jakie można sobie wyobrazić.

Czasem nawet te wzorce absolutnie nic nie robią! Bo komuś się wydaje, że jak zrobi singletona zamiast zmiennej globalnej, to będzie lepiej (spoiler: singleton to po prostu zmienna globalna inaczej zapisana). No ale singleton jeszcze nie jest najgorszy, bo to prosty pattern, gorsze są te bardziej skomplikowane, gdzie ktoś musiał się namęczyć, jak robił.

Chociaż... może kwestia tego, że ktoś się za mało namęczył? Dobry design wymaga przemyślenia jednak, porobienia prototypów, a tam to czasem wygląda odwrotnie - jakby ktoś prosto po studiach z wiedzą napakowaną teorią zabrał się za kodzenie. Czasem nawet ludzie z wieloletnim doświadczeniem się tak zachowują! No ale to jest doświadczenie w stylu "rok powtórzony X razy". Czyli niby kodzą od dłuższego czasu, ale praktycznie robią tak samo, jakby dopiero coś poczytali o wzorcach. Co za bezsens.

No i syndrom sztokholmski dotyczący danego projektu. Ludzie nie dostrzegają już tego, że żyją w syfie. Na zadane pytanie odpowiedzą ci w stylu "Przecież to łatwe. Musisz tylko zrobić X, żeby Y", gdzie ta ich odpowiedź niby "robi robotę" (można faktycznie osiągnąć Y, jak się zrobi X), problem tylko, że jest to odpowiedź tak absurdalna, że ciężko nad nią przejść do codziennośći.

Przypomina to trochę te wszystkie patenty, które się stosuje w duchu prowizorki. Trochę jak wtedy, kiedy popsuje się kabel w słuchawkach i żeby wydobywał się dźwięk, trzeba ułożyć kabel w bardzo specyficzny sposób i czymś docisnąć.

Jednak słuchawki można kupić nowe. Co jednak z projektem, który działa tak, jakby już w połowie nie działał?

• Można... robić więcej spotkań. Czyli recepta na wszystko wg PMów. Na tych spotkaniach miałby się odbywać transfer wiedzy z osób lepiej znających projekt do osób dopiero w niego wchodzących. Na tych spotkaniach mogłaby zostać podjęta dyskusja na temat tego, jak ulepszyć projekt. No dobra, tylko to ładnie wygląda na papierze, ale za pomocą kilku spotkań nie zamieciesz pod dywan tony złych praktyk, które się nagromadziły przez rok czy dwa albo przez jeszcze dłuższy czas.

• Można stosować zasadę skauta - stopniowo poprawiać projekt, zostawiając moduły w lepszym stanie, niż je zastaliśmy. Powodzenia. Zmiana paru modułów nic nie da, i tak przyjdą i zaśmiecą z powrotem, twoje zmiany na lepsze zostaną zaorane. Przydałaby się gruntowna zmiana architektury całego projektu i narzucenie pewnych sensownych standardów.

  Ale całego projektu nie da się przepisać ot tak, nie opłaca się to po prostu biznesowo. Więc może część projektu? Albo samą infrastrukturę? Albo sposób implementacji kluczowych modułów? Gdyby zrobić duże zmiany, ale jednocześnie jakoś ulokowane w konkretnych miejscach?

  Gdyby. No właśnie, można gdybać ale jak przyjdzie co do czego, to się okazuje, że nic nie można zmienić, bo projekt działa, a jak coś zmienisz, to przestanie działać. A testów albo nie ma albo są napisane w taki sposób, że i tak nic się nie da zmienić. Jeszcze jest opór organizacyjny - jak będziesz za bardzo polepszać, to nie starczy ci czasu na bieżące zadania i twój PM nie będzie zadowolony. Dlatego nikt już się nie stara niczego polepszać, skoro zawsze jest coś do zrobienia na "bieżąco".

• Można się ewakuować, czyli zagłosować nogami. "Ostatni gasi światła". Choć nie jestem przekonany, czy to powiedzenie jest prawdziwe. Wydaje mi się, że raczej "jak nie ty, to ktoś inny". Ludzie, którzy są w projekcie długo, już nauczyli się żyć w tym pierdolniku i nie będą rezygnować. A jak będzie trzeba dodatkowej mocy przerobowej , to się wystawi ofertę pracy i trochę podkoloryzuje, żeby zachęcić. Np. zamiast "kupa legacy kodu" napisze się "ciekawe wyzwania" i przyjdą kolejni naiwni... Chociaż czy naiwni? Wiele ludzi podjęłoby się kąpieli w szambie, jeśli dostaliby za to odpowiednio wysoką stawkę...

Ogółem więc nie lubię wchodzić w duże projekty. W małe też. Ogólnie w kod legacy, z którym nic nie mogę zrobić, jak tylko w nim grzebać i marudzić. Ja to lubię mieć kurczę wpływ na design, architekturę i standardy kodu w projekcie. Żeby było po mojemu, czyli dobrze. Nie lubię tej przykrej konieczności akceptacji słabej jakości kodu, jednocześnie widząc, jak nikt wokół nie kuma, że to słaby kod, wszyscy kładą lachę na zmiany. Przyzwyczaili się.