Jak walczyć z gigantycznym kodem w Java'ie, część 1.5 ;-) - czyli jak je się słonie ;-)

Poprzednio było o tym jak zacząć zabawę z kilkoma milionami linii kodu i jak zacząć je przygotowywać do analizy, o analizie jeszcze nie było, dziś będzie o organizacji.

Najpierw trzeba te parę milionów linii pociąć i dać im właścicieli.
Można zaproponować by zainteresowani sami powiedzieli czym się chcą zajmować (i rozwiązać ewentualne konflikty, tudzież przypisać komuś to czego nikt nie chciał), można też po prostu wylosować kto co weźmie.
Ale TRZEBA komuś dać własność kodu.
Czemu?
Bo jeśli kod ma właściciela, to ma kogoś kto ma bardziej długoterminową perspektywę dla tego kodu. Częściej w nim grzebie, widzi to co jest w tym kodzie najbardziej problematyczne i to co sprawia największe problemy w trakcie utrzymania.
Widzi też problemy w systemach na których ten kod działa.
Może wtedy zacząć zarządzać długiem technicznym. Może podejmować decyzje w dłuższej perspektywie czasowej.

Jeśli gdzieś w kodzie są "biblioteki" to trzeba się im przyjrzeć i stwierdzić czy są w ogóle bibliotekami.
Biblioteka to kod, który jest czyjąś własnością, do którego nowe ficzery wprowadzane są przez właściciela (nie musi być on autorem kodu, ten może przyjść od kogoś innego przez np. mechanizm pull request) i który to kod ma swój własny backlog zmian i własne priorytety (które są ustalane w odpowiedzi na requesty od klientów).
Biblioteką nie jest kod, którego używa N projektów w którym to kodzie grzebie kto chce z tych projektów gdy mu jest wygodnie.
Biblioteka nie istnieje po to "by nie robić copy & paste".

Co robić gdy masz "biblioteki", które istnieją "by nie robić copy & paste"?
Wydaje mi się, że trzeba wybrać jedną z czterech opcji.
Split - jeśli widać w "bibliotece" i projektach, które jej używają jakiś porządek, polegający na tym, że projekty będące własnością jednego zespołu/osoby używają tylko poszczególnych klas, a inne klasy są używane przez projekty używane przez kogoś innego, to najzdrowiej wydzielić z tej "biblioteki" kilka i oddać je zainteresowanym (obecnie próbuję stworzyć narzędzie do tego)
"Libarise" - ;-) ubibliotecz ;-) jeśli, kod jest używany przez wiele projektów ale jest niezbyt często zmieniany i ma ściśle określony zakres działań (to może wymagać najpierw zrobienia split) to może warto z niego uczynić prawdziwą bibliotekę, która będzie miała właściciela i zmiany do niej będą wprowadzane przez tego właściciela. Tutaj sugeruję dodanie całej masy UT, które pozwolą na załatwianie dodawania nowego kodu przez pull requesty. Wydaje mi się, że na początku UT powinny niemal betonować zastany kod.
Fork - jeśli wszyscy czegoś używają, ale nie da się tego ubibliotecznić to wydaje się, że zdrowsze będzie zrobienie forków kodu. Niech każda zainteresowana strona zmienia go sobie jak chce.
Można tu spróbować zrobić coś a'la Spotify'iowe chaptery (czyli każdy zespół który zrobił swojego forka będzie miał kogoś w chapterze i ten chapter będzie starał się by taki zforkowany kod szedł w kierunku biblioteki, albo by chociaż ciekawe zmiany, które będą przydatne dla innych się propagowały (z czasem będzie coraz trudniej)).
Forget - pewnie gdzieś jest kod, którego NIKT nie używa (tutaj przydatne będzie coś co podziała na wynikach z "lekcji 1" ;-)), wtedy najlepsze co z nim można zrobić to go SKASOWAĆ (usunąć pliki, zrobić commit).

Walka z wielkim codebasem to ćwiczenie w jedzeniu słoni.
Jeśli masz stado 100 słoni, i z każdego zjesz po 10% (bo będziesz zjadać tylko kawałki które wystają ze stada), to zjesz 10 słoni, ale nadal będzie ich 100.
Jeśli jednak podzielisz stado na 10 mniejszych stad to jest szansa, że w każdym z nich uda Ci się zjeść po 1 słoniu i będziesz mieć tych słoni 90 sztuk.
[analogia może być chybiona i bez sensu, ale mi się podoba ;-)]


Podobne posty^beta
Drugi klasyfikator jako "sanity check"
Notka miraż
Kaczyński zniósł demokrację
Twitter
Seks w ujęciu informatycznym ;-) - rozmnażanie ;-)