TheTarPit

I co z tego, że działa...

Każdy, kto usiłuje traktować tworzenie oprogramowania z szacunkiem należnym, jeśli nie sztuce to przynajmniej rzemiosłu, musi przyznać, że „działa” to za mało. Program może działać i wykonywać wszelkie zachcianki użytkownika/zlecającego/klienta i równocześnie być zupełnie marnym produktem software'owym. I nie ma w tym żadnej sprzeczności, ponieważ prawdą jest co pisze Ian Sommerville:

Software is not just the programs but also all associated documentation and configuration data which is needed to make these programs operate correctly.

Ian Sommerville

Software Engineering

Osobiście jestem za pełnym rozwinięciem tej definicji na wszystkie postacie w jakich może występować oprogramowanie. Tak więc postać ostateczna, wykonywalna funkcjonuje jako produkt wyłącznie razem z dokumentacją użytkownika i analogicznie postać przejściowa, czyli kod źródłowy funkcjonuje jako produkt wyłącznie razem z dokumentacją kodu.

produkt ukryty

Tymczasem dokumentacja kodu, najlepiej umieszczona w nim samym lub tuż obok, oraz związana z nią jakość źródeł, jest od zawsze piętą achillesową inżynierii oprogramowania. Nieczytelny, niezrozumiały i nie udokumentowany kod — wszyscy to przecież znamy aż za dobrze. I co gorsza sami sobie przygotowujemy to bagno...

A jakby tak spojrzeć na każdy kawałek kodu stanowiący zdefiniowaną całość jako na produkt software'owy z pełnym obciążeniem tej definicji...? To by oznaczało, że brak minimum komentarzy w kodzie, brak uzupełnienia dokumentacji technicznej projektu, czy choćby brak opisów nowych elementów konfiguracji jednoznacznie określa dany produkt jako niekompletny. A zatem zadanie postawione przed programistą nie zostało wykonane do końca i jako takie nie może zostać oddane.

W praktyce jednak wygląda to tak, że po osiągnięciu stanu „o, zadziałało?!” dany fragment programu jest przekazywany do kompilacji i/lub do testów. Kompilacja programu, jeżeli taki etap jest w ogóle wydzielony w danym projekcie, koncentruje się głównie na tym, czy uda się stworzyć nowy build i kod jako taki przestaje już być istotny, byle by był kompilowalny. Testerzy oceniają jakość oprogramowania po wynikach działania wersji skompilowanej, więc tym bardziej nie interesują się wyglądem i kompletnością źródeł. W ten sposób kod zostaje „zalegalizowany”, „wyprany” i fakt, że produkt stworzony przez programistę jest niekompletny umyka wszystkim. Do czasu gdy trzeba w danym fragmencie systemu wykonać jakieś poprawki i zadanie to dostaje inny programista...

bubel ujawniony

Koszmaru pracy nad kodem stworzonym przez kogoś o zupełnie innym sposobie rozumowania nie muszę chyba tłumaczyć nikomu, kto uczestniczył w projekcie z choćby częściową zmianą obsady. Teoretycznie przejęcie po kimś kodu wymaga chwili na zorientowanie się „jak to jest napisane”. Ewentualnie kilku chwil. Jednak w przypadku enigmatycznego, nieudokumentowanego kodu, w sytuacji gdy wspomniany wyżej produkt został przekazany (i przyjęty!) w postaci szcztkowej, jego zrozumienie może zająć cały czas przeznaczony na wykonanie zadania. Albo i jeszcze trochę więcej. Generalnie możliwe są tutaj dwie równie niewesołe sytuacje:

• kod jest napisany tak, że budzi wątpliwości co do poczytalności, umiejętności i prawego pochodzenia jest twórcy,
• kod stanowi obraz tak skomplikowany, rozbudowany i pełen najróżniejszych pułapek, że jawi się jako dzieło obcej cywilizacji wyprzedzającej ludzkość o tysiące lat ewolucji.

Wulgaryzując — programista staje przed wyborem: albo poprzedni autor jest głupi albo on sam jest jeszcze głupszy. Można oczywiście podejść do sprawy z humorem lub z zacięciem badacza nieznanych cywilizacji, jednak w praktycznych sytuacjach rzadko kiedy jest czas na takie zabawy. Dlatego każdy kod, który budzi wątpliwości i każe się domyślać swojego przeznaczenia, zasady działania czy celu w ogóle, powinien być potraktowany jako produkt zły. I to niezależnie od tego czy stawia poprzedniego programistę w lepszym czy w gorszym świetle — programistyczny geniusz bez instrukcji obsługi jest tak samo nieprzydatny jak programistyczny idiota.

produkt jawny

Szczególną (i nie zawsze oczywistą) cechą oprogramowania open source jest znacznie większa jakość kodu niż w przypadku systemów zamkniętych. Można spokojnie założyć, że nie jest to żaden cud, a jedynie prosta konsekwencja założenia przedstawionego powyżej — w open source kod jest produktem w sposób jawny i oczywisty. Myślę, że również ten fakt (oprócz zwiększonej ilości testów) przyczynia się do dużo mniejszej awaryjności oprogramowania z gatunku FLOSS.

W systemach z zamkniętym kodem brakuje tej atmosfery jawności zarówno w działaniach samego programisty jak i w spojrzeniu kierownictwa wszelkiego szczebla. A przecież wystarczy stworzyć świadomość, że osoby decydujące np. o premii programistów oglądają i oceniają wytworzone przez nich produkty (w sensie definicji powyżej). W sytuacji komercyjnej produkcji oprogramowania pełniliby identyczną rolę jaką pełni szeroko pojęta społeczność użytkowników dla oprogramowania open source — rolę kogoś, przed kim dobrze jest się wykazać kodem eleganckim i udokumentowanym, a nie tylko działającym. Kogoś, przed kim po prostu nie opłaca się wstydzić za własne wypociny...

Wątpisz, że ludzie zarządzający komercyjną produkcją oprogramowania są w stanie obejrzeć, zrozumieć i ocenić kompletność produktu programisty? W takim razie powiem Ci, że .... masz całkowitą rację.

Komentarze