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.