Temat: Jakość kodu
Pracowałem kiedyś (prehistoria) w dość dużej firmie, posiadającej własny dział IT zatrudniający m.in. dość spore stado programistów, utrzymujących i rozwijających autorski software (napisany w CA Clipper), który obsługiwał całą firmę (telemarketing, sprzedaż, poprzez księgowość, reporting, marketing, oddział celny, zakupy, aż po transport - wszystko). Kodu było sporo - pewnie z kilka milionów linii, oczywiście dokumentacji nie było, bo nikt nie miał czasu jej tworzyć. Kluczowa byłą więc czytelność kodu i stosowanie przez wszystkich tych samych stylów kodowania, zasad nazewnictwa (małe/duże litery, opisowość), wcięć, interpunkcji itd itp, ale i unikanie pewnych konstrukcji (bo "nie stosujemy" i już). Nie wnikam tutaj w to, ile tych zasad było sensownych, ile nie, ale fakt em niezaprzeczalnym było to, że kod dość dobrze opisywał się dzięki temu sam: siadało się do kodu, robionego rok wcześniej przez koleżankę, i pracowało się z nim jak ze swoim. Ocena jakości kodu i związane z tym działania była proste: stwierdzenie któregokolwiek programisty "kurwa, nic z tego nie rozumiem, co on tu porobił???" oznaczało, że kod trafia do przeglądu przez jednego ze starszych programistów, i - jeśli on ocenił, że kod jest kiepski - wracał do refactoringu do autora (każdy się podpisywał pod swoimi zmianami w komentarzach w kodzie, więc było wiadomo, kto ma poprawiać). Uzgadniany był termin (zwykle na jutro) i nie było zmiłuj się, że już 16:00 i koniec pracy, albo że jest jakaś inna robota pilniejsza: siadasz i robisz, najwyżej będziesz siedział w nocy.
Powiem Wam, że było to bardzo skuteczne - nikomu nie chciało się pisać niezgodnie z zasadami, bo po prostu prędzej czy później dodawało to kupę pracy po godzinach, ale za free.
A jaki był koszt wdrożenia się nowych ludzi w takie standardy? Wbrew pozorom niewielki. Młody dostawał szybkie szkolenie w stylu: tu są biblioteki, tu masz kod modułów, tak robimy dostęp do tabel, funkcje mają zawsze zwracać wartość bool określającą, czy się powiodły, czy nie, a teraz siadaj do kodu i oglądaj, masz dwa dni, możesz zadawać pytania ;) Po dwóch dniach młody dostawał coś do zrobienia, na początek coś prostego, jakąś prostą modyfikację na przykład, i miał przydzielanego starszego programistę jako mentora i "weryfikatora". Przez pierwsze 2...3 dni zadawał zwykle setki pytań, po tygodniu ilość pytań drastycznie spadała, po dwóch tygodniach młody zwykle stwierdzał, że nie rozumie, jak on mógł kiedyś pisać kod w inny sposób ;) Zwykle dalsze angażowanie tego starszego programisty (mentora/weryfikatora) przestawało już być potrzebne.
I tyle.
Czy ten kod był dobrej jakości? Obiektywnie mówiąc: nie wiem, być może inne firmy stosowały własne zasady i konwencje, może i pod jakimś względem lepsze. Natomiast subiektywnie, z punktu widzenia programistów, którzy nad takim kodem później pracowali, mogę uczciwie stwierdzić: tak, to był bardzo dobry kod, bo wszyscy mogli z nim pracować równie sprawnie i szybko, jak z własnym.
Wtedy też zauważyłem, że największe znaczenie ma to, żeby wszyscy stosowali konsekwentnie te same zasady - a jakie to są zasady, ma już mniejsze znaczenie. Dowolne, konsekwentnie stosowane zasady stają się zrozumiałe po kilku dniach, a wchodzą "w krew" po tygodniu...dwóch. I tutaj jest odpowiedź na pytanie: "a co, jeśli dalszy maintenance ma robić zupełnie inna firma?" Nic. Jeśli kod jest pisany w/g dowolnych zasad, ale konsekwentnie stosowanych, każdy doświadczony programmer szybciutko to ogarnie i - co więcej - w imię tej przytaczanej przeze mnie wcześniej "estetyki technicznej" wykona poprawki czy zmiany w tej samej konwencji, żeby nie psuć przejrzystości.
Tak więc wszelkie bicie piany np. o wyższości konwencji camel nad konwencją pascal, to bullshit - to nie ma żadnego znaczenia, znaczenie ma tylko to, żeby coś ustalić i cholernie konsekwentnie stosować.
пропозиції роботи
