tomii napisał(a)
Poprawianie w test ma tą zaletę że w trunk można tworzyć kolejne funkcjonalności (np 1 osoba poprawia błędy a pozostałe pracują już nad kolejną wersją) to wydaje się przydatne jeżeli testy z jakiś powodów się przeciągają.
Jeśli taka wersja test wypuszczana jest raz na dłuższy czas (min. co 2 mies.) i błędy nie są bardzo poważne, to przesunięcie poprawek w dół do trunk nie powinno być problemem. Jednak, jeśli taką wersję będziesz wypuszczał zbyt często (co kilka dni, tydzień) i będzie zawierała sporo błędów, bo wcześniej czy później ktoś takiego bajzlu narobi, że będziesz biegał 2-3 dni i odkręcał i rzucał mięchem po korytarzach. Nie teoretyzuje - to z obserwacji prawdziwych przypadków. Swoją drogą podobny scenariusz kilka dni temu miełem w robocie, jeden programista tak namieszał, że już drugi dzień odkręca jakieś krzywe akcje i nie wiem czy dziś się wyrobi :/
Jeszcze trochę obok tematu, ale będą to kwestie istotne z punktu widzenia procesu wytwarzania oprogramowania.
Automatyzacja build'ów. Jak na razie tylko w jednej firmie spotkałem się z profesjonalnym rozwiązaniem tego problemu. W innych robiło się to ręcznie. Nie ma problemu jak aplikacja builduje się w 1-5 min. ale jak builduje się przez 15 min. czy nawet godzinę, to już robienie tego ręcznie to jakaś padaka.
Przy użyciu ant'a (i innych tego typu, zależy jakiego jęzzyka używacie) można stworzyć sobie odpowiednie skrypty. Proponuję co dziennie z wersji trunk w nocy robić build i jeśli sie powiódł automatycznie podgrywać go jako wersję developerską, do testów wewnętrznych. Gałąź test też mogłaby podlegać automatycznym buildom, ale nie co dziennie, tylko np. jeśli zmieniło od ostatniego build coś zostało wcommitowane do tej gałęzi.
Testy automatyczne. Na etapie projektowania aplikacji warto pomyśleć nad automatycznymi testami jednostowymi, etc. Tak aby wersja test po poprawnym buildzie była od razu automatycznie walidowana, jeśli nie przejdzie testów, to jest wycofywana. Takie testy głównie powinny weryfikować jakąś logikę biznesową i inne istotne funkcjonalności używane w wielu miejscach aplikacji, czyli jakieś istotne biznesowo klasy narzędziowe.
Dokumentowanie kodu. Przy bardziej skomplikowanych metodach/klasach opisywać ich działanie, nawet z przykładami. Bo później jak ktoś ma tego użyć a nie rozumie jak, to często zaczyna pisać własny kawałek kodu, który robi to samo, czasem gorzej, z błędami. No i zasada DRY leży i kwiczy.
Sensownie dzielić projekt na biblioteki/moduły. Zawsze jest jakaś część aplikacji, która rzadko podlega zmianą (taka część core). I takie elementy powinny być odseparowane, aby zbyt wielu programistów ich nie tykało.
Jeśli tworzycie procedury skłądowane, to przyjąć jakiś schemat nazewnictwa, aby łatwo było sprawdzić czy procedura o potrzebnej funkcjonalności już jest (to samo tyczy się DAL). Bo znowu z autopsji przy większych projektach programistą nie chce się szukać czy ktoś już napisał jakąś prcedurę etc. tylko klepie jaka mu potrzebna i poźniej do pobrania podobnych danych jest kilka prcedur, chociaż możnaby stworzyć jedną czy dwie realizujące wszystkie przypadki.
W sumie powyższe wiąże się z kolejną rzeczą - komunikacja w zespole. Kiedy wszyscy członkowie zespołu wiedzą z grubsza kto czym się zajmuje, za jaki obszar odpowiada, to wiedzą kogo o co pytać. Miałem nieprzyjemność pracy w zespole, gdzie menago rozdzielał zadanka, ale w sumie nie wiedziałem co robią typy obok, więc później jak przychodziło do poprawy czyjegoś kodu, albo połączenia kilku funkcjonalności pojawiały się problemy. Ch... mnie strzelał i w końcu poszukałem innej roboty :) Codzienne 5 min. spotkania żeby każdy powiedział robie to i to i jest git mają sens, testowaliśmy to w jednej firmie i się sprawdzało. Później kierownik zaczął się lenić i coraz później przychodzić i się posypało i staneło na dłuższych spotkaniach raz w tyg., ale to też miało sens, bo każdemu dawało to całościowy obraz sytuacji w projekcie.