Jak poznać kiedy jakiś projekt i jego rozwój jest źle zarządzany, źle utrzymywany? Kiedy twórcy nie podchodzą dość poważnie do samego procesu rozwoju danego oprogramowania? Przy takiej ocenie posiłkować się można analizą zmian pomiędzy kolejnymi wydaniami oprogramowania.

Nie ukrywam, że mam tu na myśli jeden konkretny soft - mechanizm forum dyskusyjnego MyBB. Przy każdym wyjściu nowej wersji tego oprogramowania dokonuję szczegółowej analizy zmian, które wprowadzono - przede wszystkim na potrzeby utrzymywania moich własnych poprawek i modyfikacji. Prosta komenda jak:

diff -ubBr mybb-128 mybb-129 > patch_1.2.8-to-1.2.9.diff

daje wszystko co potrzeba wiedzieć z punktu widzenia samego kodu (aczkolwiek bez bezpośrednich zmian w strukturze bazy danych, które to trzeba uzyskać patrząc na zmiany w kodzie instalatora/aktualizatora).

Producent nie udostępnia bezpośrednich patchy pomiędzy wersjami, a jeśli wypuszcza jakąś łatę, to nie jako DIFF, ale jako plik ręcznych modyfikacji (mod). Jest to pierwszy sygnał, że producent może nie zarządzać kodem prawidłowo.

Co jakiś czas jednak taką łatę udostępnia - jak w przypadku MyBB 1.2.8 -> 1.2.9. I co się okazuje? Że jego łata jest uboższa niż bezpośredni DIFF pomiędzy danymi wersjami (tu 1.2.8 i 1.2.9). To znaczy, że:

(MyBB 1.2.8) + (łata 1.2.8->1.2.9) != (MyBB 1.2.9)

To jest drugi - bardziej poważny już - sygnał, że projekt jest źle zarządzany pod kątem rozwoju.

O samej stabilności i jakości procesu rozwoju produktu świadczy też polityka związana z wydawaniem kolejnych stabilnych wersji oprogramowania. Przykładowo położenie nacisku na automatyzację pewnych procesów w celu uniknięcia błędów mających przyczynę w czynniku ludzkim. Tudzież kontrola zmian w kodzie kolejnej nowej wersji tak, by być pewnym, że nie wcisnął się do niej żaden kod np. z gałęzi testowej. Jeżeli aktualizacja bug-fix wprowadza małą lecz nieprawidłową zmianę (bug), którą deweloper kwituje “I don’t see why that was changed“, to znaczy, że w tej polityce czegoś brakuje.

Ostatnim elementem jest polityka wersjonowania, kompatybilności i ilości zmian w poszczególnych release’ach. Trochę o tym pisałem w notce “Mały update i… ZONK!“, choć z innego punktu widzenia. Inkrementacja składowej patch-level lub revision, to zazwyczaj małe zmiany w kodzie i funkcjonowaniu aplikacji, np. poszczególne bug-fixy. Jeśli 1.2.7->1.2.8 oznacza zmianę w 44 plikach plus dodanie 9 nowych, a 1.2.8->1.2.9 to modyfikacja tylko 3 plików, to znaczy, że do aktualizacji zupełnie różnej skali stosuje się tę samą miarę.