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

#1 | 2005.06.03 23:52 | Sławek

Przepraszam, że tak późno się wpisuję, ale dopiero niedawno tu trafiłem. :)

Bolączką sporej większości produktów jest nie brak dokumentacji kodu, ale brak dokumentacji projektowej. Czyli opisu jak to ma działać, jakie są parametry i spodziewane wyniki, jak ma wyglądać obsługa specyficznych błędów dla danego modułu i w jakis sposób należy przetestować poprawność działania.

Projekt modułu oprogramowania jest nie dość, że podstawą do zakodowania modułu przez programistę, to pozwala w prosty sposób na przejęcie pracy przez inną osobę (o ile projekt jest jasno opisany ;-)), a także stosunkowo szybkie stwierdzenie czy pojawiający się błąd jest błędem projektowym czy stricte programistycznym.

Ułatwia to niezmiernie życie i w połączeniu z systemem kontroli wersji projektów i kodu pozwala utrzymać porządek przy produkcji danego oprogramowania. Często się mówi "nie ma czasu na pisanie projektu, zacznijmy kodować". Takie podejście mści się szybko, szczególnie wtedy, gdy odchodzi z zespołu osoba, która miała wszystko "w głowie" i tak naprawdę ona jedna wiedziała jak to działa. Sensownie wykonany projekt, który opisuje działanie systemu/modułu zarówno od strony biznesowej jak i technicznej to prawdziwy skarb. :)

#2 | 2005.06.06 08:09 | MiMaS

Święte (w swej oczywistości) słowa. ;-)

Niestety lata praktyki inżynierii oprogramowania nauczyły nas, że dobry, kompletny, aktualny projekt to coś, na co nas zwyczajnie nie stać. Zresztą sam mówisz o nim „prawdziwy skarb” — skarby się ceni, ale przede wszystkim trudno zdobywa. W każdym rozbudowanym projekcie (a myślę, że taki jest każdy projekt stricte biznesowy, nie akademicki) prędzej czy później przychodzi taki moment, że istnieje kod i tylko kod.

Nie chcę przez to powiedzieć, że projekt techniczny nie jest ważny — jako wieloletni projektant chciałbym, żeby to, o czym piszesz, było oczywiste dla wszystkich. Ale równocześnie świadomie używam przy każdej okazji określenia „inżynieria”, aby zwrócić uwagę na ten element improwizacji, rozwiązywania problemów ad hoc i kierowania się zdrowym rozsądkiem niekoniecznie ściśle z projektem, jaki kryje się w tym słowie i w postawie inżyniera jako takiej...

#3 | 2005.06.06 20:25 | Sławek

Problem typu "nas na to nie stać" dotyczy przede wszystkim niedużych firm, które faktycznie nie mają wystarczających środków, żeby zatrudnić nie tylko programistów, ale i projektantów. Często też nie posiadają jednolitego środowiska do budowy aplikacji, sprawdzonych w praktyce i udokumentowanych rozwiązań. Skupiają się zatem na szybkim napisaniu kodu i sprzedaniu tego klientowi.

Ale w przypadku dużego i skomplikowanego systemu np. system obsługi kredytów w banku, system billingowy dla operatora telekomunikacyjnego itp. brak projektu oznacza szybką i dużą katastrofę.

Weźmy choćby pod uwagę dodanie nowego modułu czy współpracę z innym systemem. Skąd mamy się dowiedzieć, jak nasz system przechowuje pewne informacje i jak je przetwarza? Analizując kod? Przecież analiza różnorakich fragmentów kodu, powiązanych ze sobą w niekoniecznie widoczny od razu sposób może zająć tygodnie albo i więcej. Abstrahując już od faktu, że niekoniecznie chcemy przekazywać klientowi kod, a ten chce własnymi siłami wyciągać dane np. do systemu analitycznego.

Albo taki przykład: jest sobie w bazie tabelka z jakimś opcjonalnym kluczem obcym, który jest wypełniany w pewnych specyficznych, acz istotnych okolicznościach (dajmy na to przy rozliczaniu miesiąca). Czy z kodu dowiemy się, jakie znaczenie ma ten klucz?

Pracowałem już nad systemem, który posiadał jedynie ogólny projekt, natomiast szczegóły poszczególnych modułów powstawały od razu na kod. Udało się go wdrożyć, ale szczerze mówiąc teraz już nie skorzystałbym z takiej metody, bo wiem ile straciłem czasu na wprowadzanie funkcjonalności i poprawek nieuwzględnionych w projekcie. Poza tym wprowadzenie kogoś nowego w celu rozwijania takiego systemu jest nie dość, że trudne to angażujące pozostałe osoby z zespołu.

Teraz kiedy chcę się dowiedzieć, jak działa dany moduł wystarczy, że spojrzę w projekt i to mi wystarcza w 95% przypadków.

#4 | 2005.06.07 09:07 | MiMaS

Problem typu "nas na to nie stać" dotyczy przede wszystkim niedużych firm, które faktycznie nie mają wystarczających środków, żeby zatrudnić nie tylko programistów, ale i projektantów.

Nie koniecznie. Znam z autopsji takie przypadki w jednej z większych polskich firm softwareowych. Wszystko zależy od polityki i terminu wykonania systemu.

Ale w przypadku dużego i skomplikowanego systemu np. system obsługi kredytów w banku [...] itp. brak projektu oznacza szybką i dużą katastrofę.

Nie koniecznie. Znam system działający w dużym polskim banku, w którym projekt techniczny (czy właściwie kolejne projekty nowych funkcjonalności) istniał tak długo jak długo go utrzymywałem. Już nie uczestniczę w rozwoju tego systemu. Aktualny projekt techniczny nie istnieje. System ewoluuje i działa z powodzeniem od kilku lat.

Ale w ogóle to co chcesz mi/nam udowodnić, Sławek? To, że projekt systemu jest potrzebny? O tym każdy, kto się zajmuje tworzeniem oprogramowania, doskonale wie. Naprawdę. Zresztą nie przypominam sobie, żebym powiedział kiedyś, że tak nie jest. Natomiast chodzi mi o to, że nie możesz po prostu powiedzieć „przecież jest projekt, gdzie wszystko znajdę”, bo nader często tego projektu faktycznie nie ma. Jasne, że wnioskowanie o funkcjonalności i/lub architekturze systemu na podstawie jego kodu jest ... trudne. Ale czasem nie ma innego wyjścia. Dlatego postuluję powyżej uznanie kodu wraz z jego dokumentacją jako jednolity produkt programisty. I z takiego produktu programista powinien być rozliczany. Nie tylko z tego że „działa a w projekcie masz napisane jak i dlaczego”...

#5 | 2005.06.07 19:01 | Sławek

Chciałbym po prostu uświadomić tym, którzy to przeczytają (hej, jest tu ktoś jeszcze? ;)), że sama dokumentacja w kodzie programu nie wystarczy. Dobrze jest, jeśli programista o niej pamięta, ale to za mało, żeby powiedzieć, że produkt jest dobrze udokumentowany. Sam poza tym pisałeś, że problemy zaczynają się, gdy kod przejmuje ktoś inny. Często problem nie jest ze zrozumieniem poszczególnych fragmentów kodu, ale tego jak one ze sobą współdziałają. To jest właśnie rola projektu danego modułu czy obszaru aplikacji.

Zaczynając jakiś projekt warto się nastawić na tworzenie projektów, a nie radośnie przystąpić do kodowania, zmieniając 10-krotnie koncepcję i przerabiając kod niemalże od podstaw. Zmiany na etapie koncepcji nie są jeszcze tak kosztowne jak zmiany na etapie implementacji. Papier (lub inny dokument) jest cierpliwy i pozwala się wznieść na wyższy poziom abstrakcji niż kontrolki na formularzu. :)

Dobra, koniec wynurzeń - programiści do kodu, projektanci do projektów. :)

 

Uwaga: Ze względu na bardzo intensywną działalność spambotów komentowanie zostało wyłączone po 60 dniach od opublikowania wpisu. Jeżeli faktycznie chcesz jeszcze skomentować skorzystaj ze strony kontaktowej.