Duża część mojego kodu ma poważną wadę projektową. Skończyć czy naprawić to teraz? [Zamknięte]

Jestem uczniem szkoły średniej pracującym nad projektem C # z moim przyjacielem o prawie takim samym poziomie umiejętności jak ja. Do tej pory napisaliśmy około 3000 wierszy kodu i 250 wierszy kodu testowego w zakresie 100 zatwierdzeń. Ze względu na szkołę odłożyłem projekt na kilka miesięcy, a ostatnio mogłem go ponownie podjąć.

Do czasu, gdy go odzyskałem, zrozumiałem, że kod, który napisałem, był źle zaprojektowany, taki jak włączenie nadmiernej liczby wątków do renderera, złe zapobieganie warunkom wyścigowym w interakcji między emulowanym procesorem, GPU i kartą do gry , a także kod, który jest po prostu zbędny i mylący.

Problem polega na tym, że nie ukończyłem nawet głównej funkcjonalności mojego programu, więc nie mogę tak naprawdę zrefaktoryzować, i czuję się zniechęcony tym, że mam pełną świadomość, że mój kod jest wadliwy. Jednocześnie nie chcę rezygnować z projektu; poczyniono znaczne postępy i praca nie może się zmarnować.

Mam wrażenie, że mam kilka opcji: po prostu dokończyć funkcjonalność, omijając kiepski projekt, a następnie refaktoryzować, gdy wszystko działa, zatrzymać wszystko i dążyć do rozplątywania wszystkiego, zanim reszta funkcjonalności będzie mogła zostać ukończona, rozpoczynając projekt wszystko po to, żeby znów było świeże w moim umyśle, lub wręcz porzucenie projektu z powodu jego nadmiernych rozmiarów (w zasadzie „powrót do deski kreślarskiej”).

W oparciu o doświadczenia innych w takich projektach, jakie jest wyjście z powrotu na właściwą ścieżkę? Na podstawie odpowiedzi na tej stronie panuje ogólna zgoda co do tego, że przepisywanie jest na ogół niepotrzebne, ale dostępna opcja, jeśli kod nie może być utrzymany bez nadmiernych kosztów. Naprawdę chciałbym kontynuować ten projekt, ale na obecnym etapie mój kod nie jest wystarczająco dobrze zaprojektowany, abym mógł kontynuować, a uczucie przygnębienia zniechęca mnie do kontynuowania.

Gdybym był w twoich butach, prawdopodobnie spróbowałbym tego w ten sposób:

• po pierwsze, zakończ obecny projekt - przynajmniej częściowo - jak najszybciej, ale w stanie roboczym . Prawdopodobnie musisz zmniejszyć swoje pierwotne cele, pomyśl o minimalnej funkcjonalności, którą naprawdę potrzebujesz w „wersji 1.0”.

• wtedy i tylko wtedy pomyśl o przepisaniu od zera (nazwijmy to „wersją 2.0”). Być może możesz ponownie użyć części kodu z wersji 1.0. Może po ponownym przespaniu się nad sytuacją podejmiesz decyzję, możesz zmienić wersję V1.0 i zaoszczędzić większość. Ale nie podejmuj tej decyzji, zanim nie będziesz mieć pod ręką „dowodu koncepcji wersji 1.0”.

Działający program „1.0” jest czymś, co możesz pokazać innym, nawet gdy kod jest zły (o czym nikt inny nie będzie się martwić, oprócz ciebie). Jeśli w trakcie tworzenia wersji 2.0 zdasz sobie sprawę, że kończy Ci się czas, nadal masz wersję 1.0 jako częściowy sukces, co znacznie poprawi twoje morale. Jeśli jednak nie ukończysz najpierw wersji 1.0, istnieje duża szansa, że ​​nigdy nie ukończysz wersji 2.0, ponieważ gdy będziesz w połowie, pojawi się punkt, w którym ponownie nie będziesz zadowolony z projektu, a potem? Czy porzucisz V2.0 ponownie i będziesz pracować na V3.0? Istnieje wysokie ryzyko wpadnięcia w ten niekończący się krąg, który nigdy się nie skończy.

Lepiej wykorzystaj to jako okazję do nauczenia się, jak osiągać cele pośrednie, zamiast możliwości nauczenia się, jak pozostawiać projekty w stanie niedokończonym.

Gotowe projekty IT, nawet te wadliwe, są znacznie lepsze niż niedokończone.

Niedokończone też mogą cię wiele nauczyć, ale nie tak bardzo jak ukończone.

Możesz go teraz nie widzieć, ale zyskujesz ogromną wartość, pracując nawet z wadliwym kodem.

Głosuję za zakończeniem, a następnie, jeśli zajdzie taka potrzeba, refaktoryzacją. Kiedy zaczniesz pracować z większą liczbą projektów, zobaczysz, że zaskakująco często część, która „miała zostać zrefaktoryzowana”, pozostaje niezmieniona przez lata, podczas gdy inne elementy są przedłużane.

Z punktu widzenia zatrudnienia w większości przypadków otrzymasz więcej uznania za ukończony projekt.

Z radością rozpocznę projekt od nowa.

Jesteś uczniem i wciąż się uczysz. To stawia cię w zupełnie innej pozycji niż pytanie, z którym się łączysz.

• Nie ponosisz żadnej odpowiedzialności zawodowej za swój kod; jeśli miałbyś teraz usunąć cały projekt i odejść, nie ponosiłbyś żadnych konsekwencji. To ogromna zaleta dla programisty. W pytaniu, które podłączyłeś, programiści starają się utrzymać oprogramowanie, za które ludzie płacą pieniądze, a nawet małe błędy mogą powodować duże problemy z klientami, co sprawia, że ​​pisanie od zera jest niebezpieczne. Nie masz tego problemu.

• Jako osobisty projekt jest to idealna okazja do wypróbowania nowych rzeczy i uczenia się na własnych błędach. To wspaniale, że rozpoznajesz problemy ze starym kodem, ponieważ oznacza to, że nauczyłeś się robić lepiej. Doświadczenie z prób i błędów może być nieocenione dla początkujących programistów.

• Twój projekt jest stosunkowo niewielki i zasadniczo nie masz żadnych testów. Napisanie 3000 linii od zera może potrwać kilka nocy, zwłaszcza, że ​​masz już pomysły, co zrobić lepiej następnym razem.

• Praca w zepsutej bazie kodu będzie znacznie większym obciążeniem dla twojego morale niż przepisywanie.

Nawiasem mówiąc, może to być świetna okazja, aby spróbować napisać bardziej modułowy program z testami jednostkowymi. Takie postępowanie znacznie ułatwia zrozumienie kodu, jeśli wrócisz do niego po długiej przerwie, i pomaga zapobiegać błędom, które możesz przypadkowo wprowadzić z powodu zapomnienia.

Na koniec, oto jedna opinia na temat mądrości czasami cofania się o krok, aby robić większe kroki naprzód.

Prawdopodobnie nadal jesteś w części „szybkiego uczenia się” swojego rozwoju. Istnieje spora szansa, że ​​za kilka miesięcy odkryjesz, że Twój nowy i niesamowity projekt jest strasznie zepsuty w sposób, o którym nawet nie wiedziałeś, kiedy zacząłeś.

Wykonuj zadania - jest to najważniejsza rzecz, której musisz się nauczyć. Uwierz mi, znam wielu ludzi (nie tylko programistów), którzy utknęli w pętli „zaczynaj od nowa od zera, ponieważ tyle się nauczyłem, zanim zacząłem pracę nad tym projektem”. Problem w tym, że nigdy się nie kończy - dopóki nie przestaniesz uczyć się nowych rzeczy, co nie jest miłym miejscem :)

Jest to również ważne, aby móc właściwie zakończyć wszystko. Zaczynanie od nowa jest ekscytujące, fajne, zabawne ... ale jeśli się tego nauczysz, nigdy nie będziesz w stanie niczego ukończyć. Ponownie, nie jest to bardzo przydatna umiejętność i nie jest tak dobra, jak zrobienie czegoś użytecznego (lub zabawnego). Życie jest krótkie, czas jest ograniczony i nie możesz po prostu ćwiczyć bez konkretnych rezultatów - oszalejesz z tego powodu. Jeśli nie możesz rozpocząć pracy, ponieważ nie możesz zdecydować, które podejście wybrać, jesteś już w strefie zagrożenia.

Zawsze będą impulsy, aby zacząć od nowa. Nawet w środowisku edukacyjnym są to prawdopodobnie zły pomysł. Nie oznacza to, że musisz przenieść każdy prototyp do aplikacji gotowej do produkcji, z dala od niego. Ale musisz przynajmniej przejść do działającej fazy prototypu - najprawdopodobniej pomoże ci to w morale i jest to bardzo przydatna cecha dla dowolnego dewelopera. Zrób wszystko . A zabawne jest to, że szybko zobaczysz, że istnieje milion innych fajnych lub przydatnych rzeczy, które możesz zrobić ze swoim prototypem zamiast „przepisywać go od zera” - aw wielu przypadkach nawet go przerabiać. Wszystko, co robisz, ma swój koszt - w międzyczasie mogłeś robić coś innego.

Postępuję zgodnie z ideologią „Spraw, by to działało, Spraw, aby było dobrze, Spraw, aby było to szybkie” w tworzeniu oprogramowania.

1. Niech to działa : Napisz podstawową funkcjonalność, aby projekt był użyteczny. Rób, co musisz, aby wszystko działało, nawet jeśli oznacza to brzydki kod.
2. Popraw to : napraw błędy i przebuduj kod, aby łatwiej było go czytać, rozumieć i utrzymywać.
3. Zrób to szybko : Zoptymalizuj program, starając się zachować równowagę między szybkością, zużyciem zasobów i łatwością konserwacji.

W tej chwili nie ukończyłeś kroku 1. Spraw, by najpierw działał, a potem możesz się martwić, jak brzydki jest twój kod. W rzeczywistości stworzenie działającego produktu jest jedną z najtrudniejszych rzeczy dla nowych programistów, ponieważ tak bardzo angażują się w doskonalenie kodu za pierwszym razem, więc utknęli w piekle optymalizacyjnym i nigdy nie zajęli się dokończeniem wdrażanie wszystkich funkcji. Musisz nauczyć się odkładać na bok wszystkie obawy związane z refaktoryzacją i optymalizacją, abyś mógł skoncentrować się na tym, aby oprogramowanie działało. Gdy zdobędziesz więcej doświadczenia, za pierwszym razem naturalnie zrobisz więcej rzeczy, więc konieczne jest mniej refaktoryzacji.

Pamiętaj: przedwczesna optymalizacja jest źródłem wszelkiego zła (zobacz to doskonałe pytanie Programmers.SE, aby uzyskać dobrą dyskusję). Jeśli spędzasz zbyt dużo czasu, zastanawiając się, jak ulepszyć kod, utkniesz w paraliżu analizy . To zabija projekt. Lepiej po prostu wykonać projekt, zanim zaczniesz go optymalizować.

Cytując świetnego mówcę motywacyjnego: po prostu zrób to .

Jak zawsze, istnieje odpowiedni xkcd:

Przepisz to. Niedziałający kod ma niewielką wartość, a trzy tysiące wierszy to niewiele kodu. Nie zajmie to prawie tyle czasu, ile zajęło napisanie kodu, który aktualnie posiadasz, i będzie znacznie lepiej. Często wyrzucałem pięćset lub tysiąc wierszy złego kodu i często przepisywanie trwa jedną piątą.

Większość pojęć związanych z „nie przepisuj” odnosi się do dużych systemów wykonujących ważne czynności i podlegających ciągłym zmianom w celu spełnienia zmieniających się wymagań. Przepisywanie złożonych systemów w użyciu rzadko kończy się powodzeniem.

Twoja sytuacja jest zupełnie odwrotna. Masz małą aplikację bez użytkowników, a jedynymi wymaganiami są te, które zdecydujesz się wdrożyć. Więc śmiało, przepisz to.

Ponowne uruchomienie od zera jest zwykle złym posunięciem w prawdziwych projektach, głównie dlatego, że projekty z prawdziwego życia gromadzą poprawki błędów, o których nowy deweloper nie jest świadomy (np. Zobacz Rzeczy, których nigdy nie powinieneś robić , od Joela na blogu Software ).

Niemniej jednak projekty szkolne nie dziedziczą takiej historii i zwykle zaczynają od kodowania i projektowania w tym samym czasie z częściową wiedzą na temat komputerów i brakiem doświadczenia. Rozważę twoją pierwszą wersję jako prototyp, wykorzystaną jako dowód koncepcji, która się nie powiodła, i chętnie ją wyrzucę (zobacz Jakie są różnice między prototypami odrzuconymi a ewolucyjnymi? W celu omówienia prototypowania ewolucyjnego).

Właściwy projekt dojrzał w twojej głowie i nie powinien zająć dużo czasu, aby zapisać go w kodzie.

Z szacunkiem nie zgadzam się z sugestiami, że przepisywanie to zły pomysł.

W dziedzinie cyklu życia oprogramowania ogólnie przyjmuje się, że czas i wysiłek wymagany do skorygowania błędu zwiększa się o rząd wielkości każdej warstwy w cyklu życia. Oznacza to, że jeśli poprawienie błędu na poziomie wymagań zajmie 1 godzinę, zajmie to 10 godzin projektowania, 100 godzin testowania kodu i 1000 godzin jako poprawki błędu. Te liczby mogą wydawać się oburzające, ale są akceptowane w branży jako w przybliżeniu prawidłowe. Oczywiście mniej w mniejszym projekcie, ale ogólna idea pozostaje. Jeśli Twój projekt ma podstawową wadę projektową, lepiej jest nazwać to doświadczeniem uczenia się i wrócić, przejrzeć początkowe wymagania i przeprojektować.

Chciałbym również zachęcić do rozważenia modelu rozwoju opartego na testach przy użyciu strukturalnych testów jednostkowych. Są bolesne i początkowo wydają się stratą czasu, ale ich zdolność do wykrywania błędów, zwłaszcza gdy integracja z kodem innej osoby nie może zostać przesadzona.

Zgubiłeś mnie na to zdanie:

Problem polega na tym, że nie ukończyłem nawet głównej funkcjonalności mojego programu, więc nie mogę tak naprawdę zrefaktoryzować, i czuję się zniechęcony tym, że mam pełną świadomość, że mój kod jest wadliwy.

Wierzę w zasadę (wyrażoną w Systemantics ), że

• Niezmiennie stwierdzono, że złożony system, który działa, wyewoluował z prostego systemu, który działa.
• Złożony system zaprojektowany od podstaw nigdy nie działa i nie można go załatać, aby działał. Musisz zacząć od nowa, zaczynając od działającego prostego systemu.

Tak więc pisanie złożonego systemu obejmuje

• Pisanie prostego systemu
• Upewnij się, że działa

... tj. następujące kroki:

1. Napisz trochę kodu
2. Przetestuj, aby upewnić się, że działa
3. Napisz trochę więcej kodu
4. Przetestuj jeszcze raz
5. Itp.

Pamiętaj, że krok 3 może obejmować:

3. Napisz trochę więcej kodu
   1. Przebuduj istniejący kod, aby przygotować go do nowego dodania
   2. Przetestuj refaktoryzację, aby upewnić się, że nadal działa
   3. Dodaj nową funkcjonalność

Ponadto krok 2 „Przetestuj, aby upewnić się, że działa” może wymagać przepisania, jeśli nie zadziała.

Gdybym budował na zepsutej bazie kodu, nie chciałbym dodawać dalszej funkcjonalności. Byłbym więc skłonny zaplanować coś w rodzaju „uprościć istniejącą implementację wątków” jako kolejną część pracy do zaimplementowania. Zakładając, że testujesz w miarę postępów, powinieneś być w stanie potraktować to jako ćwiczenie refaktoryzacyjne. Kryteria sukcesu / wyjścia dla tego etapu prac byłyby następujące:

• Kod źródłowy jest prostszy
• I nie wprowadzono żadnych nowych błędów
• (I niektóre stare błędy wyeliminowane)

Nawiasem mówiąc, „testowanie w celu upewnienia się, że działa” niekoniecznie oznacza „testy jednostkowe” - gdy struktura zespołu jest prosta, możesz przetestować (prosty) system za pomocą (prostych) testów systemowych (zamiast testów jednostkowych) .

Jednym z problemów, z którymi się zmagasz, gdy napotykasz taki problem, jest emocjonalne przywiązanie do kodu, który napisałeś do tej pory w taki czy inny sposób.

Kolega powiedział mi, że pisze program na uniwersytecie, gdy pobierał lekcje od słynnego profesora (sądzę, że to był Dijkstra). Poprosił profesora, aby spojrzał na kod, nad którym pracował od ponad miesiąca. Profesor zapytał go, czy zrobił kopię zapasową, odpowiedział nie. Następnie profesor usunął cały swój kod i powiedział mu, aby napisał go ponownie.

Był wkurzony, ale 3 dni później ukończył program z czystszym kodem, mniej błędów i mniej linii kodu.

Spróbuj rzetelnie oszacować, która opcja jest najlepsza w czasie dostępnym dla projektu.

Dostępne są 3 opcje

• Usuń to (całkowicie, nie oglądając się za siebie)
• Kontynuuj pracę w starym stylu
• Refaktoryzuj kod w trakcie podróży.

Jestem profesjonalnym programistą od ponad 10 lat i w swojej pracy doszedłem do wniosku, że ostatnia opcja jest najczęściej wybierana, ale nie zawsze jest to najlepsza opcja.

Wygląda na to, że Twoje umiejętności znacznie wzrosły w tym okresie. Być może praca nad tym projektem przyczyniła się do tego. Zaprojektowanie go ponownie jako celowego uczenia się byłoby owocne.

Pamiętaj, że nie jest to coś, co musisz dostarczyć jako działający program dla klienta. Został napisany specjalnie dla praktyki. Tak więc, chyba że chcesz ćwiczyć problemy z wysyłką i wadliwą dostawą, myślę, że obecnie znajdujesz się w fazie rozwojowej, w której praca nad „projektowaniem mięśni” okazałaby się owocna.

Robiąc to, skup się na procesie projektowania i planowaniu, a także rozważ swoje dotychczasowe rzeczy i zastanów się, co lepiej rozumiesz.

Refaktor. Refaktor. Refaktoryzacja! REFACTOR !!!!

Szczerze mówiąc, bez względu na twoje doświadczenie jest to powszechny problem. Napisałeś kod, nauczyłeś się czegoś i chcesz wykorzystać nową wiedzę na temat starego kodu. Chcesz porównać stary kod z nową wiedzą.

To po prostu nie zadziała. Jeśli to zrobisz, twoja aplikacja / gra nigdy nie zostanie ukończona. Zamiast tego spróbuj przeznaczyć swój czas na projekt, aby niektóre z twoich „zadań” polegały na refaktoryzacji złego kodu. Powiedzmy, że na przykład masz okropną metodę zapisywania gry. Nadal pracuj nad samą grą, ale znajdź trochę czasu na refaktoryzację (zastąpienie) tej okropnej metody. Staraj się, aby reaktory były małe i nie powinno to stanowić problemu.

Gdy dojdziesz do znacznej części aplikacji, która wymaga refaktora, robisz to źle, poważnie. Rozbij to refaktoryzację na mniejsze części. Spróbuj poświęcić siedem godzin na pisanie kodu i godzinę na refaktoryzację.

Kiedy skończysz z projektem i wciśniesz funkcję zamrażania funkcji, możesz poświęcić trochę czasu na refaktoryzację. Na razie załatw grę, ale nadal staraj się ją trochę refaktoryzować. To najlepsze, co możesz zrobić.

Zawsze będzie coś do refaktoryzacji.

Powiedziałbym, że to trochę zależy od tego, jaki masz kod i gdzie dokładnie leżą problemy. To znaczy, jeśli twoje fundamenty są dobre (w większości części odpowiedni projekt klasy, dobre odsprzęganie / spójność itp., Tylko kilka złych wyborów, takich jak wspomniane przez ciebie wątki), to na pewno dostań się od zera 1.0, a następnie refaktoryzuj jak nie ma jutra.

Z drugiej strony, jeśli tak naprawdę jest to tylko garstka brzydkich spakowanych plików tekstowych, które w jakiś sposób przechodzą przez kompilator, bez dostrzegalnej struktury itp. (Innymi słowy, prototyp uczenia się w praktyce zgodnie z koncepcją), wtedy wolę go usunąć i zacząć od nowa.

W kolejnej wersji zastosuj zwinne podejście: ustal sobie powtarzalną oś czasu, na przykład 2 tygodnie lub cokolwiek, co pasuje do twojego harmonogramu. Na początku każdego kawałka (nazwijmy to sprintem) ustal sobie cele, które są osiągalne w ciągu 2 tygodni. Idź naprzód i rób je, staraj się, jak możesz, aby działało. Ustaw swoje cele tak, aby po każdych 2 tygodniach masz coś, co można pokazać przyjacielowi, a nie tylko jakieś abstrakcyjne prace wewnętrzne. Google „scrum” i „smart goal”. Wszystko to jest bardzo łatwe do zrobienia, jeśli jesteś sam, tylko kawałek papieru z kilkoma szybko zapisanymi punktami.

Jeśli możesz to zrobić, dobrze jest zacząć od nowa. Jeśli wiesz głęboko, że po rozpoczęciu od początku prawdopodobnie skończysz tam, gdzie teraz jesteś, to trzymaj się swojego kodu i spraw, aby działał.

Musisz postawić się w buty pracodawcy.

Dla większości rekruterów byłbyś najbardziej wartościowy, jeśli pójdziesz w ten sposób: - Zakończ go 100% testami nowego napisanego kodu. - Dodaj testy dla starego (źle zaprojektowanego) kodu. - Przebuduj go, aby osiągnąć to, czego chciałeś jako projekt.

Zrób to wszystko z dobrym procesem wersjonowania, gałęziami i tagami.

Przepisywanie jest często seksownym pomysłem, ale często jest to pomysł, który mają nowicjusze, co w rzeczywistości jest niebezpieczne. Pokazanie, że jesteś bardziej skłonny do poprawy jakości pracy, którą już wykonałeś, że od zera jest dobrym znakiem, że jesteś poważną osobą.

Oczywiście możesz go przepisać, ale wtedy możesz zrobić z niego kolejny projekt.

Żeby dodać trochę moich przeszłych doświadczeń do miksu. Pracuję nad pobocznym projektem od ponad roku, ilekroć mam wolne kilka minut. Ten projekt przeszedł od prostego stanowiska testowego do klasy statycznej do zorientowanej obiektowo cienkiej wyściółki, którą obecnie ma.

Przez wszystkie te zmiany zachowałem tę samą funkcjonalność kodu, z wyjątkiem poprawek błędów i zwiększania wydajności (musi być tak szybko, jak to możliwe). Ta sama baza kodu, mimo że została zrefaktoryzowana, pozostała taka sama i jako taka znacznie ją poprawiłem bez konieczności przepisywania kodu od zera i marnowania czasu.

Oznaczało to, że byłem w stanie poprawić kod w szybszym tempie niż byłbym w stanie wcześniej. Oznaczało to również, że kiedy jechałem, łatwiej było powiedzieć, co trzeba usunąć, tj. Niepotrzebne zajęcia i co może pozostać łatwiejsze niż przepisywanie starego pomysłu, który wciąż jest w mojej głowie.

Dlatego moją radą byłoby przefakturowanie kodu i przejście od tego miejsca, wprowadzając niezbędne poprawki. Pamiętaj jednak, że jeśli zdecydujesz się przepisać od zera, powinieneś wziąć dobre pomysły ze starego projektu i przyjrzeć się im dokładnie, aby zobaczyć, gdzie są wadliwe. Nie tylko kopiuj stary kod do nowego projektu.

Odpowiedź zależy od czegoś, co lubię nazywać „pułapem złożoności”. Gdy dodajesz coraz więcej do bazy kodu, istnieje tendencja do tego, że staje się ona coraz bardziej złożona i coraz mniej zorganizowana. W pewnym momencie osiągniesz „pułap złożoności”, w którym to momencie postęp staje się bardzo trudny. Zamiast próbować poruszać się brutalnie, lepiej wykonać kopię zapasową, zreorganizować / przepisać, a następnie kontynuować.

Czy twoja baza kodów jest tak zła, że ​​zbliżasz się do pułapu złożoności? Jeśli uważasz, że tak jest, poświęć trochę czasu na oczyszczenie i uproszczenie przed kontynuowaniem. Jeśli najprostszym sposobem na oczyszczenie jest przepisanie niektórych części, nie ma sprawy.

Ani? Obie?

Kontynuuj, poświęć trochę czasu na zrewidowanie istniejącego projektu i trochę czasu na dodanie nowej funkcjonalności.

Jeśli masz racjonalne interakcje, może to być dobre miejsce na początek („nadmierne wątki w rendererze” brzmią jak nieefektywność, a nie coś, co spowodowałoby problemy z poprawnością). Sprawdź, czy potrafisz wymyślić ogólny sposób na ucieczkę od ras (i być może impasów), lub przynajmniej na wiele konkretnych sposobów.

Nie wiem, w jakim stopniu dostępne są detektory impasu i rasy dla języka C #, ale jeśli istnieją, mogą być przydatne w identyfikowaniu problemów i sprawdzaniu poprawności działania.

Uważam, że generalnie jestem bardziej zmotywowany do rozwiązywania problemów z kodem, który robi coś pożytecznego, niż do wyrzucania go i rozpoczynania od nowa. Są przypadki, w których rozwój spalonego pola (analogicznie do greenfield i brownfield ...) jest bardziej satysfakcjonujący, ale zwykle dzieje się tak w przypadku rzeczy, w których istniejące podejście jest tak dalekie od miejsca, w którym powinno być, że nie jest już nawet błędne.

Jeśli twój kod jest modułowy, powinieneś być w stanie dokończyć resztę kodu wokół źle napisanych komponentów, a następnie ponownie napisać źle napisane komponenty bez wpływu na resztę kodu.

W takim przypadku to od Ciebie zależy, kiedy ponownie napiszesz źle napisane komponenty. Jeśli źle napisane komponenty są tak źle napisane, że gotowy kod nie będzie z nimi działał tak, jak są, musisz je ponownie napisać, zanim skończysz resztę kodu.

Pierwsze pytanie, które powinieneś sobie zadać, brzmi: „jak zła jest wada?”

Co dokładnie zrobiłeś źle?

Jeśli coś jest tak źle, że zmarnujesz mnóstwo godzin, próbując rozwiązać problem, narażasz wrażliwe dane (hasła / karty kredytowe) lub powoduje złą podatność, być może powinieneś je edytować, ale przez większość czasu możesz weź to, co masz, dokończ i rozwiąż problem później.

Programiści uwielbiają ulepszać swoje aplikacje, chcąc, aby były „jak najlepsze”, ale to nie jest właściwe podejście.

JEŻELI opublikujesz swoją aplikację tak szybko, jak to możliwe, nawet jeśli nie jest to 100%, wszystkie błędy i wszystkie, to otrzymujesz INFORMACJE ZWROTNE od innych, mając czas na naprawienie błędów i innych rzeczy w wersji 1.1. Inne osoby będą w stanie pomóc Ci ulepszyć aplikację i możesz stracić czas na robienie czegoś, czego ludzie nie lubią.

Więc w twoim przypadku, weź to tam, uzyskaj trochę opinii, a następnie możesz ustrukturyzować wersję 2.0 ze wszystkimi zmianami i naprawić wadę, którą masz.

Kolejną rzeczą do zapamiętania jest to, że ciągle się doskonalimy. Jest takie powiedzenie, że jeśli możesz spojrzeć na swój kod sprzed roku i zobaczyć, że jest zły, oznacza to, że wciąż się poprawiasz, i to jest świetna rzecz.

To zależy od tego, jak popsuty jest twój kod.

• Jeśli popełniłeś prawdziwe błędy n00b, które powodują, że kod jest zbyt skomplikowany lub zbyt szczegółowy, zalecamy przepisanie tych części.

• Jeśli uważasz, że masz poważne błędy, które i tak będziesz musiał naprawić, napisz kilka testów jednostkowych, które mogą sprawdzić, czy naprawiłeś błąd (... ponieważ nie możesz jeszcze uruchomić programu). Lepiej jest wcześnie naprawiać błędy i zdecydowanie lepiej je naprawiać, póki jeszcze pamiętasz, co robi kod.

• Jeśli nie podoba ci się, jak nazywają się te metody, do której klasy należą, lub takie małe rzeczy, po prostu użyj IDE. (Pamiętaj, że jest to C #, a nie niektóre javascript, python, perl, php itp.) Kiedy pracujesz nad kodem, który korzysta z komponentu, którego dotyczy problem, i masz jasny obraz tego, co ten komponent powinien robić, następnie przebuduj go, jeśli Twoje IDE czyni go bezbolesnym.

W przeciwnym razie uruchom go i doskonal swoje umiejętności przy kolejnym projekcie.

Jak sugerują inni, ponieważ jest to projekt osobisty, a nie (jeszcze) projekt profesjonalny, poważnie rozważę jego przepisanie.

Możesz jednak wykorzystać tutaj metodę naukową, przeprowadzając eksperyment. Najpierw stwórz hipotezę. Moim zdaniem byłoby „prawdopodobnie czas na przepisanie”. Aby zaoszczędzić czas, zmniejszyć koszty awarii i nieco ograniczyć uprzedzenie, zanim przystąpisz do programowania, określ czas („ramka czasu”). Sugerowałbym może 4 godziny naścienne. Zdecyduj także o metodyce oceny hipotezy. Ponieważ stawki są niskie, proponuję jako metodologię, po prostu zadaj sobie pytanie: „Cieszę się, że to zrobiłem?” Teraz rozpocznij eksperyment. Jaka jest ocena hipotezy po wybranym czasie? np. z mojego przykładu, czy jesteś zadowolony, że zacząłeś przepisywać teraz, skoro spędziłeś na tym 4 godziny? To prawdopodobnie właściwy wybór.

Możesz poprosić o wszystkie porady na świecie, ale nie ma nic lepszego niż empiryczne sprawdzenie hipotezy.

Kilka powodów, dla których warto rozważyć wybór przepisania jako eksperymentu:

• Z mojego doświadczenia wynika, że ​​zazwyczaj jest to więcej zabawy. Głównym powodem, dla którego przepisy nie są często wybierane w sytuacjach zawodowych, jest to, że zabawa nie jest jedynym kryterium. Ale wciąż jesteś stosunkowo nowy w kodowaniu, więc zabawa jest prawdopodobnie dość ważnym kryterium, a także wskaźnikiem innych czynników, które mogą być dla ciebie niematerialne na tym wczesnym etapie (zabawa sugeruje, że dowiesz się więcej itp.).
• Twoje doświadczenie i prawdopodobnie dokuczliwe poczucie sumienia wydają się mówić ci, że przepisanie jest warte rozważenia. Posłuchaj tego głosu, jeśli taki istnieje. Nawet jeśli nie zastosujesz się do jego rad, przynajmniej słuchaj. W przyszłości pojawi się więcej głosów zewnętrznych i trzeba ćwiczyć słuchanie własnego rozsądku.
• Podejrzewam, że po przepisaniu, bardziej prawdopodobne jest, że będziesz bardziej modularyzował swój kod. Podczas tworzenia modułów masz więcej niezawodnych komponentów wielokrotnego użytku, które możesz wykorzystać w innych projektach. Może się nawet okazać, że to, co wydawało się zwykłym modułem głównego projektu, okazuje się być najciekawszym i najcenniejszym fragmentem kodu, który piszesz.

Wykończenie czegoś jest dobrym pomysłem, ale nie w próżni. Jeśli rozpoczniesz przepisywanie, możesz zakończyć coś, kończąc określony podmoduł. Możesz ustawić to jako pierwszy cel po powyższym eksperymencie. Wykończenie nie musi jeszcze kończyć początkowego głównego projektu. Po zakończeniu modułu zakończ inny itd., Dopóki nie zakończysz przepisywania całego zakresu oryginalnego projektu, jeśli chcesz.