Jak radzisz sobie z brzydkim kodem, który napisałeś? [Zamknięte]

Twój klient prosi o napisanie kodu, więc ty to zrobisz. Następnie zmienia zgodnie z oczekiwaniami specyfikacje, a ty pilnie wdrażasz jego nowe funkcje, jak dobry mały chłopiec. Z wyjątkiem ... nowe funkcje są w pewnym sensie sprzeczne ze starymi funkcjami, więc teraz twój kod jest bałaganem. Ty naprawdę chcesz wrócić i naprawić, ale trzyma zainteresowanie nowych rzeczy i za każdym razem coś zakończeniu czyszczenia, to nakręca bałagan ponownie.

Co robisz? Przestań być maniakiem OCD i po prostu zaakceptuj, że Twój kod skończy bałagan, bez względu na to, co robisz, i po prostu staraj się cechować tę potworność? Zapisać czyszczenie dla wersji 2?

Znajdź inną pracę i pozwól innym sobie z tym poradzić. Muahahahhahahaa.

.....

Tylko żartuję. :)

Ale z całą powagą: wypełnienie szacunków jest twoim przyjacielem. Generalnie robię przyzwoite realistyczne szacunki, a następnie je podwajam. Może to zabrzmieć przesadnie i czasami tak jest, ale lepiej jest nieco przecenić, a czasem nawet wyglądać odrobinę powolnie - niż pozostawić złe wrażenia, wyrzucając błędny kod i zawsze wysuwając swoje prognozy. I oczywiście zaciągasz dług techniczny, pozwalając, aby baza kodów stała się zhackowana.

Kolejna (pokrewna) wskazówka: zawsze oceniaj pozornie małe, bez sprytnych zadań do przyzwoitej wielkości bloku. Powiedzmy na przykład - element, którego jesteś prawie pewien, będzie prostą zmianą w 30-sekundowym wierszu - daj mu 1 godzinę (a może cokolwiek w najniższym bloku czasu znajduje się w twoim grafiku lub systemie CR, np. 15 minut / 0,25 godziny) . I daj półdniowe lub 1-dniowe bloki na nieco większe, ale wciąż stosunkowo trywialne przedmioty.

Przyczyna tego jest głównie psychologiczna: uważam, że jeśli przyzwyczaisz się do szybkiego robienia drobnych zmian, praca wydaje się przyspieszona i nigdy nie kończysz siedzieć, podsumowywać i przerabiać rzeczy, które należy zreformować. Ponadto, na poziomie praktycznym: czasami pojawiają się drobne, ale nie trywialne zmiany, i nie chcesz ciągle czuć, że spóźniasz się z gaszeniem pożarów. To nieodłączna część tego, dlaczego bazy kodu stają się z czasem hakujące.

Wreszcie, zawsze pamiętaj, że ludzie nie muszą wiedzieć, że nieco podszywasz swoje szacunki. Dopóki jesteś kompetentnym programistą i pracujesz w przyzwoitym tempie, ta wyściółka nie będzie zauważalna. tzn. nie mów PHB „Moje wstępne szacunki mówią, że zajmie to dwie godziny, ale daj mi pół dnia”. Po prostu powiedz mu: „Myślę, że zajmie to około pół dnia”. i zostaw to tam.

Celowo przeceniaj czas potrzebny na kolejne funkcje. Wykorzystaj ten dodatkowy czas na posprzątanie.

Nigdy nie będziesz w stanie uzasadnić konserwacji, a klient jej potrzebuje, niezależnie od tego, więc podaj mu gorzki lek (nieznacznie zwiększone koszty następnych funkcji), aby mógł się poprawić.

Spróbuj dokonać właściwego przeprojektowania, jednocześnie integrując nowe funkcje. Nie ma później. Bez przeprojektowania stale dodajesz coraz więcej tarcia w celu wprowadzenia dalszych zmian i nowych funkcji.

W pewnym momencie dobiegniesz końca, w którym wszystko wydaje się trwać wieki. Większość firm prawdopodobnie zdecydowała się na dużą przeróbkę w tym momencie, wersja 2. Ma dość kiepską ekonomię i jest dobrym momentem dla twojego klienta, aby spróbować innej grupy programistów, jeśli czuje się skłonny.

Prawidłowe przeprojektowanie / refaktoryzacja może chronić inwestycje klientów i zachować równowagę. Musisz to wbudować. Zoptymalizuj pod kątem zmian, podróżuj lekko.

Biorąc pod uwagę wszystkie komentarze na temat przeszacowania, myślę, że brakuje pewnej ilości punktu (dobra okazja).

Nie chodzi o oszacowanie zajętego czasu, aby dokonać zmiany (tylko), a następnie dodanie, chodzi o oszacowanie czasu potrzebnego na zmodyfikowanie kodu (refaktoryzacja!), Aby doprowadzić go do punktu, w którym zmiana może być bezpiecznie wykonana, a następnie dokonać zmiana (prawdopodobnie nieco zmiksowana razem). Ok, to sprowadza się do tej samej rzeczy ... ale nie ma mowy o kręceniu się, rozciąganiu czy przeszacowywaniu, wystarczy powiedzieć, że aby to zrobić, najpierw muszę to zrobić i tyle czasu to zajmie w sumie. Kluczem tutaj jest to, że pracujesz w tych częściach systemu, od których zależy zmiana, i nic więcej - jeśli gdzieś jest okropny kod ... trudny, złap go, gdy tam jesteś.

Wracając nieco do pierwotnego pytania - po wielu latach sprowadza się to do mnie, kiedy wdrażasz coś, chyba że wiesz (nie wierzysz, nie oczekujesz (podejrzewasz?), Nie myślisz, ale wiesz ), że dodatkowe rzeczy to wymagane także wtedy, powinieneś zrobić wszystko, co konieczne, aby spełnić ten wymóg i nie więcej w tak uporządkowany i elegancki sposób, jak to możliwe.

Kiedy zaczynasz wdrażać następną rzecz - jakiś czas później - podejmujesz kroki niezbędne do wprowadzenia bazy kodu (i bazy danych itp.) Do stanu potrzebnego do wdrożenia tej funkcji tak schludnie i elegancko, jak to tylko możliwe. Refaktoryzacja polega na tym, że radzisz sobie z bałaganem, który powstaje naturalnie w miarę rozwoju projektu - i miejmy nadzieję, że unikniesz tworzenia więcej bałaganu (lub przynajmniej utrzymasz spójność poziomu).

Jednym z obszarów dyskusji jest tutaj „Zadłużenie techniczne” - to jak debet, musisz go spłacić, a im dłużej go pozostawiasz, tym większe są odsetki (w tym przypadku czas potrzebny na poprawienie) - co daje ci dobre argument za poświęceniem czasu na zminimalizowanie długu technicznego.

Tutaj też zaczynają pojawiać się testy jednostkowe i inne testy automatyczne (gdybym mógł zrobić tak dobrze, jak mówię, jestem pewien, że byłbym szczęśliwszy!) W połączeniu z odpowiednim serwerem kompilacji (który może uruchomić przynajmniej niektóre twoich testów). W połączeniu z tymi - ale o wartości same w sobie - są wzorce takie jak wstrzykiwanie zależności i odwracanie kontroli (nigdy nie jestem pewien, ile to te „te same” są), ponieważ ułatwiają zmianę instalacji hydraulicznej, a zatem radzą sobie ze zmianami w izolacja.

Wreszcie - pamiętaj, jeśli nie jest zepsute, nie naprawiaj tego. Sprzątanie kodu wyłącznie w celu uporządkowania może być satysfakcjonujące, ale jest również okazją do wprowadzenia błędów, więc może być bolesne, jeśli nie musisz go zmieniać i nie budujesz na nim, może lepiej pozostawić kilka grudek sam - możliwość naprawy lub wymiany w końcu się pojawi!

1) Właściwa kontrola zmian to twój przyjaciel

Jeśli klient zmieni specyfikację, co jest w porządku, to ma rację, jednak jest to zmiana i należy ją obciążyć (lub wycenić w dowolny sposób odpowiedni dla struktury / relacji projektu).

Szacunek dla tej zmiany powinien obejmować koszt niezbędnego refaktoryzacji. Klient może zaryzykować, co wydaje się być kosztowne, ale w tym momencie musisz mu wyjaśnić, że ponieważ kod jest już w połowie napisany, istnieją elementy, które należy przepisać, aby zapewnić jego niezawodność i obsługę w przyszłości, i że jeśli nie zostanie to zrobione, prawdopodobnie będzie miał problemy z przyszłym wsparciem lub zmiany będą jeszcze droższe.

2) Refaktoryzacja powinna być wykonana w taki sposób, który zapewnia klientowi prawdziwą długoterminową korzyść

Rozważając refaktoryzację, zawsze musisz wziąć pod uwagę to, co jest rzeczywiście potrzebne i co jest ważne, i upewnić się, że praca refaktoryzacji zapewnia prawdziwie długoterminowy stosunek jakości do ceny.

W końcu powinniśmy robić te rzeczy, aby kod mógł być rozszerzany i obsługiwany w perspektywie średnio- / długoterminowej, aby zapewnić, że inwestycja klienta pozostanie ważna, a nie z powodu dążenia do doskonałości teoretycznej. Praca nad refaktoryzacją (i odpowiednimi szacunkami) powinna być wykonana z tym zakresem, a nie tylko dlatego, że teraz uważasz, że może być nieco lepszy sposób na wykonanie tego.

Niektórzy programiści sugerują, że sposobem kontrolowania tego problemu z klientami jest podpisanie przez klienta i autoryzacja początkowej specyfikacji. NASTĘPNIE, gdy zażądają zmiany wymagań, która nie jest w początkowej specyfikacji, mówisz im, że musisz przejść przez umowę i harmonogram projektu w celu obliczenia dodatkowych kosztów i opóźnień, a następnie zrobić aneks do umowy. Najwyraźniej robi cuda, uniemożliwiając klientom naleganie na nowe (nieprzewidziane) funkcje.

Mam następujący komentarz w bazie kodu, nad którym obecnie pracuję:

/*
 * Every time I see this function, I want to take a shower.
 */

Wiem bardzo dobrze sytuację, którą opisujesz. Staram się (jak najlepiej) poczekać, aż wszystko się uspokoi i jakikolwiek „pełzacz” nie „wkradnie się” do wszystkiego. Do tego czasu prawdopodobnie wydałeś coś użytecznego i możesz poświęcić trochę czasu na oczyszczenie i zaimplementowanie rzeczy nieco inaczej.

Nie możesz biegać w kółko, czyszcząc wiele małych bałaganów. To potroi twoją pracę i frustrację. Poczekaj, aż stanie się jednym większym, ale ledwo poruszającym się bałaganem, a następnie możesz coś z tym zrobić.

Przede wszystkim wolę unikać tej sytuacji.

Wszystko zależy od tego, w jaki sposób czytasz specyfikację. Łatwo myśleć o nich jak o kamiennych tablicach, ale w rzeczywistości większość specyfikacji się zmienia. Projektując kod, zobacz, jak prawdopodobne jest, że każda część specyfikacji ulegnie zmianie. Z czasem będziesz dość dobry w przewidywaniu tego.

Wejście w bałagan, doświadczenie i osąd są bardzo ważne. Czy piszesz nowe błędy z powodu tego kodu spaghetti? czy wdrożenie trwa dłużej? wskazywałoby to na założenie taktycznego refaktora.

na przyszłość wygląda na to, że musisz współpracować z klientem. Mówiąc im: „spójrz, ten produkt znacznie rozszerza się poza oryginalną specyfikację. Podczas gdy oryginalny projekt był dobry dla tego poziomu, rozszerzanie go w kierunku X i kierunkach Y wymaga pewnej restrukturyzacji w projekcie” dobrze sobie poradzono, a nawet dostaniesz swój klient za to zapłaci.

Opłata za godzinę i jeśli chce zmian, powiedz, że jest w porządku, ale uwzględnij czas potrzebny na napisanie dobrego kodu do równania. Pamiętaj też, że pisanie starszego kodu jest opłacalne, gdy trzeba go utrzymać. Oszczędność czasu może cię później kosztować.

Myślę, że pisanie oprogramowania musi iść w parze z potrzebami biznesowymi. Jeśli jest to projekt jednorazowy (jak prototyp, który trzeba zbudować w ciągu tygodnia, z nowymi danymi wejściowymi przychodzącymi każdego dnia), nie ma potrzeby martwić się o konserwację kodu i inne rzeczy - czas jest niezbędny i wystarczy wypchnij kod tak szybko, jak to możliwe.

Ale jeśli piszesz aplikację długoterminową, warto rozważyć to wszystko, ponieważ ma znaczny wpływ na to, ile czasu zajmuje tworzenie nowych funkcji, usuwanie istniejących błędów, integracja z innymi aplikacjami i innymi rzeczami - i przekłada się to na wpływ na działalność (ze względu na więcej czasu potrzebnego później i wyższe koszty).

Dlatego lepiej uwrażliwić osobę podejmującą decyzje na rzeczywiste koszty braku refaktoryzacji kodu, gdy jest to konieczne - z mojego doświadczenia wynika, że ​​jeśli wpływ obu opcji na koszty i czas zostaną wyjaśnione właścicielowi decyzji w wymierny sposób, decyzja może być bez zastanowienia. Nie oczekuj, że ludzie powiedzą „tak, napisz piękny kod, chociaż zajmuje to dwa razy więcej czasu i nie daje mi żadnych dodatkowych korzyści”. To po prostu nie działa w ten sposób.

Włącz to do swojego procesu, nazywam to „ekstremalnym refaktoryzacją”, a będzie duże! ;) Po prostu rób rzeczy szybko, a gdy dodano wystarczającą liczbę nowych funkcji, że jest tam blizna, przerób ją. Ciągle zadawaj sobie pytanie: „Gdybym zaczął od zera, jak bym to zrobił”

Ludzie, którzy myślą, że potrafią zaprojektować i myśleć o wszystkim z góry, w większości oszukują samych siebie, Ty (i Twój klient) zawsze uczysz się różnych rzeczy. Skorzystaj z tych lekcji.

Ponieważ jesteś dobrym programistą, będziesz w stanie dość szybko refaktoryzować, a gdy to zrobisz, kod zacznie przyjmować swoją „właściwą formę”, co oznacza, że ​​stanie się bardziej elastyczny przy mniejszej zależności.

Klienci mogą być zdenerwowani, jeśli wiedzą, że „marnujesz czas” na przerabianie rzeczy, więc to pomaga nie pytać / mówić i być naprawdę szybkim.

Tak opracowany kod pozwoli Ci zaoszczędzić mnóstwo czasu i sprawi, że będzie coraz łatwiej dodawać nowe funkcje.

Powiedziałbym również, że jednym z największych powodów złego kodu jest obawa, że ​​niektórzy programiści obawiają się większego refaktoryzacji strukturalnej, a im dłużej czekasz, tym gorzej.

Polegaj na sile wyższej

Nie mam na myśli modlitwy. Mam na myśli, upewnij się, że jest jakiś facet od biznesu (tj. Kierownik projektu lub równoważny), który możesz umieścić jako podkładkę między tobą a klientem. Jeśli klient wymaga zbyt wiele, pozwól biznesmenowi postawić stopę i być gotowym do użycia „jest w stanie, ale nie jestem pewien, czy to pasuje do zakresu specyfikacji, zobacz [biznesmen]”.

W normalnym toku projektu ogólna specyfikacja powinna zostać zamrożona, zanim nastąpi poważny rozwój.

Wielu klientów będzie nadal dążyć do zmian / ulepszeń / ulepszeń, dopóki im na to pozwolisz. Wielu będzie nadużywać tej zdolności do maksimum, ponieważ sprawia, że ​​czują, że zarabiają najwięcej za swoje pieniądze (nawet jeśli sabotuje twój projekt).

Poproś osobę zajmującą się doskonaleniem i zamrażaniem specyfikacji na wczesnym etapie i egzekwowaniem jej później.

Nie ma nic złego w robieniu trochę więcej za odrobinę dobrej karmy z klientem, ale bądź gotów przełożyć się na wyższą moc, gdy wymkną się spod kontroli. Jeśli specyfikacja wymaga absurdalnej ilości zmian, być może nadszedł czas, aby wrócić do pętli biznesowej i ponownie ocenić umowę i / lub dodać dodatki do umowy (z uczciwą rekompensatą pieniężną).

Fakt, że masz ten problem, nie ma wiele wspólnego ze sposobem kodowania. Jest to znak, że kierownik projektu nie jest w pełni wykorzystany w projekcie (czy to z winy, z winy, czy w obu przypadkach).

Jak inni powiedzieli w wielu odpowiedziach, dodanie bufora czasu na nieprzewidziane wydatki jest również konieczne w każdym projekcie, ale określenie, które należy podjąć za zamkniętymi drzwiami, zanim specyfikacja zostanie zamrożona i dostarczona klientowi przez PM.

Wstępny prawidłowy projekt nie może pomóc uniknąć problemu. I prawie niemożliwe (lub bardzo trudne) jest rozważenie wszystkich przyszłych wymagań „być może”. Tak więc po pewnym czasie pojawi się Big Re-faktoring. A najlepszym rozwiązaniem jest przepisanie wszystkiego od nowa.

W kilku słowach: zamiast montować wieżę na czerwonym Ferrari, ponownie rozważ wymagania i zbuduj czołg.

Zabij to ogniem.

Refaktoryzacja Aka tak szybko, jak to możliwe: na przykład, gdy brzydki kod pochodzi z pośpiesznego terminu, dokonam refaktoryzacji po terminie, ponieważ nie możesz (lub nie powinieneś) dodawać więcej funkcji, dopóki istniejący kod nie będzie możliwy do utrzymania, w przeciwnym razie znacznie utrudni to debugowanie przyszłych kodów.

Napisz testy jednostkowe dla swoich projektów, które testują bieżący stan, a następnie refaktoryzuj, gdy masz czas, w ten sposób unikniesz zepsucia projektu podczas próby jego wyczyszczenia.

Najprostsza odpowiedź. Przestałbym kodować, dopóki nie będzie miał ostatecznej specyfikacji dokładnie tego, czego chce teraz.

Następnie muszą ustalić priorytety tej listy funkcji itp., Aby potwierdzić, jakie elementy muszą mieć teraz, a które można zrobić później ...

Korzystając ze swoich doświadczeń, określ czas i koszt każdej funkcji, a następnie powiedz im, że jeśli tego chcą, zajmie to x czasu i pieniędzy.

Radzisz sobie z wielką przestępczością związaną z zakresem funkcji, a oni będą ciągle dodawać funkcje, dopóki nic nie zostanie zrobione lub zrobione tak źle.

Po uzyskaniu ostatecznej listy powiedz im, że wprowadzisz przyszłe modyfikacje, jak wolą, ale musisz skupić się na najlepszych 15/20, które muszą mieć teraz.

Następnie, na podstawie czasu do ukończenia, powiedz im, że po wydaniu tego, będziesz otwarty na dyskusję / burzę mózgów na temat kolejnej wersji.

Po podjęciu ostatecznej decyzji, co należy zrobić dla bieżącej wersji, wszystkie dyskusje / pomysły / sugestie należy zatrzymać w 100%.

Jeśli dostaje pomysły w nieskończoność, powiedz mu, aby je zapisał na liście funkcji dla następnej wersji i pozwól, abyś skupił się na dostarczaniu najważniejszych funkcji, których chcą teraz.

Jeśli nadal będą marnować twój czas, zmieniaj zdanie. Potem po prostu przestałbym pracować nad projektem i pracował nad innymi projektami, dopóki nie sfinalizują swoich decyzji.

Trudno to zrobić, ale pełzanie funkcji jest tak destrukcyjne dla czasu, energii, motywacji i jasnego myślenia.

Z kompletnej perspektywy projektu:

Naucz się z kodu ze swoim zespołem, zobacz, co można ponownie wykorzystać i wykorzystać ponownie następnym razem, a potem idź napić się piwa.

Z perspektywy rozwoju:

Cierpliwie wyjaśnij, dlaczego rozwój został zatrzymany, i wyjaśnij, dlaczego nie można kontynuować, dopóki wszystkie specyfikacje nie zostaną przedstawione i zrozumiane. Potem idź napić się piwa.

Z perspektywy planowania:

Poproś z wyprzedzeniem wszystkie specyfikacje i pracuj ze wszystkimi, aby dobrze zrozumieć ścieżkę rozwoju. Zaangażuj klienta / interesariuszy tak blisko, jak to możliwe, aby upewnić się, że wszyscy są na tej samej stronie. Później tej nocy zdobądźcie wszystkie piwa. Jutro rozpocznij projekt.