Po to stosuje się krótkie sprinty i często spotyka sie z klientem. Pisanie niechlujnego kodu (powodzenia przy refaktorowaniu większego softu, takiego > 0.5mln linii kodu, bez testów jednostkowych, pochwal sie potem ile było regresji) nigdy nie kończy sie dobrze. Poza tym pisanie słabego kodu, bez testów i dokumentacji tylko pozornie kosztuje cię mniej czasu. No chyba że w projekcie studenckim który klepiesz dwa wieczory. W sofcie który klepie 100+ programistów od kilku lat to już nie działa...
A co powiesz na customizacje softu majacego kilkadziesiat tysiecy klas, i bedacego jednym z najwiekszych jesli nie najwiekszym w zakresie PLM? Nawet majac dostep do source nieraz widzialem ze test case'ow tam jak na lekarstwo a jakos jest to jeden z najlepszych produktow na rynku. Da sie? Da. Tylko trzeba pisac od poczatku porzadny kod z glowa. Wcale wiecej czasu to nie kosztuje potem. Test case owszem sa robione, ale zapewne nie takie jak macie na mysli typu (JUnit) tylko podstawowe z poziomu aplikacji, ktore klient sam dostarczy w celu sprawdzenia. Juz dawno sie nauczylem ze nawet klepiac kod na zaliczenie na uczelnie pisze go w sposob przemyslany i w miare generyczny od poczatku, bo zajmuje mi to zazwyczaj mniej czasu.
To jakaś nowość dla mnie. Zwykle bugfixing polega na naprawianiu błędów w kodzie, ale tych które wynikają z pominięcia albo złego zrozumienia wymagań prawie nie ma. Są za to inne ;]
No widzisz u nas ilosc typowych bugow jest mala, czesciej ten proces polega jednak na tym co napisalem. I nie mowie o zlym zrozumieniu wymagan przez nas, tylko zapisaniu ich w taki sposob przez klienta lub niedoprecyzowaniu, ze potem wymagane sa drobne poprawki. Ostatnio na codziennych meetingach zdarzylo sie im 4 razy zmienic zdanie odnosnie 1 funkcjonalnosci, a potem repo, revert, zmiana, revert. Tragedia.
Ale znam ludzi którzy celowo komitują słaby / nie dzialający poprawnie kod, byleby tylko "zdążyć na deadline", zakładając że "jak klient / testerzy" zgloszą błąd to sie potem poprawi. Takich ludzi należy nabijać na pal, bo zwykle to nie oni muszą te błędy poprawiać ;]
Jak sami sobie dol kopia i potem musza poprawiac to krzyzyk na droge. Oby tylko na kogos innego nie spadlo. Sprinty? Tak, przy dlugoterminowych projektach i wiekszej ilosci osob na projekcie. Przy malych raczej sie tych technik 'zwinnych' nie stosuje. Nadal podkreslam, ze nie mowie o sobie, tylko o tym jakie sa praktyki stosowane czesto. Ostatnio tez dostalem po kims projekt. Teoretycznie krotki 2-3 miesiace, ale jak zobaczylem shit kodu ktory na mnie spadl to wzialem wywalilem to i zaczalem wszystko od zera. Typowy kod studencki, ktorego sie nie dalo nawet rozszerzyc bez duzych zmian.
No ale takie krzaczki sie zdarzaja wszedzie. Nie jeden z nas dostajac kod po kims mial male WTF patrzac na te konstrukcje.
Jak się nie dzieje? Mi się już parę razy przytrafiła praca domowa w ramach procesu rekrutacyjnego.
Napisanie jakiejś aplikacji na zawołanie, w kilka godzin, bez czasu na przemyślenie, jest tylko bezsensowną męczarnią. Człowiek jest zestresowany, nie może się skupić, do tego pracuje na nie swoim sprzęcie/systemie, nie ma ulubionej konfiguracji, itd. To nie są normalne warunki pracy, więc jak można w ten sposób coś sprawdzić?
Ja bym chyba podziękował, gdybym dostał takie zadanie podczas rekrutacji.
Jest to swego rodzaju test wiedzy i doswiadczenia. Nikt nie daje jakichs bardzo skomplikowanych aplikacji. Co my tam mielismy 10-15 klas? Zaleznie od pomyslu. Dzieki temu mozna wybrac osoby, ktore sa pewne swoich umiejetnosci i potrafia kodzic, i przede wszystkim widac ze osoba zrobila sama. Skad maja pewnosc ze nie trafi sie cwaniaczek, ktory dostanie pomoc przy napisaniu czegos takiego, a potem mimo swojej niewiedzy zostanie zatrudniony zamiast kogos lepszego i bedzie sie jakos przeslizgiwal tam. Dla mnie jest to calkiem dobra metoda i mi sie bardzo podobalo.