Wiedza plemienna w projekcie IT
Słyszałeś o projektach, w którym wzorzec MVC znajduje się w jednym pliku? Takie i wiele innych „kwiatków” zdarzają się w projektach każdego dnia. Wiem, że w twoich projektach takich rzeczy nie ma, ale na pewno widziałeś je kiedyś w projekcie „u znajomego” 😉 W tym wpisie wyjaśniam kwestię tzw „baboli” w kodzie oraz mówię jak sobie z nimi radzić by nie uśmierciły naszego projektu IT.
wiedza plemienna…czyli co?
Termin „wiedza plemienna” usłyszałem od Andrzeja Krzywdy z Arkency.com – od razu go zapamiętałem bo bardzo mi się spodobał. Ja rozumiem ten termin jako niestandardowe rozwiązania w kodzie, które ciężko przyporządkować do jakiegokolwiek wzorca/szablonu. Słyszałem też określenie „babole”. Bardziej jednak podoba mi się pierwszy termin, którego użyłem – w pradawnych czasach wiedza (na wszystkie tematy) była przekazywana werbalnie pomiędzy członkami plemienia. Nikt nie potrafił pisać lub dokumentować wiedzy – ojciec uczył syna itd. Mam wrażenie, że w niektórych projektach IT jest podobnie. Istnieją fragmenty w kodzie, których nie da się racjonalnie wytłumaczyć bez narracji członka zespołu. Są to różnego rodzaju hardcodowane ID, dziwne ify lub cały wzorzec MVC w jednym pliku. Każdy z tych elementów ma swoją genezę – coś nie działało i trzeba było zrobić hack, nie było czasu by zrobić to porządnie, więc zrobiliśmy tak i działa więc nie ma sensu tego naprawiać. Często też występują ustalenia między biznesem odnośnie logiki aplikacji, które są odzwierciedlone w kodzie z komentarzem „na prośbę XYZ” – żeby było wiadomo kogo pytać o wyjaśnienia dziwnego rozwiązania. Większość takich fragmentów dla nowego członka zespołu jest niezrozumiała – nie ma co się dziwić. Zupełnie jak w plemieniu – ktoś musi mu przekazać tajemną wiedzę odnośnie wszystkich hacków w projekcie, które zna tylko zespół. Można żartobliwie powiedzieć, że to są ich autorskie wzorce 😉
jak sobie z tym radzić?
Takie fragmenty mogłem znaleźć w większości projektów, przy których pracowałem. Rozmawiałem ze znajomymi na ten temat – u nich sytuacja wygląda podobnie. Myślę, że w każdym projekcie (w mniejszym lub większym stopniu) możemy znaleźć fragmenty wiedzy plemiennej, przekazywanej z zatrudnienia na zatrudnienie. Czy takie elementy w kodzie są czymś złym? Uważam, że nie tak bardzo jak uważa większość (szczególnie developerów technicznych). Wiadome jest, że jeśli mamy do wyboru mieć dług technologiczny lub nie – to lepiej go nie posiadać, ale nie demonizowałbym tego. Moim zdaniem da się to trzymać w ryzach na tyle by nie przeszkadzało w życiu projektu. Musimy pamiętać by tą wiedzę plemienną dokumentować – żeby nikomu nie umknęła. Jeżeli zaczniemy takie rzeczy spisywać, nadawać im klucze (ID) – czyniąc te rozwiązania jawnymi i ogólnie dostępnymi dla środowiska projektowego to myślę, że nie zaszkodzi to projektowi. Wiadomo, że wszystko zależy od skali – generalizuję bo każdy projekt jest unikalny. Ważną rzeczą jest żeby wiedza plemienna była dostępna dla członków zespołu – jedni to nazywają wiki projektowym, inni dokumentacją. Nomenklatura jest nieistotna – ważne jest by każdy wiedział w jakim miejscu może znaleźć wyjaśnienie dziwnych fragmentów. Przed rozpoczęciem pracy nad projektem powinna to być obowiązkowa lektura dla każdego developera. Oczywiście te przypadki powinny być dobrze opisane w dokumentacji – powinien być wskazany plik, geneza rozwiązania, jego skutki oraz wpływ na inne projektu. Nie zaszkodzi podpiąć zadania które odnoszą się do danego rozwiązania. Oczywiście takiej dokumentacji dotyczą te same zasady jak każdej innej – MUSI być aktualizowana wraz z życiem projektu. Brak aktualizacji dokumentów jest ich chyba największą bolączką – po kilku tygodniach stają się nieaktualne, a wtedy mogą wyrządzić więcej szkód niż przynieść pożytku. Pamiętajmy o tym, nieaktualny dokument lepiej usunąć niż się nim posługiwać.
Sprawdź jak mogę Ci pomóc osiągnąć Twoje cele 🎯
Podsumowanie
Wiedza plemienna występuje prawie we wszystkich projektach – uważam, że nie ma co się jej wstydzić, tylko ją dokumentować. Nie róbmy z tego tematy tabu, udając, że „w naszej firmie kod jest idealny, ale słyszałem u znajomego, że mają dług technologiczny” 😉 Pamiętajmy, że długiem technologicznym też można zarządzać, a wszystko co zarządzalne z wroga potrafi zamienić się w sprzymierzeńca.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
Jeśli jest to udokumentowane rozwiązanie to nie jest już to wiedza plemienna ani dług, tak na logikę 😉
Dlaczego? Przecież można dokumentować „nie eleganckie” rozwiązania, a to, że je ktoś opisze nie czyni je dobrymi 😉
tyle że to czy to jest dobre czy złe czy eleganckie rozwiązanie nie ma nic wspólnego z wiedzą plemienną,
wiedza plemienna to wiedza która jest tylko w głowie plemienia,
jeśli wiedza plemiana zostaje przelana na papier i udokumentowana to przestaje być wiedzą plemienną.
jeśli rowiązanie jest złe, to dług pozostaje, aczkolwiek ta część która dotyczy braku dokumentacji zostaje spłacona
W mojej definicji wiedza plemienna jest nieeleganckim lub nieoczywistym rozwiązaniem, którego gdy ktoś nie zna może wywołać jakiś fuckup. Nawet gdy się to spisze w mojej definicji również jest to wiedza plemienna.
Co jeśli cały projekt jest przykładem wiedzy plemiennej? Co jeśli plemię przez dekady nie słyszało o wzorcach i nowi współplemieńcy muszą adaptować się do takiej sytuacji lub walczyć o przywrócenie normalności? Co jeśli model biznesowy firmy zakłada sprzedawanie produktów z tej samej dziedziny dla różnych firm (bez przekazywania praw do kodu na wyłączność) i produkty te tworzone są przez kopiowanie i modyfikowanie plemiennego kodu, który nigdy nie był pudełkiem? Być może odpowiedzi na te pytania, jeśli je znasz, mógłbyś zamienić w nowy artykuł 🙂
Dzięki, będę miał na uwadze 🙂