Prawdy objawione

Po długiej przerwie, spowodowanej przyczynami obiektywnymi ;) postanowiłem napisać coś z zupełnie innej beczki - historię z życia wziętą.

Niedawno przedstawiono mi wyniki audytu kodu pewnego systemu, którym mam przyjemność(?) się zajmować, przygotowanego przy pomocy Automatycznego Narzędzia Weryfikującego Jakość Kodu.

Oprócz skądinąd słusznych uwag dotyczących formy czy złożoności kodu (metryki McCabe'a czy Halstead'a), ku mojemu zdziwieniu, znalazły się tam rzeczy, które zaliczyć można raczej do "dobrych praktyk programowania", czyli zasad, których bezwzględne i bezkrytyczne stosowanie przyczyni się do osiągnięcia wysokiej jakości, skalowalności i wydajności aplikacji (tak, to była lekka ironia).

Wśród tych dobrych praktyk znalazły się pewne wytyczne, które nazywam "prawdami objawionymi". Dziwnym trafem, z reguły są to stwierdzenia zaczynające się od słów "zawsze należy...", "nigdy nie stosuj...", "najlepiej będzie, gdy...", "najgorsze rozwiązanie to..." - jestem wyczulony na takie zwroty i coś mi zaczyna, za przeproszeniem, śmierdzieć, gdy takowe czytam lub słyszę. Nie wiem dlaczego (żeby było jasne, mówię to w swoim imieniu i na podstawie subiektywnych doświadczeń) spora część z nich to zwykłe bzdury.

Oczywiście, takie "uniwersalne reguły" nie wzięły się znikąd, w każdej z nich być może znajdzie się ziarno prawdy, ale pod warunkiem, że taka teza zostanie postawiona w jakimś kontekście, przy założeniu pewnych warunków brzegowych ("w wersji X zwróć uwagę na użycie konstrukcji Y, ponieważ w niektórych sytuacjach (patrz przykład Z) może się okazać zbyt kosztowna" itp. itd.) - ale "zawsze i wszędzie"?
Przykład, który najbardziej przypadł mi do gustu - "nigdy nie stosuj złączeń kartezjańskich, bo zawsze wiążą się one z niską wydajnością systemu". Przyznam, że w momencie, w którym to przeczytałem lekko opadły mi członki - ale to być może jest temat na osobnego posta (o wydajności, nie o członkach).


Nie twierdzę bynajmniej, że nie znajdą się reguły, które być może będą miały zastosowanie "zawsze i wszędzie" - tyle, że jak na złość IT ma to do siebie, że się zmienia - pojawiają się nowe wersje, nowe funkcjonalności z nowymi błędami, stare są poprawiane, usuwane, przerabiane - i może się okazać, że taka złota zasada, która sprawdzała się jako tako w wersji 8.5.1.9 z 1987 roku nadaje się już dawno na śmietnik.
Jeśli jednak ktoś bezkrytycznie wymaga stosowania się do takich zasad i uzależnia od wyniku audytu odbiór produktu - to może być pewien problem... W opisywanym tu przypadku na szczęście tak nie będzie(?), ale wyobrażam sobie i takie sytuacje.

To co napisałem, oczywiście nie odnosi się tylko do jakichś sformalizowanych reguł implementacji, obowiązujących w danej firmie czy ogólnie stosowanych "najlepszych praktyk" w danej technologii czy języku programowania, ale również do tzw. "wiedzy powszechnej", funkcjonującej w świadomości wielu z nas w postaci Jedynie Słusznych i Uniwersalnych Sposobów na wykonanie danego zadania (nie będę ściemniał, że sam się na tym wiele razy nie przejechałem - no cóż, uczymy się na własnych i cudzych błędach).

Jeden z moich ulubionych przykładów (uwaga: stary i oklepany, przynajmniej dla mnie) - wstawianie LOBów do tabeli w Oracle. Większość "wyguglanych" przeze mnie przykładów na forach, blogach itp. zawierało z gruntu złe informacje na temat tego, w jaki sposób można to zrobić poprawnie. Co więcej, w 90% przypadków, które widziałem w "prawdziwych" aplikacjach, robiono to dokładnie w sposób tamże podany.
Tymczasem w oficjalnej dokumentacji (zainteresowanych odsyłam do niej)) łatwo znaleźć takie informacje. Co więcej, łatwo sprawdzić, czy sposób podany w dokumentacji będzie w naszym przypadku, przy spełnieniu naszych założeń, przy użyciu dostępnej nam wersji, rzeczywiście optymalny - pisząc prosty test porównawczy.
Ale przecież łatwiej przekopiować kawałek kodu z sieci - skoro ktoś go tam umieścił, to musi być dobry, bo przecież "działa", prawda?
Mam wrażenie, że część specjalistów (you know who you are) od jakości czy klepania kodu opiera się właśnie na takich nierzetelnych informacjach, pochodzących z mało wiarygodnych źródeł. Rzetelnych specjalistów na wszelki wypadek przepraszam - ale przecież nie uogólniam :)

Zatem, mam następujące propozycje (nie zasady! ;)):
Szanowny konsultancie ds. zapewnienia jakości:

1. Bądź specjalistą w dziedzinie, której weryfikacją się zajmujesz. Jeśli takowym nie jesteś, to skonsultuj się z przyjaznym manualem lub kimś, kto zna się na tym lepiej od Ciebie - to chyba nie jest powód do wstydu.
2. Pamiętaj o tym, że tezy, które stawiasz, są w większości przypadków łatwo weryfikowalne. Staraj się więc je sprawdzić (na początek - w oficjalnej dokumentacji) i udowodnić, zanim zasypiesz kogoś miliardem uwag, nie mających pokrycia w rzeczywistości. Głupio będzie przecież, jeśli podniosłeś alarm na pół firmy, a ktoś udowodni Ci, że nie masz racji?
3. Jeśli developer twierdzi, że się mylisz - masz prawo zweryfikować przedstawiony przez niego punkt widzenia. Może jednak Twoje uwagi nie były zasadne? A może będzie na odwrót i przedstawisz niepodważalny dowód na poparcie swoich tez, dzięki czemu będziesz mógł chodzić w glorii chwały? :) Na pewno obaj dojdziecie w końcu do konstruktywnych wniosków i do porozumienia (pod warunkiem, że z obu stron padają rzeczowe, poparte dowodami argumenty, a nie "prawdy objawione").
4. "Najlepsze praktyki" to nie jest dekalog, dany raz na zawsze ciemnemu ludowi przez zespół oświeconych ekspertów. Taki zbiór wiedzy nie powinien być niepodważalny i niezmienny, powinien żyć, być stale poddawany weryfikacji, ocenie, modyfikacjom (niewykluczone, że również dzięki uwagom drugiej strony). Jeśli tak nie będzie, to po pewnym czasie stanie się skamieliną. Co więcej, zastanów się, czy taki zbiór reguł powinien dotyczyć technologii jako takiej (np. Dobre Praktyki dla PL/SQL), czy może raczej konkretnego jej zastosowania, konkretnego systemu? Może aplikacja jest na tyle specyficzna, że wymaga zupełnie odmiennego podejścia od tego, które Ty zawsze stosowałeś?
5. Automatyczne narzędzia, wspomagające proces oceny kodu to... tyko narzędzia i jako takie mogą zawierać błędy i generować fałszywe alarmy. One mają jedynie pomóc w przeprowadzeniu tego procesu - nic nie zastąpi myślącego człowieka.

Szanowny developerze:

1. QA nie jest Twoim wrogiem, choć Ty często dajesz im ku temu powody :) Ich zadaniem jest zapewnienie oczekiwanego przez klienta poziomu jakości. Ale to nie znaczy, że są oni wyrocznią, której powinieneś bezkrytycznie słuchać tyko po to, żeby oczekiwane przez management Wskaźniki Jakości były większe lub równe założonej wartości progowej (z całym szacunkiem do management'u).
2. Staraj się sprawdzać we własnym zakresie tezy, stawiane przez QA czy informacje znalezione na forach, blogach (także niniejszym! sic!). Jeżeli mają rację to chwała im za to, natomiast jeśli tak nie jest - powiedz o tym "bez kozery" - przecież wszystkim zależy na dostarczaniu dobrego softu. Ale przedstaw argumenty na poparcie swoich racji.
3. Współpracuj przy opracowywaniu i modyfikacji zbioru dobrych praktyk - jeśli jesteś ekspertem w danej dziedzinie, to Twoje uwagi mogą być nieocenione i przyczynić się do zwiększenia poziomu "wiedzy powszechnej".
4. Wykaż trochę własnej inicjatywy podczas implementacji ważnych funkcjonalności. Może się okazać, że Jedyne Słuszne Rozwiązanie, wynikające z bezkrytycznego zastosowania Złotej Reguły nr 1 ze Zbioru Dobrych Praktyk jest całkowicie bezsensowne w tym konkretnym przypadku, którym się zajmujesz. Prosty, szybki test, poparty powtarzalnymi wynikami, pomoże wybrać optymalne w danej sytuacji rozwiązanie.
5. Uwaga na źródła, z których czerpiesz wiedzę. To, że ktoś wkleił na forum X jakiś snippet nie znaczy, że masz przekopiować go bezmyślnie do swojego kodu tylko dlatego, że "u niego działa".

Tak, wiem, łatwo się to wszystko pisze :)

PS. Wszelkie podobieństwo do prawdziwych osób i wydarzeń jest całkowicie przypadkowe.