Cykl rozwoju kodu programu wykazuje znaczące zbieżności z cyklem życia gwiazd.
Na początku jest chmura pomysłów i różnych fragmentów kodu porozrzucanych w najróżniejszych skryptach.
W
pewnym momencie, gdy ciśnienie zewnętrznej potrzeby jest wystarczająco
duże, programista decyduje się utworzyć projekt - jednoplikowy rdzeń
programu, do którego zachodzi akrecja pomysłów na nowe funkcjonalności i
dawniej stworzone fragmenty kodu. Gdy funkcjonalność kodu osiąga
odpowiednią gęstość, zaczyna się go używać. To pierwsza wersja programu i
początek jego życia.
Jeśli ciśnienie
potrzeby i gęstość idei wokół tematu nie jest zbyt wielka, kod zaczyna
stabilne życie. Zachodzi w nim kontrakcja objętości kodu - kod mniej
efektywny/napisany na szybko zostaje zamieniany na bardziej
efektywny/przemyślany, który jest zazwyczaj krótszy. Po pewnym czasie
już nic nie jest dodawane. Program działa siłą rozpędu, zależną od
zgromadzonej funkcjonalności.
Są jednak
sytuacje w których chmura idei jest bardzo gęsta, i towarzyszy jej
wielkie ciśnienie potrzeby. Po uformowaniu projektu i pierwszego pliku, a
później pierwszej wersji użytkowej, akrecja kodu nie zatrzymuje się.
Towarzyszy mu powstawanie kolejnych plików z funkcjami programu. Czas
mija, a projekt rozrasta się. Zachodzi w nim wiele zmian i koncentracji
kodu z gorszego do lepszego, ale kod ciągle wymaga dołączania nowych
funkcji. Plik główny jest bardzo masywny i silne wiatry odprogramowe
powodują uwalnianie kodu do mniejszych plików, tworząc barwną otoczkę
wokół programu głównego.
W pewnym
momencie jednak ciśnienie kodu jest już tak duże, że przerasta granicę
cierpliwości programisty i dochodzi do kolapsu kodu.
W
trakcie tego dramatycznego i gwałtownego wydarzenia plik głównych
wybucha, tworząc w projekcie zrestrukturyzowane biblioteki klas i
funkcji, których kod jest zwarty i najczęściej dobrze napisany. W
centrum programu pozostaje jedynie mały rdzeń - importujący wszystkie
biblioteki, posiadający (jeśli jest to program z GUI) jedynie rdzenną,
zwartą klasę. Efektem tego dramatycznego eventu może być powstanie wielu
mniejszych projektów, które będą korzystać z tak powstałego, kodu
bibliotek o większej efektywności.
Jednakże
może zajść jeszcze inna sytuacja, w której akrecja kodu jest na tyle
silna, że program przekracza finalną granicę, za którą nie ma już
powrotu.
Dochodzi do utworzenia
osobliwości - kodu tak rozległego i niepodzielonego, że nawet twórca
projektu nie wie co dzieje się za granicą horyzontu działań programu.
Nie mam czasu na prowadzenie tego bloga, to może od czasu do czasu coś takiego tu wrzucę :)
Brak komentarzy:
Prześlij komentarz