mmazur.7thguard.net

Klepiąc się z pehapowym koszmarem (muszę co jakiś czas coś w tym pogrzebać, bo mnie wreszcie wywalą z roboty za obijanie się) nie mogę wyjść ze zdziwienia, że ten potworek jednak działa. Niespecjalnie skoordynowana grupa przeważnie niezbyt doświadczonych programistów jest w stanie stworzyć coś, co, choć wygląda bardziej przerażająco, niż uśmiechający się Roman Giertych, spełnia swoje zadanie. Patrząc na ten kod ma się ochotę zastrzelić tego, który powinien był zatrudnić jakiegoś doświadczonego projektanta, a tego nie zrobił. Nie wpłynęłoby to jakoś szczególnie na jakość pracy poszczególnych programistów, ale przynajmniej dałoby im w miarę szczegółowe wytyczne odnośnie tego co wolno, a czego nie wolno (no i zawsze byłoby się kogoś zapytać o to, w jaki sposób coś zaimplementować). Chodzi mi tu głównie o jawne zdefiniowanie zasad komunikacji pomiędzy poszczególnymi modułami. Bo o ile przy pomocy grepa mogę szybko sprawdzić jak moja zmiana wpłynie na funkcjonowanie reszty modułu (no a samą zmianę mogę później szybko przetestować), to już nigdy nie wiem, czy (teoretycznie) mała poprawka nie będzie sprzeczna z założeniami jakiejś odległej części systemu. Oczywiście mogę pisać kod asekurancko, ale wszystkich możliwości i tak nie jestem w stanie przewidzieć. Nie sposób tu nie docenić 'ciężko' obiektowych języków, gdzie istnieje wymóg zdefiniowania interfejsów do komunikacji, a kompilator programistów jednak pilnuje. Zakładam, że dzięki temu projektant jest w stanie zapewnić, że ogólna jakość projektu nie spadnie poniżej pewnego poziomu.

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.

Pomijając stwierdzenia o 'zwiększonej ilości testów' i 'mniejszej awaryjności', które wydają mi się mocno przesadzone, to trudno się jednak nie zgodzić z tym, że w open source sam kod jest produktem, co w konsekwencji przekłada się na jego jakość. Pytanie -- to gdzie tu jest miejsce na projektowanie? W przypadku zamkniętego projektu komercyjnego nie mogę odżałować, że nikt nigdy nie zrobił jakiegoś porządnego projektu. Jednocześnie w przypadku projektów open source strzelałbym do każdego, kto próbowałby ustalać cokolwiek na sztywno (acz tutaj jest kwestia wyznaczenia granicy -- jakiś projekt zawsze musi być, pytanie jak bardzo 'sztywny' i skodyfikowany). Czy KDE ma jakąś formalną dokumentację projektową? Albo GNOME? Może sam Linux? A może jednak jeśli sam kod traktuje się jako produkt, to jest on także sam w sobie designem? Gdzieś ostatnio czytałem, że każdy projekt dochodzi kiedyś do takiego momentu, gdzie istnieje już tylko i wyłącznie kod...

Hmm. Gdzieś mi się tu plątała jakaś pointa, ale pewnie spadła za biurko, a że ciemno już, to nie chce mi się szukać, wolę iść spać. Kurde, muszę gdzieś pójść na jakieś praktyki i zobaczyć jak formalne procesy zarządzania tworzeniem oprogramowania wyglądają, bo się zateoretyzuję na śmierć. Dobranoc.