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

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.

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.

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.

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.

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ę!

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.

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 ”.

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”.

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.

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.

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.

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.

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 .

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.

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.

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ć.