Czy ktoś jeszcze ma problem z refaktoryzacją? [Zamknięte]

Wygląda na to, że po napisaniu znacznej ilości kodu odczuwam niepokój, że nie zrobiłem tego w najlepszy możliwy sposób, i ostatecznie ciągle refaktoryzuję i spędzam zbyt dużo czasu na projekcie lub nigdy nie dostaję czasami tak się dzieje. Czy zdarza się to komukolwiek innemu i jak sobie z tym poradzić?

Lubię te chwile, kiedy mi się przytrafiają.

Powód: gdybym nie spojrzał wstecz na swoją pracę i pomyślał, że jest coś, co mógłbym zrobić lepiej, niż nie rozwijałbym się jako programista. Dlatego, kiedy zdarzają się te momenty oświecenia, obejmij je i zanotuj to, czego się nauczyłeś. Zastanów się nad swoim harmonogramem bieżącego projektu i, jeśli to możliwe, popraw kod, jeśli nie jest to możliwe, weź lekcję i wykorzystaj go w przyszłych implementacjach projektów.

Tak czy inaczej, uczenie się na własnych błędach to świetna rzecz!

Oto kilka zasad ograniczających tę aktywność i zwiększających jej produktywność:

• ustaw czas, np. ustaw timer na 25 minut
• rób to tylko wtedy, gdy masz przyzwoity zasięg testu.
• postaraj się, aby refaktoryzacja była przydatna przy opracowywaniu kolejnych kilku funkcji

Wygląda na to, że zawsze można refaktoryzować, prawda? Staram się ograniczać refaktoryzację tylko podczas próby rozwiązania innych problemów. Na przykład refaktoryzuj, gdy masz problem z wydajnością, i refaktoryzuj z pomocą w jego rozwiązaniu - refaktoryzuj, gdy potrzebujesz dodać nową funkcjonalność i refaktoryzacja pomoże ci go rozwiązać

Szczerze mówiąc, martwiłbym się bardziej, gdybyś wykuwał ogromne sterty kodu i myślał, że wszystko jest idealne i nie wymaga żadnego refaktoryzacji ...

Kiedy byłem młodszy i niedoświadczony, byłem bardzo arogancki, jeśli chodzi o moje zdolności programistyczne i zawsze wyobrażałem sobie, że można naprawdę dobrze zaprojektować i zaplanować - i że kiedy przejdę do etapu wdrożenia, po prostu go rozwalę i to ”. Wszystko będzie idealne.

Rzeczywistość jest prawie odwrotna. Niektórzy nawet twierdzą, że jak tylko zaczniesz kodować, powinieneś być w trybie konserwacji. Chodzi o to, że etap „Implementacja” SDLC tak naprawdę nie istnieje jako taki, ponieważ nigdy nie należy odkładać naprawiania błędów lub refaktoryzacji na bok i udawać, że tworzony kod jest „świeży” i doskonały.

To powiedziawszy, przypuszczam, że jest zbyt obsesja na punkcie refaktoryzacji. Po prostu jeszcze tego nie widziałem. A im więcej mam doświadczenia, tym bardziej myślę, że dobrze byłoby, gdyby więcej zespołów oprogramowania wyraźnie odmówiło pracy w napiętych terminach i popadło w techniczne długi. W końcu jest to najczęstszy powód, dla którego refaktoryzacja zostaje odłożona na bok w prawdziwym świecie.

Sugerowałbym, aby nie polegać wyłącznie na odczuciu lub zapachu kodowym.

Wylicz dokładnie, co jest nie tak z kodem i jakie są rozwiązania. Poważnie, zapisz to, ponieważ będziesz chciał sprawdzić, jak skuteczny był twój refaktor przeciwko temu.

Zidentyfikuj sposoby rozbicia reaktora na możliwe do osiągnięcia części i nadaj im priorytety. Dbaj o dyscyplinę, aby skupić się tylko na zakresie każdego kawałka, unikając stycznych, które mogą podważyć twoje zadanie.

Przed kontynuowaniem określ również, jakie testy jednostkowe możesz napisać z istniejącym kodem. Jeśli są już obszerne testy, to świetna rzecz. Brak testów jednostkowych jest świetną okazją do zrobienia czegoś.

Nie ma wątpliwości, że wpadnę w tę pułapkę, ale pewne refaktoryzacja jest ważna dla przyszłego wsparcia / debugowania.

Podczas pisania dużego fragmentu kodu bardzo łatwo jest przechodzić przez wiersze kodu do obecnie pisanej metody. Po ukończeniu ważnego fragmentu kodu umieszczam komentarz do przeglądu: todo: code . Następnie kilka dni później dokonam przeglądu kodu i odpowiednio go zmienię. Jeśli mam problem z przeczytaniem go kilka dni później, co stanie się za kilka miesięcy lub nawet lat.

Wpadam w tę pułapkę, kiedy pierwszy raz uczę się języka lub technologii. Na przykład, kiedy uczysz się java po raz pierwszy, wyobraź sobie, że piszesz aplikację internetową z serwletem, myśląc, że to właściwa droga. Wtedy zdajesz sobie sprawę, że jest jsp i myślisz, że to nowsza wersja, która prawdopodobnie ma rację. Potem, kiedy znajdziesz się w połowie, znajdziesz Struts i może trochę EJB, po czym znajdziesz wiosnę (na podstawie xml), po czym znajdziesz fajne adnotacje @MVC, po których okazuje się, że jest zbyt gadatliwy i jesteś rozpieszczany wybór między groovy / grails i scala / lift! Jest to doskonale w przypadku projektów osobistych, ponieważ zazwyczaj chodzi o naukę i niekoniecznie dotrzymanie określonego terminu.

Byłem też uber-refaktorerem w pracy. Ale kiedy zdobywałem więcej doświadczenia, stałem się bardziej selektywny w kwestii tego, co zmienię. Okazuje się, że opuszczając firmę, nie zabierasz ze sobą kodu i zwykle inni inżynierowie mogą zniszczyć kod prawie szybciej, niż możesz go naprawić.

Zasada, którą stosuję, jest następująca: dokonuję refaktoryzacji, dopóki nie jest tak zoptymalizowana, jak to możliwe , a następnie nie refaktoryzuję jej ponownie, chyba że sytuacja się zmieni, lub rzadziej, jeśli mam inspirację na temat nowego i lepszego sposobu rób rzeczy (na przykład używając nowej funkcji językowej).

Na przykład kiedyś musiałem napisać nowy moduł kodu dla istniejącej aplikacji. Napisałem to w określony sposób, a następnego dnia zastanowiłem się nad tym i pomyślałem, że mogę to przeredagować i uczynić bardziej abstrakcyjnym, ponieważ byliśmy dość pewni, że będzie musiał zostać przedłużony na inne sposoby. Więc zreorganizowałem kod. Potem zdecydowałem, że to trochę zbyt ogólne i skonsolidowałem niektóre klasy i interfejsy, które zasadniczo robiły to samo, używając Generics (C #), aby uzyskać tę samą funkcjonalność. W tym momencie prawdopodobnie mógłbymdalszy refaktor, aby uczynić go jeszcze lepszym, ale jest „wystarczająco dobry” - kod jest dobrze napisany, zgodny z prawidłowymi wzorami projektowymi i koncepcjami inżynierskimi i jest rozszerzalny. Dokonałbym ponownej refaktoryzacji tylko wtedy, gdy wymagania zmusiłyby mnie do ponownej oceny kodu lub gdyby istniała funkcja języka, która mogłaby uczynić kod bardziej przejrzystym i / lub bardziej czytelnym.