io-2009-4d team mailing list archive

[Adrian Panasiuk <adek336@xxxxxxxxx>]

Musimy ustalic kilka kamieni milowych, opisac co nasz program ma miec
zaimplementowane w najblizszym czasie.

W pisaniu podzielimy sie modulami, ktore musza ze soba wspolgrac.
Takze od poczatku musimy miec interfejsy wszystkich klas. Bedziemy
robic te interfejsy tak jak w classes.dia uzgodnilismy, dlatego jak
zamierzamy cos tam zmieniac, to musimy to zrobic w najblizszym czasie.
Zmiany w interfejsach z ktorych juz kod juz korzysta oznacza
marnotrawstwo czasu na przepisywanie kodu na nowy interfejs.

Prosze spojrzcie na classes.dia pod katem tego czy wypisane funkcje
wystarcza do naszych potrzeb, czy jest spojnie. Juz musimy zmieniac
nazwy opisowe (np. "wyslij komende nie czekajac na odpowiedz") na te,
ktore pojawia sie w kodzie (powiedzmy, "wyslij_bez_czekania").

Chociaz nie wszystko bedziemy implementowac, to interfejsy mozemy
przygotowac w calosci bo to nie bedzie duzo roboty.



A potem potrzebujemy miec juz pliki .py odpowiadajace klasom w ktorych
znajduja sie juz ich publiczne interfejsy.

Przygotujemy jeszcze jakies minimalne czarno-skrzynkowe unit testy na
te publiczne interfejsy i bedziemy mogli wtedy zaczac implementacje.

Oczywiscie commitujemy zmiany czesto, changeset generalnie nie
powinien przekraczac kilkudziesieciu linii. Nie ma sensu napisac przez
3 dni 300 linii i wrzucic to jako jeden wielki kloc. Kiedy zmiany sa
male, duzo latwiej znalezc zrodla regresji. Commitlogi powinny byc
klarownie napisane i nie tylko byc wytlumaczeniem czemu zmiana jest
sensowna, ale tez opisywac jaki obiekt zostal zmieniony i co bylo
zmieniane - jesli mimo przeczytania commitloga, zeby wiedziec czemu
sluzy dany changeset musze ogladac ktore pliki byly zmienione i jaki
byl diff, to pisanie commitlogow mija sie z celem.