Co jest takiego złego w kreatywnym kodowaniu? [Zamknięte]

42

Oglądałem dziś wieczorem Boba Rossa, który malował „szczęśliwe drzewa”, i zorientowałem się, co ostatnio stresuje mnie w moim kodzie.

Społeczność ludzi tutaj i na Stack Overflow wydaje się odrzucać powiew niedoskonałości. Moim celem jest pisanie szanowanego (a zatem łatwego w utrzymaniu i funkcjonującego) kodu poprzez doskonalenie moich umiejętności. Jednak koduję twórczo.

Pozwól mi wyjaśnić, co rozumiem przez „twórcze kodowanie”:

  • Moimi pierwszymi krokami w projekcie jest często usiąść i wykpić trochę kodu. W przypadku większych rzeczy planuję trochę tu i tam, ale głównie po prostu nurkuję.
  • Nie rysuję żadnej z moich klas, chyba że pracuję z innymi, którzy tworzą inne elementy w projekcie. Nawet wtedy z pewnością nie jest to pierwsza rzecz, którą robię. Zwykle nie pracuję nad dużymi projektami i nie uważam tego obrazu za bardzo przydatny.
  • Pierwsza runda kodu, który piszę, zostanie przepisana wiele, wiele razy, kiedy testuję, upraszczam, ponawiam i przekształcam oryginalny hack w coś wielokrotnego użytku, logicznego i wydajnego.

Podczas tego procesu zawsze sprzątam. Usuwam nieużywany kod i komentuję wszystko, co nie jest oczywiste. Testuję ciągle.

Mój proces wydaje się być sprzeczny z tym, co jest akceptowalne w środowisku profesjonalnych programistów i chciałbym zrozumieć, dlaczego.

Wiem, że większość porywającego złego kodu polega na tym, że ktoś utknął w bałaganie byłego pracownika, a jego naprawienie kosztuje dużo czasu i pieniędzy. Że rozumiem Nie rozumiem, w jaki sposób mój proces jest nieprawidłowy, biorąc pod uwagę, że końcowy wynik jest podobny do tego, co można uzyskać od planowania wszystkiego od samego początku. (A przynajmniej tak znalazłem.)

Mój niepokój związany z tym problemem był ostatnio tak poważny, że przestałem kodować, dopóki nie dowiem się wszystkiego o każdej metodzie rozwiązania konkretnego problemu, nad którym pracuję. Innymi słowy, w większości przestałem kodować całkowicie.

Szczerze doceniam twój wkład, bez względu na twoje opinie na ten temat.

Edycja: Dziękuję wszystkim za odpowiedzi. Nauczyłem się czegoś od każdego z nich. Wszyscy byliście najbardziej pomocni.

Ćwiek
źródło
6
Nie ma nic złego w sposobie pracy, wiesz, co jest ważne w końcowym wyniku i to jest naprawdę ważne. Chodzi o to, że możesz mieć trudności w pracy z dużym zespołem w ten sposób, ale prawdopodobnie dostosujesz się, jeśli tak jest. To naprawdę brzmi, jakbyś zmierzał prosto do Analysis Paraliż: sourcemaking.com/antipatterns/analysis-paralysis
Bjarke Freund-Hansen,
39
Miesiące przepisywania pozwolą Ci zaoszczędzić dni planowania!
Jonas,
3
@Jonas: Dobry. Ale tak naprawdę nie należy lekceważyć Paraliżu Analizy. Z tymi wszystkimi „dobrymi radami” na temat metodologii, wzorców projektowych itp. Naprawdę łatwo jest odnieść wrażenie, że powinieneś planować, analizować i projektować przez wiele dni, nawet zanim dotkniesz jednego wiersza kodu . I to może łatwo stać się bardzo bezproduktywne. Wierzę, że rzeczywistość polega na zrozumieniu, jakie planowanie i projektowanie z góry może ci pomóc na dłuższą metę, i zrozumieniu, kiedy możesz się zanurzyć, aby poczuć, nad czym pracujesz, i faktycznie coś zrobić.
Bjarke Freund-Hansen,
4
Z manifestu Agile: „Oprogramowanie robocze jest podstawową miarą postępu”.
Gary Rowe,
2
To prawie tak, jakby świat programowania był pełen primadonnas. Nie mogę powiedzieć, jak frustrujące jest przejście na SO i zobaczenie 5-krotnie poprawnego pytania, ponieważ użytkownik nie pisze po angielsku lub kod jest uważany za „zbyt początkujący” dla elity.
Scottie,

Odpowiedzi:

29

Nie ma nic złego w testowaniu kodu-refaktorze-powtarzaniu, po prostu powiedz ludziom, że prototypujesz.

Z drugiej strony, w przypadku większych projektów przekonasz się, że przemyślenie projektu z góry pozwoli ci zaoszczędzić dużo czasu w pętli och-cholera-teraz-co!

PS: Techniki tworzenia diagramów pomagają nauczyć się umiejętności myślenia wizualnego, które są cenne, nawet jeśli nikt oprócz ciebie nie widzi twoich diagramów.

Steven A. Lowe
źródło
4
„code-test-refactor-repeat” (lub jego permutacja) to sposób, w jaki piszemy kod. Być może Superman jest „kodowany”, ale śmiertelnicy muszą iterować.
Martin Wickman,
5
@Martin: pewne wstępne myślenie w tej pętli jest często korzystne ;-)
Steven A. Lowe
4
tak długo, jak wiesz, ile to „trochę”!
Frank Shearar,
Dziękuję za odpowiedź. Nigdy nie myślałem o tym, co robię, to prototypowanie, ale tak właśnie robię. Twoja odpowiedź dała mi nowy sposób patrzenia na sprawy i bardzo doceniam twoją odpowiedź.
Brad
7
@Brad, pamiętaj, że czasami prototypy muszą umrzeć zamiast ewoluować.
21

Zawsze wolę przejrzysty, czytelny i prosty kod od dowolnego prezentowanego wizualnie kodu UMLed z wzorami projektowymi, w którym klasa / interfejs zawiera nazwy wzorców, takie jak „ItemVisitor” (?!). Wzory projektowe, techniki OO i wszystko inne mają na celu sformalizowanie reguł. Zasady te pochodzą ze zdrowego rozsądku.

Nie można pracować bez tej formalizacji (chyba że pracujesz sam nad własnym projektem), a nadformalizacja zwiększa koszty projektu. Nigdy nie lekceważ potrzeb innych osób, aby zrozumieć Twój kod. Najlepszy kod jest najprostszy.

Nigdy nie wahaj się ponownie napisać kodu. Zamierzam uzyskać za to X głosów ujemnych (X> = 10), ale pogrubię: ponowne użycie kodu nie jest najważniejsze .

Zanim zaczniesz kodować , powinieneś rozważyć przypadki użycia, które kod zaimplementuje. Ponieważ oprogramowania należy używać, a nie opracowywać. Użyteczność, użyteczność są dwoma najważniejszymi celami i nie ma znaczenia, kto będzie korzystał z tego oprogramowania - inni twórcy zależnych części projektu lub użytkownik końcowy.

duros
źródło
4
+1 za „ponowne użycie kodu nie jest najważniejsze”. Czasem potrzebujesz szwajcarskiego scyzoryka, czasem skalpela.
mu jest za krótki
Dziękuję za twoje komentarze. Jeśli chodzi o to, do czego będzie wykorzystywane powstałe oprogramowanie, zdecydowanie o tym pamiętam podczas całego procesu. Zgadzam się, to jest najważniejsza część. Wspomniałem o możliwości ponownego użycia kodu, ponieważ jest to droga do osiągnięcia tego celu.
Brad
+1 ponownie za „ponowne użycie kodu nie jest najważniejsze” i ani jednego negatywnego zdania (jak dotąd)
Gary Rowe
Myślę, że ekstremalnym naciskiem na „możliwość ponownego użycia” była nieprzenikniona wersja Don't Repeat Yourself i eliminacja powielania.
Rob K
„Użyj przed ponownym użyciem” przekształciło się nawet w ładną małą książkę: 97things.oreilly.com/wiki/index.php/…
Lovis
14

Jestem taki sam. Słuchaj, kiedy inni opowiadają ci o rzeczach, które dla nich działały, ale ignoruj ​​każdego, kto mówi ci, co powinieneś „robić”, jakby istniała jakaś moralna imperatyw. Jeśli znajdziesz coś, co Ci odpowiada, idź z tym. To znaczy, końcowy wynik jest ważny, prawda? Kogo naprawdę obchodzi ścieżka, którą podjąłeś, aby się tam dostać?

Pamiętaj: ludzie są inni . To dobra rzecz. Nie słuchaj ludzi, którzy starają się cię polubić, i opieraj się pragnieniu, aby inni ludzie tacy jak ty, a będziesz dobrze.

Jason Baker
źródło
Każdy, kto mówi, że coś należy zrobić, musi mieć uzasadnione powody, by to zasugerować. Jeśli nie mogą podać dobrego, jasnego i logicznego powodu, wówczas ich „powinno” staje się „być może”.
Tin Man,
1
@Greg - Nawet dobry, jasny i logiczny powód może być dla mnie całkowicie nielogiczny.
Jason Baker,
1
+1. Każdy, kto mówi, że absolutnie powinieneś to robić i to jest po prostu zły. Jasne, musisz uczyć się i słuchać innych (zwłaszcza tych wielkich i doświadczonych), myśleć intensywnie, wypróbowywać i porównywać alternatywne podejścia itp., Ale ostatecznie rób to , co uważasz za słuszne. Jeśli chcesz być po prostu mierny, to idź dalej i postępuj zgodnie z procesem projektowania, ale jeśli coś jest tego warte, musisz zaufać sobie.
Joonas Pulakka,
+1 - Mogę osobiście zacząć od schematu lub zrobić to oficjalnie, ale dzieje się tak dlatego, że oficjalny sposób działa dla mnie. Naprawdę nie możesz nauczyć ludzi, jak stać się mądrzejszym lub bardziej kreatywnym. Są dorośli na swój sposób. Albo je zatrudniasz, albo nie.
Job
6

Wygląda na to, że jesteś:

  1. Próbowanie rzeczy w celu znalezienia najlepszego podejścia (eksperymentowanie, projektowanie przyrostowe)
  2. Przepisywanie kodu, aby był bardziej przejrzysty (refaktoryzacja)
  3. Ciągłe pisanie testów (rozwój oparty na testach)

To, co robisz, jest niesamowite! Wygląda na to, że robisz to doskonale, zwłaszcza jeśli sam to wymyśliłeś i nie nauczyłeś się z (zwinnej) książki programistycznej. Jest w tym oczywiście więcej, ale masz już ustalone wartości. Pamiętaj tylko o przebudowaniu i ulepszeniu projektu podczas dodawania kodu, a BDUF nie powinien być potrzebny .

Czy rozważałeś skupienie się na jednej małej funkcji na raz i wypuszczanie jej po zakończeniu każdej funkcji? Może to pomóc w oderwaniu się od jakiegokolwiek problemu analitycznego, z którym się zmagasz, i pokazuje pracodawcy prawdziwy postęp.

Nie wiem też, o jakiej „społeczności rozwoju zawodowego” mówisz, ale gdybyś był, powiedziałbym im, aby wrócili do swoich wież z kości słoniowej, abyś mógł zacząć swoją pracę!

Martin Wickman
źródło
W pełni popieram to stanowisko, co odzwierciedla moją własną odpowiedź.
Eric O Lebigot,
4

Brad, nie jesteś sam. Znam bardzo dobrych programistów, którzy działają dokładnie tak, jak opisujesz. :)

Jeśli wyczyścisz swój kod i wiesz, jak uczynić go wydajnym i czytelnym, z pewnością rozwinęłeś już umiejętność pisania z góry czystego i wydajnego kodu.

Co więcej, niczego nie można w pełni zaplanować z góry, a najkrótszą drogą do odkrycia subtelności jest często uruchomienie kodu i zrozumienie szczegółów, które zostały przeoczone.

Myślę, że masz się doskonale i że styl programowania, który opisujesz, jest całkowicie poprawny.

Eric O Lebigot
źródło
4

Myślę, że warto uzupełnić powyższe odpowiedzi cytatem Alana J. Perlisa z przedmowy znanej książki MIT „Struktura i interpretacja programów komputerowych”, powszechnie zwanej „SICP”:

Każdy program komputerowy jest wykreślonym w umyśle modelem prawdziwego lub mentalnego procesu. Procesy te, wynikające z ludzkiego doświadczenia i myśli, są ogromne, skomplikowane w szczegółach i w dowolnym momencie tylko częściowo zrozumiane. Są one modelowane dla naszego stałego zadowolenia rzadko przez nasze programy komputerowe. Tak więc, mimo że nasze programy są starannie ręcznie dyskretnymi kolekcjami symboli, mozaik funkcji blokujących, ciągle się rozwijają: zmieniamy je, gdy nasza percepcja modelu pogłębia się, powiększa, uogólnia, aż model ostatecznie osiągnie metastabilne miejsce w jeszcze innym modelu, z którym walczymy ”.

Yugo Amaryl
źródło
dobrze wyłożone. Są to prymitywne modele, modele humanistyczne, a na koniec modele nadludzkie, gdy programista wciąga coraz więcej myśli w działania zachodzące w kodzie.
easymoden00b
3

Jest dobry mądry i zły mądry.

Good Clever - wysoki stosunek między sprytnymi liniami kodu a liniami w nie sprytnej alternatywie. 20 linii kodu, który oszczędza ci pisania 20000, jest wyjątkowo dobry. Good Clever polega na oszczędzaniu sobie pracy.

Bad Clever - niski stosunek między zapisanymi wierszami kodu a zapisanymi wierszami. Jedna linia sprytnego kodu, która oszczędza ci pisania pięciu linii kodu, to Bad Clever. Źle sprytny dotyczy „syntaktycznej masturbacji”.

Uwaga: Bad Clever prawie nigdy nie nazywa się „Bad Clever”; często podróżuje pod pseudonimami „piękny”, „elegancki”, „zwięzły” lub „zwięzły”.

użytkownik8865
źródło
1
„piękny”, „elegancki”, „zwięzły” lub „zwięzły”. ..... Myślę, że widziałem to kiedyś na stronie głównej Ruby on Rails. :-D
Brad
1
Może to tylko ja, ale myślę, że 80% redukcja LOC jest warta sprytu.
rekurencyjny
Znalazłem wielu, którzy nazywają rzeczy „syntaktyczną masturbacją”, podczas gdy w rzeczywistości jest to po prostu zbyt leniwe, aby faktycznie nauczyć się języka, którego używają ...
Svish
3

Zdecydowanie mogę rozpoznać sposób, w jaki opisujesz swój przepływ pracy. Oto rzecz: kiedy zacząłem pracować w środowisku grupowym, prawie wszystkie te rzeczy MUSZĄ się zmienić.

Praca, w której pracuję od około 8 miesięcy, to tak naprawdę moje pierwsze doświadczenie w pracy w zespole programistów nad jednym projektem. Do tej pory dosłownie cała moja kariera była samotnym programistą, który nie musiał radzić sobie ze wszystkim, co wiąże się z pracą zespołową. Nawet kiedy pracowałem w grupie, zawsze była to dość wyciszona praca - miałem swój projekt, który był mój, lub mój jego odcinek, który był mój, itp. To była ciekawa krzywa uczenia się, kiedy przyśpieszyłem prawdziwie współpracujące środowisko pracy zespołowej.

Oto najważniejsza rzecz, którą sobie uświadomiłem: jeśli nie jest cholernie oczywiste, co robisz, prawdopodobnie piszesz kolejny ból głowy kolegi. Większość „zorientowanego na proces” zamieszania, które tu widzicie, ma związek z faktem, że wielu z nas BYŁO kolegą z bólem głowy. A większość teorii zarządzania procesami oprogramowania ma na celu zminimalizowanie tego bólu głowy.

Tak więc rzeczy takie jak planowanie uzgodnionego planu z wyprzedzeniem itp. Chodzi o posiadanie zespołu na pokładzie i synchronizację. Jeśli jesteś zespołem, jesteś już zsynchronizowany ze sobą i nie jest to tak naprawdę konieczne.

Dan Ray
źródło
2

Nie ma nic złego w twoim podejściu jako twórczej formie sztuki. Jeśli rozwijasz się dla własnej korzyści, a to, co robisz, działa dla Ciebie i uważasz, że sprawia ci przyjemność, jest prawdopodobnie równie ważne jak końcowy wynik, jak sam produkt.

W profesjonalnym środowisku pracy, jeśli ramy czasowe projektu są krótkie, być może około 2-3 tygodni lub krócej, wtedy twoje podejście nazywa się szybkim prototypowaniem i jest całkiem odpowiednie do przyszłych zadań.

Jednak w przypadku dłuższych projektów, nawet tych, które pracujesz sam, takie podejście jest prawdopodobnie drogim luksusem dla twojego pracodawcy. Poświęcenie kilku dni budżetu projektu na wstępne projektowanie architektury, a następnie przetestowanie architektury pod kątem tego, jeśli kierownictwo zdecyduje się zmienić specyfikację do ... jest zwykle dobrze spędzony czas i rozwinie swoje umiejętności, aby stać się bardziej wartościowym programistą / architektem dalej w twojej karierze.

Michael Shaw
źródło
2

Dwie perspektywy:

  1. Nikt nie musi utrzymywać obrazu.

  2. Każdy, kto kiedykolwiek widział, jak Bob Ross maluje obraz, wie, że obrazy mają strukturę. Jeśli miałbyś wziąć jedną lekcję od Boba Rossa, byłoby tak, że planowanie z wyprzedzeniem i praca w zorganizowany sposób sprawia, że ​​proces przebiega gładko i wygląda na prosty.

Caleb
źródło
1
Bob Ross nigdy nie malował szczęśliwych drzew przed malowaniem nieba za nimi.
Rob K
1

Koduję prawie w ten sam sposób. Po prostu zacznę pisać i widząc pojawiające się wzory, refaktoryzuję. W ten sposób możesz pomalować się w kącie, musisz wiedzieć, kiedy usiąść i przemyśleć problem, ale czasami po prostu dźgnij go, aby naprawdę zrozumieć problem.

Ale jestem ciekawy tego:

Społeczność ludzi tutaj i na Stack Overflow wydaje się odrzucać powiew niedoskonałości. [..] Mój proces wydaje się być sprzeczny z tym, co jest akceptowalne w społeczności profesjonalnych programistów i chciałbym zrozumieć, dlaczego.

Skąd ktoś w Stack Overflow zna twój proces? A co rozumiesz przez „odrzucenie”? Oczywiście kod wysłany do społeczności programistów zostanie poddany krytycznej analizie. Ale jeśli ktoś zauważy obszary, w których można poprawić kod, może to być tylko dobra rzecz, prawda?

Mam nadzieję, że wysyłając pytanie do Stackframe, oczyszczasz swój kod i próbujesz sprowadzić go do najprostszej możliwej formy, z szacunku dla czytelników (czasami rozwiązujesz swój problem, próbując uczynić go prezentowalnym dla innych), w którym jeśli jakakolwiek opinia jest dobra. Jeśli opublikujesz kod, o którym wiesz , że jest zły, i wiesz, dlaczego jest zły, zanim go opublikujesz, nie powinieneś brać go osobiście, jeśli ludzie zauważą , że jest zły.

Błoto
źródło
Nie miałem na myśli żadnych pytań ani odpowiedzi, które osobiście zadałem. Kiedy zamieszczam pytania, dzielę je na najprostsze możliwe przypadki i to samo z moimi odpowiedziami. Zauważyłem, że kiedy inni umieszczają niezbyt doskonały kod w swoich pytaniach lub nie są pewni, jak zadać właściwe pytanie, są wielokrotnie zastrzeleni. W przypadkach granicznych, w których pytanie jest bliskie dobrym, często je edytuję lub dodaję komentarze, aby popchnąć PO we właściwym kierunku. Nie wydaje mi się, żeby tak się zwykle działo. [więcej w następnym komentarzu]
Brad
W każdym razie, po przeczytaniu odpowiedzi na moje pytanie tutaj, czuję, że źle odczytałem społeczność i rzuciłem krytykę odpowiedzi na krytykę kompletnych projektów, które, jak wyjaśniłeś, to dwie różne rzeczy.
Brad
1

Korzystam również z twojego podejścia. Działa to dla mnie lepiej, ponieważ zmniejsza ryzyko nadmiernej inżynierii.

Bardzo często rozwiązuję problem z prawdopodobnie najmniejszym możliwym kodem, co zwykle prowadzi do ewidentnie niepotrzebnych zależności lub innych problemów projektowych. Następnie przekształcam działający kod w piękny kod.
Na przykład redukuję zależności między różnymi modułami do zwięzłych interfejsów i zastanawiam się, które dane powinny być przechowywane gdzie, dopóki każdy moduł nie będzie zależał tylko od bardzo minimalistycznych abstrakcji innych modułów. Można powiedzieć, że odkładam ostateczną decyzję, który moduł powinien ponosić odpowiedzialność. Odkładam abstrakcję.
Zbytnie zastanawianie się nad rozdzieleniem problemu na odrębne obowiązki, na wyraźne abstrakcje nie jest dobre. Zmusi cię do zgięcia swojej implementacji, aby pasowała do twoich abstrakcji. Kod działa, jeśli daje pożądane wyniki i można go utrzymać. Projekt działa, jeśli można go zaimplementować za pomocą dobrego kodu. Jeśli kod nie działa, możesz go zmienić. Ergo, jeśli projekt nie działa, musisz go również zmienić. Możesz zobaczyć, czy projekt działa, po jego wdrożeniu.

Tak więc, mając na uwadze prosty szkic, wystarczy zaprojektować go, zanim zaczniesz go realizować. Przeprojektowanie, streszczenie i refaktoryzacja w razie potrzeby .

back2dos
źródło
1

Myślę, że jeśli zamierzasz być dobry w programowaniu, przynajmniej czasami musi to być zabawa, a to oznacza bycie kreatywnym.

Z pewnością przy programowaniu w grupach obowiązują przynajmniej minimalne standardy, których należy przestrzegać, nie ze względów „moralnych”, ale ze względów praktycznych, gdy mają zastosowanie.

Poza tym ciekawie i przyjemnie jest zbadać granice, aby zobaczyć, co można tam znaleźć. Pewnego razu, pracując nad językiem asemblera Mini, odkryłem, że można tworzyć procedury, które można przełączać z jednej instrukcji na drugą. Potem wymyśliłem, jak stworzyć samoorganizację, która mogłaby iść dwa kroki do przodu, jeden krok do tyłu itp. Czy było to przydatne? Wątpię. Nie o to chodzi.

Kiedyś usłyszałem przemówienie Edsgera Dijkstry mówiące o kreatywności w programowaniu. Wspomniał, w jaki sposób uczeń znalazł sposób na n-bitowe obracanie słowa n + m-bit. Dokonano tego za pomocą 3 bitów. Najpierw zamieniasz n bitów, następnie zamieniasz m bitów, a następnie zamieniasz całe n + m bitów. Przydatny? Nie. Sprytny? Tak.

Dobrze jest wypróbować rzeczy, których nikt przy zdrowych zmysłach nie zrobiłby.

Mike Dunlavey
źródło
1

Może to być przypadek „jeden rozmiar nie pasuje do wszystkich”. Sprawiłeś, że Twój styl działa w projektach, w których byłeś, więc kto się z tym kłóci? Jednak krytycy, których czytasz tutaj i na temat SO, mogą pracować nad większymi projektami lub nad projektami, które wymagają złożonej koordynacji między członkami zespołu.

Twój styl programowania może stać się problemem, jeśli kiedykolwiek byłeś zaangażowany w większe projekty wymagające współpracy wielu programistów. Trudno to zaplanować, trudno jest śledzić swoje postępy i inni programiści nie mogą zaplanować części swojej pracy, która zależy od wiedzy, co robi.

Być może zainteresuje Cię czytanie Dreaming in Code, aby zobaczyć, co może się stać, gdy duży projekt przyjmie styl programowania podobny do twojego.

Charles E. Grant
źródło
1
Dziękuję za odpowiedź. Twoje komentarze są dla mnie pomocne.
Brad
1

Zapewniam, że twoja metoda nie jest zła, ale pozwól, że dodam trochę osobistych doświadczeń. Zacząłem od twojej drogi, ale tymczasem nauczyłem się korzyści z planowania z wyprzedzeniem przynajmniej części ogólnej struktury, a to z kilku powodów:

  • największą zaletą jest to, że łatwiej jest zobaczyć, który kod może być ponownie użyty, jeśli nieco go obejdzie. Często piszę fragment kodu, który podczas pisania wydaje się nagle przydatny w innej części ogólnego schematu, który zawiesiłem obok mojego ekranu (narysowanego na papierze w stylu tylko dla mnie czytelnym).

  • Posiadanie schematu pozwala refaktoryzować nie tylko kod, ale również schemat. Czasami jestem zajęty pisaniem lekcji, która nagle wydaje się przydatna również w innych aspektach programu. W rezultacie schemat staje się prostszy, gdy projekt jest kontynuowany

  • Za każdym razem aktualizuję ten schemat o wymagane dane wejściowe i dane wyjściowe funkcji / metod oraz dostępne gniazda w klasach. Jest to szybsze w przypadku ponownego wykorzystywania bitów: nie muszę za każdym razem nurkować w kodzie, aby sprawdzić, co dokładnie wchodzi i wychodzi. Nawet jeśli jest to w komentarzach, wciąż muszę przeglądać, aby uzyskać komentarze

Więc właściwie używam również twojej metody. Po prostu zaczynam, wypróbowuję, refaktoryzuję, próbuję ponownie, zmieniam kolejny bit i tak dalej, ale mój cykl obejmuje również schemat. A kiedy to zrobię, dodaję informacje o następnej, która działa na tym kodzie.

Pamiętaj, że dotyczy to projektów, nad którymi pracuję sam. Jeśli pracujesz z większą liczbą osób na tym samym kodzie, planowanie z wyprzedzeniem jest nie tylko logiką, ale także koniecznością. Ale chyba już to wiesz.

I jak powiedzieli inni: to moja droga, twój przebieg może się różnić.

Joris Meys
źródło