Jak wytrenować się, aby uniknąć pisania „sprytnego” kodu? [Zamknięte]

75

Znasz to uczucie, kiedy po prostu trzeba pokazać, że nowy trik ze Expressions lub generalizować trzy różne procedury? Nie musi to być w skali Astronauta architektury i faktycznie może być pomocne, ale nie mogę nie zauważyć, że ktoś inny zaimplementowałby tę samą klasę lub pakiet w bardziej przejrzysty, prosty (a czasem nudny) sposób.

Zauważyłem, że często projektuję programy, rozwiązując problem , czasem celowo, a czasem z nudów. W obu przypadkach zazwyczaj szczerze wierzę, że moje rozwiązanie jest krystalicznie czyste i eleganckie, dopóki nie zobaczę dowodów przeciwnych, ale zwykle jest za późno. Jest też część mnie, która woli nieudokumentowane założenia od powielania kodu, a spryt od prostoty.

Co mogę zrobić, aby oprzeć się pokusie napisania „sprytnego” kodu i kiedy powinien zadzwonić dzwonek, że robię to źle ?

Problem staje się jeszcze bardziej pchający, ponieważ teraz pracuję z zespołem doświadczonych programistów, a czasami moje próby pisania inteligentnego kodu wydają mi się głupie nawet dla siebie po pewnym czasie, które rozpraszają iluzję elegancji.

Dan
źródło
5
trochę off topic, ale thedailywtf.com/Articles/...
@Joe: to bardzo temat, dzięki! Przeczytałem ten artykuł, ale teraz z przyjemnością go odkrywam.
Dan
33
Debuguj dużo sprytnego kodu ... to powinno załatwić sprawę.
Dan Olson,
@Joe baza danych linków do baz danych w tym artykule ma umrzeć.
jnewman
Krótka odpowiedź: wygrywa najkrótszy, najprostszy kod. Wyeliminuj duplikację, ale nie dodawaj warstw „tylko dlatego”. Refaktoryzacja Fowlera może dać ci wgląd.
kevin cline

Odpowiedzi:

54

Problem staje się jeszcze bardziej pchający, ponieważ teraz pracuję z zespołem doświadczonych programistów, a czasami moje próby pisania inteligentnego kodu wydają mi się głupie nawet dla siebie po pewnym czasie, które rozpraszają iluzję elegancji.

Twoje rozwiązanie leży tutaj. Zakładam, że „doświadczony” w tym kontekście oznacza „bardziej doświadczony niż ty”. Przynajmniej ich szanujesz. Jest to cenna okazja do nauki - zakładając, że twoje ego może przyjąć trafienie. (Irytujące rzeczy, ego. Szkoda, że ​​ich potrzebujemy.)

Czy masz recenzje kodu z tymi ludźmi? Jeśli tak, jeśli jeszcze tego nie robią, wyraźnie poproś ich, aby zadzwonili do ciebie z powodu bzdur. Wspomnij, że zauważyłeś w sobie tendencję do przeprojektowywania, używania skrupulatnie zaprojektowanego pneumatycznego młota pneumatycznego (najlepiej dzierżonego przez pewnego rodzaju zautomatyzowanego androida pracującego na drodze), gdy prosty młot pazurowy byłby więcej niż wystarczający .

Często możesz się wiercić na swoim miejscu, a twarz zmienia kolor na czerwony podczas przeglądów kodu. Znieść to. Uczysz się.

Następnie, gdy masz już kilka z nich za paskiem, zwróć uwagę na momenty, w których podejrzewasz, że być może przesadzasz. Kiedy nadejdą te chwile, zadaj sobie pytanie: „Jeśli ktoś woła mnie o to podczas przeglądu kodu, czy mogę bronić mojego rozwiązania jako najlepszego z dostępnych?

Czasami wzajemna ocena jest najlepszym sposobem, aby dobrze przyjrzeć się własnej pracy.

BlairHippo
źródło
Dzięki za naprawdę dobrą odpowiedź. Nie, nie mamy recenzji kodu, głównie dlatego, że projekt jest duży, a zasoby klienta są bardzo ograniczone. Ale chyba mogę się sprawdzić, pytając „czy mogę bronić swojego rozwiązania jako najlepszego z dostępnych” na koniec każdego dnia.
Dan
7
Brak recenzji kodu? Urk. Pisałbym coś całkowicie samolubnego i przerażonego, ale pracowałem również w tym środowisku. Są czasochłonne i stanowią rodzaj bólu dla każdego, ale naprawdę są cenne zarówno dla projektu, jak i dla twojego rozwoju osobistego. Jeśli temat „Może powinniśmy robić recenzje kodu?” zawsze pojawia się, upewnij się, że jesteś na dole jako „Piekło tak!” A jeśli nie zostaną zatłoczeni własnymi zbliżającymi się terminami, możesz poprosić współpracowników, których szanujesz, o wykonanie pracy, której nie masz pewności co do nieformalnego przeglądu kodu.
BlairHippo
1
Cóż, projekt jest swego rodzaju start-upem i ze względu na pewne błędy w planowaniu, również po stronie klienta, trafiliśmy w sytuację, gdy naprawdę musimy szybko dostarczyć lub inaczej nie jest to warte wysiłku. Właśnie rozmawiałem z naszym premierem, który potwierdził, że agresywny termin jest jedynym powodem, dla którego nie robimy recenzji kodu, przynajmniej teraz. Jeśli uruchomienie zakończy się sukcesem, a ograniczenia czasowe staną się bardziej zrelaksowane, być może będziemy przeprowadzać recenzje w przyszłości.
Dan
2
O mój. Brzmi ekscytująco - ze wszystkimi dobrymi i złymi konotacjami, które niesie ze sobą słowo. :-) Powodzenia, kolego; mam nadzieję, że jesteś na początku czegoś wspaniałego.
BlairHippo
8
@BlairHippo: Po prostu zastosowałem się do twojej rady, uspokoiłem się i uprzejmie poprosiłem kolegę, który wskazał na problem wprowadzony przez moje zmiany, o dokonanie ze mną nieformalnych recenzji, a on zgodził się. Pomogło to również usunąć pewną niezręczność z naszej rozmowy (jak w „piszesz złożony kod i muszę go naprawić…”). Dzięki!
Dan
20

Najlepiej jest pamiętać o maksymie Briana Kernighana:

„Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod tak sprytnie, jak to możliwe, z definicji nie jesteś wystarczająco inteligentny, aby go debugować. ”

Daniel Roseman
źródło
1
Z całego serca zgadzam się z cytatem, ale pytanie brzmi, jak pokonać pokusę bycia sprytnym chłopcem ? Możesz zostać poproszony, aby nie jeść lodów, gdy jesteś chory, ale czasami to nie pomaga.
Dan
13
+1 za maksymę, którą każda małpa kodowa powinna znać na pamięć, ale -1 za nie oferowanie OP żadnego wglądu, jak zastosować ją do własnej pracy. Wszystko to wyrównuje się do braku klikania strzałki.
BlairHippo
2
Świetny cytat, ale tak naprawdę nie jest odpowiedzią na pytanie PO.
Jim G.,
5
Cześć Daniel, szukamy czegoś więcej niż cytatu: strona jest przydatna tylko wtedy, gdy pytania są zestawiane z długimi, przemyślanymi odpowiedziami wypełnionymi doświadczeniami, faktami i referencjami. Czy możesz dodać coś jeszcze z własnego doświadczenia?
2
-1: W najmniejszym stopniu nie odpowiada na pytanie PO.
Thomas Eding,
15

Zazwyczaj istnieją co najmniej trzy rozwiązania problemów oprogramowania o dowolnym znaczeniu: oczywisty sposób, nieoczywisty złożony sposób (sprytny) i nieoczywisty prosty sposób (elegancki). Cytat na temat autorów ma zastosowanie tutaj:

Odłóż wszystko, co przychodzi ci do głowy, a potem jesteś pisarzem. Ale autor jest tym, który bez litości może oceniać własne rzeczy i niszczyć większość z nich. - Colette

Nie będziesz w stanie pisać eleganckiego kodu, dopóki nie będziesz w stanie ocenić wartości własnego kodu, bez litości, i zniszczyć większość z nich. Jeśli ocenisz elegancki kod na podstawie wyniku końcowego, wygląda on na zwodniczo łatwy, ale wymaga spowolnienia, przejścia przez wiele szkiców, szukania porady innych i wyjaśniania, co nie jest właściwe na stronie. Oznacza to, że nawet jeśli Twój kod działa idealnie, pytasz siebie lub kolegę, dlaczego coś jest nie tak, dopóki nie będziesz zadowolony z odpowiedzi. Może wydaje się zbyt długi lub powtarzalny, albo uważasz, że kompilator powinien był w stanie wykryć pewien rodzaj błędu. Większość programistów z odrobiną doświadczenia może łatwo rozpoznać nieelegancki kod. Sztuką jest dowiedzieć się, dlaczego .

To metodyczny sposób pisania bardziej eleganckiego kodu. Często wymaga również błyskawicznego wglądu, który pomaga spojrzeć na problem w nowy sposób. Jest to trudniejsze do osiągnięcia, ale pomaga zwolnić i po prostu pomyśleć o problemie przed zanurzeniem się w kodowaniu. Kiedy znajdziesz dobre rozwiązanie, poszukaj lepszego. Czytanie innego kodu pomaga. Pomaga lekcje lub czytanie książek o najlepszych praktykach. Nauka innych paradygmatów programowania pomaga. Pomaga ci poprosić o radę kolegów, których kod podziwiasz.

Karl Bielefeldt
źródło
3
To przypomina mi cytat starego matematyka: „Dla każdego problemu istnieje rozwiązanie, które jest proste, eleganckie i złe”.
Joris Timmermans
9

Dodałbym do istniejących odpowiedzi, rozwijał się w sposób TDD, więc najpierw piszesz testy o tym, co powinien zrobić twój kod, a następnie implementujesz, aby twoje testy stały się zielone. W ten sposób spełnisz tylko wymagania nałożone przez testy. Ponieważ będziesz pisać test, jest to dobry sposób na zdyscyplinowane podejście do rozwoju.

Matteo Mosca
źródło
Zdecydowanie staram się narzucić to sobie, kiedy tylko jest na to czas.
jnewman
Późniejsze pisanie testów jest również dobrym sposobem na wykrycie poważnych błędów w kodzie. Jest to jakoś samoocena. Ale TDD jest zdecydowanie najlepszym podejściem, jeśli zaczynasz od nowa.
vanna
6

Pracując dla dużego i dynamicznego zespołu, który obejmuje wiele różnych zestawów umiejętności i lat, rozwój ma naturalny postęp, aby zostać „stępionym” do najniższego poziomu najbardziej konserwatywnego lub najbardziej upośledzonego intelektualnie członka zespołu, obecnego lub historycznego.

Nie musi to być złą rzeczą, ponieważ sprytny kod może być trudniejszy do debugowania, trudniejszy do przekazania w specyfikacji technicznej i zajmuje więcej czasu na pisanie, co spowalnia czas programowania.

Są chwile, kiedy sprytny kod jest ważny, na przykład gdy sprytny kod zapewnia wzrost wydajności i wydajności później w cyklu dojrzałości oprogramowania, gdy wydajność staje się wymogiem.

Sprytny kod umożliwia także szybsze opracowanie i bardziej czytelny i zrozumiały kod dla zespołu, który może nie być narażony na nową funkcję języka lub wywołanie biblioteki. Na przykład, kiedy po raz pierwszy przedstawiłem Linqowi młodszego programistę, od razu poczułem wstręt do niego jako niepotrzebnego, trudnego do debugowania, głupiego i „sprytnego”. Po tym, jak sam się z tym bawiłem i odkryłem, jak przydatne i potężne mogą być zapytania Linq, zainwestowałem czas, aby się tego nauczyć, a mój kod DAL nigdy nie był tak czysty i czytelny, jak również łatwiejszy do debugowania i rozszerzania.

Żałuję, że wcześniej nie miałem otwartego umysłu i żałuję, że nie byłbym tak surowy wobec tak „sprytnego” młodszego programisty.

Chodzi mi o to, że „sprytny” kod MUSI BYĆ podejrzany, ale nie powinniśmy prowadzić przeciwko nim krucjaty, ponieważ może to stłumić kreatywność i innowacje.

EDYCJA: Właśnie zdałem sobie sprawę, że nie w pełni odpowiedziałem na twoje pytanie. Jeśli masz w swoim projekcie zdolność do bardzo łatwego pisania sprytnego kodu, być może zespół powinien przyjąć bardziej rygorystyczne standardy kodowania, aby zachować jednolity i wyraźny szablon i styl. Pomoże to narysować linie piaskownicy, abyś nie wychodził na ulicę w pogoni za piłką.

wałek klonowy
źródło
6

Jeśli 20% (twój% może się różnić) lub więcej z dodanych linii musi być dokumentacją - czas cofnąć się i przemyśleć .

Naprawdę uważam, że powinieneś starać się być sprytnym, to naturalny efekt uboczny zdobywania większej biegłości. Udzielenie sobie ogólnych wskazówek, takich jak% komentarzy potrzebnych do wyjaśnienia, jest dobrym sposobem zmuszenia się do wycofania się i oceny, czy korzystanie z tej nowej rzeczy, której się nauczyłeś, jest mądrym wyborem, czy tylko sposobem na pochwalenie się nową zabawką.

DKnight
źródło
3
Dokumenty / komentarze traktuję jako niepowodzenie. Kiedy musisz coś udokumentować / skomentować, oznacza to przede wszystkim, że Twój kod jest niejasny. Niestety, jest to nierealny cel i w pewnym momencie potrzebujemy dokumentacji. Pamiętaj tylko, że ta część kodu powinna zostać zredukowana do minimum.
deadalnix
@deadalnix: Niezły punkt. Podejrzewam, że mój% byłby wyższy niż większość, ponieważ zwykle piszę w języku asemblera, który w przeciwnym razie byłby martwy i zawierał makra. Trudniej czytać, a każdy nowy najemca musi uczyć się języka, w związku z czym konieczne jest więcej komentarzy.
DKnight
2
@deadalnix - dokumentacja wyjaśniająca, w jaki sposób znak jest niejasny w kodzie. Dokumentacja wyjaśniająca, dlaczego jest bardzo potrzebna. Widziałem zbyt wiele fragmentów kodu, że mogłem zrozumieć, co zrobili, ale nie wiem, dlaczego zdecydowali się zrobić to w nieintuicyjny sposób. To bardzo utrudnia utrzymanie.
HLGEM,
@HLGEM Jest to dyskusyjne. Niejasność kodu może wynikać z źle zaprojektowanego libs / API, z niejasności w samej koncepcji, jak złe rozdzielenie problemów. Żyjemy w prawdziwym świecie, a nasze możliwości są skończone, więc definitywnie potrzebujemy dokumentacji, ale za każdym razem, gdy jej potrzebujemy, oznacza to, że ktoś napisał niedoskonały kod. Żadna dokumentacja nie jest czymś, co powinieneś robić - nawet o tym nie myśl, ale czymś, o czym trzeba cały czas myśleć, aby ciągle poprawiać się we właściwym kierunku.
deadalnix
@deadalnix - idealny kod nigdy nie jest praktycznym rozwiązaniem w prawdziwym świecie.
JeffO
4

Nie mogę się oprzeć próbie czegoś sprytnego.

Robię to w projekcie zabawkowym, w swoim własnym czasie, w domu.

Kiedy nowość się kończy - problem rozwiązany.

Mike Dunlavey
źródło
3

Uważam, że jednym ze sposobów sprawdzenia, czy kod jest zbyt „sprytny”, jest cofnięcie się i zadawanie sobie następujących pytań:

Gdybym miał wydrukować ten kod komuś, kto nigdy nie pracował nad tym projektem / kodem, czy byłby w stanie go przeczytać i opisać mi, co robi funkcja (po podaniu im krótkiego kontekstu)? Jeśli nie, ile muszę wyjaśnić? Jak wytłumaczyłbym to komuś biorącemu CS101?

Jeśli okaże się, że będziesz musiał przeprowadzić kogoś przez każdą linię lub większość linii w metodzie lub klasie, jest to prawdopodobnie zbyt sprytne. Jeśli musisz wyjaśnić konstrukcje językowe (na przykład LINQ) komuś, kto go nie zna, prawdopodobnie jest to w porządku. Jeśli musisz rzucić okiem na linię i zastanowić się przez chwilę, zanim będziesz w stanie ją wyjaśnić, Twój kod musi zostać ponownie przetworzony.

Becuzz
źródło
Słyszałem, że nazywa się to „Rubber Ducking”, gdy stosuje się je do rozwiązywania problemów; kiedy jest zakłopotany, spróbuj wyjaśnić problem komuś, kto nic o tym nie wie (jak wiesz, twoje gumowe kaczątko) i sprawdź, czy rozwiązanie nie spadnie na twoje kolana. Muszę myśleć, że to też zadziała.
BlairHippo,
2

1) Najpierw się nim spal, żebyście wiedzieli, że to coś złego. Próba debugowania czegoś, co napisano sprytnie, to świetna zabawa. Myślę, że to masz.
2) Skomentuj swój kod, wyjaśnij, co robisz przed każdą sekcją kodu.
3) Jeśli masz problem z wyjaśnieniem tego lub czujesz potrzebę wstawienia diagramu, to co właśnie zrobiłeś, jest zbyt sprytne i prawdopodobnie można to zrobić w bardziej czysty sposób.

Sprytne rozwiązania problemów mogą być fantastyczne, dopóki nie trzeba ich debugować ani rozszerzać. Czasami jest to jedyne rozwiązanie. Jeśli potrafisz dokładnie opisać, co on do cholery robi i jak to robi, sprytne rozwiązania mogą być akceptowane.

Zazwyczaj komentuję, aby opisać, co robię z sekcją kodu. Jeśli wydaje się to najmniej mylące, opisuję również, jak to robię. Najlepiej byłoby, gdyby kod był prosty i zrozumiały. Ale jeśli mam trudności z wyjaśnieniem, jak zrobiłem to, co właśnie zrobiłem, to jest to wyraźny znak, że muszę się wycofać i spróbować ponownie.

Philip
źródło
2
Sztuczka komentowania też działa dla mnie. Wśród innych powodów zawsze umieszczam blok komentarza nad wszelkimi trywialnymi podprogramami jako rodzaj ostatecznej kontroli poczytalności. Jeśli muszę dużo wyjaśniać (lub nawet czasami przepraszać) zawiłe lub rozwarte sekcje kodu lub dziwne parametry wejściowe lub cokolwiek innego, to znak ostrzegawczy, że może potrzebuję trochę przemyśleć rozwiązanie.
BlairHippo,
@BlairHippo HA! „ostateczna kontrola poczytalności” Podoba mi się.
Philip
2

Prawdopodobnie dobrym sposobem na rozpoczęcie pisania prostego kodu jest uwolnienie pasji sprytowej w projekcie, który wymaga sprytu . Reszta odpowiedzi jest specyficzna dla .NET, ale jestem pewien, że można znaleźć projekty o podobnym poziomie w dowolnym innym języku.

Istnieją frameworki do wstrzykiwania zależności typu open source, nad którymi po prostu prosi się o Expressionwiedzę na temat sztuczek, jest F # i wspaniały zakres zadań, które można chcieć wypróbować.

Jeśli interesujesz się matematyką (i to bez względu na język ), masz dla ciebie Project Euler .

Wreszcie, w świecie .NET istnieje Mono Project, który ma wiele obszarów, które wymagają uwagi programistów , niektóre z nich są dość skomplikowane. Co powiesz na wkład w narzędzie do analizy statycznego kodu .NET typu open source ? W grę wchodzi analiza IL, a także rzeczy na wysokim poziomie. Jb Evain zawsze działa na czymś interesującym, niezależnie od tego, czy jest to biblioteka refleksyjna Cecil, Expressionwsparcie czy dekompilator .NET.

Jeśli nic nie pasuje, po prostu uruchom własną kpinę :-)

Dan
źródło
2

Czy znasz to uczucie, gdy musisz po prostu pokazać nową sztuczkę za pomocą wyrażeń lub uogólnić trzy różne procedury?

Nie

Jest to jeden z powodów, dla których zawsze mówię, że dobrze jest, gdy nowi programiści rzucają się w wielki bałagan nieudokumentowanego kodu speghetti w celu utrzymania i refaktoryzacji. Nauczy ich realiów utrzymywania zbyt „sprytnego” kodu, którego nie napisali, i mam nadzieję, że zaszczepi trochę empatii dla biednego szmucka, który będzie musiał debugować swój kod za 5 lat.

Grandmaster B.
źródło
Myślę, że jest to bardziej prawdopodobne, że będą sfrustrowani i sądzę, że ICH kod będzie znacznie lepszy i elegancki niż noobowie, którzy napisali TEN bałagan. Nikt nie pisze kodu z zamiarem utrudnienia jego utrzymania.
sara,
2

Myślę, że temat jest dobrze wybrany. „Fajnie” jest napisać wiersz Perla, który robi dziesięć tysięcy rzeczy naraz, ale potem jest do kitu, gdy trzeba go ponownie odwiedzić.

Z innej notatki, sprytnej czy nie, kod musi być udokumentowany. Istnieje nieodłączna niedopasowanie impedancji między akceptowanymi w branży językami programowania a wysokopoziomowymi koncepcjami, do których my, ludzie, jesteśmy przyzwyczajeni w naszym myśleniu. Kod samodokumentujący jest po prostu niemożliwy do zrealizowania - dopóki nie stanie się językiem naturalnym. Nawet kod Prolog wymaga udokumentowania, ponieważ niezależnie od tego, jak wysoki jest poziom, nadal jest dość formalny.

Drobnoziarnisty kod imperatywny służy do wdrażania gruboziarnistych planów - co należy udokumentować. Nie chcę czytać wszystkich 50 wierszy metody, gdy zrobi to szybki 3-liniowy komentarz do mapy drogowej.

Późniejsza edycja: bardziej wymownym przykładem jest ten, który wykracza poza komputery. Książka może być bardzo dobrze napisana, ale często chcemy ją przetwarzać na różnych poziomach abstrakcji. Często wystarczy podsumowanie książki i to właśnie komentarze mogą zaoferować kodowi. Oczywiście dobrze wyodrębniony kod może znacznie przyczynić się do samodzielnej dokumentacji, ale nie może zapewnić wszystkich poziomów abstrakcji.

Komentarze mogą również zachowywać się jak sidenotes w książce, gdy musimy wyjaśnić proces uzasadnienia roszczenia w tekście głównym bez wykolejenia go.

W tym kontekście uważam, że moje wcześniejsze stwierdzenie odnoszące się do języka naturalnego wykraczającego poza potrzebę komentarzy jest nieprawidłowe. Nawet język naturalny, tak jak w książce, może nadawać się do dokumentacji, aby wyjaśnić w rzadki sposób abstrakcję zawartą w tekście lub zapewnić objazdy bez wykolejenia głównego tekstu. Uwaga: dobrze wyodrębniony kod mógł już przejść długą drogę w kierunku samodokumentowania.

Wreszcie, komentarze mogą pomóc koderowi utrzymać wysoki poziom abstrakcji. Często zdaję sobie sprawę, że dwa kolejne komentarze, które zamieściłem na liście kroków, nie mówią na tym samym poziomie abstrakcji, co natychmiast gwarantuje krytyczne spojrzenie na to, co robię z tym kodem.

Niektóre problemy wykraczają poza kodowanie i wpływają na kodowanie, podobnie jak inne czynności. Komentarze mogą pomóc w wyjaśnieniu uzasadnienia i aspektów naszego kodu, i uważam je za miłego towarzysza, który mówi łagodniejszym językiem, aby przynieść korzyść osobie dla odmiany.

Mihai Danila
źródło
1

W jaki sposób? Pokazuj swój kod doświadczonym programistom. a kiedy zostaniesz przeklęty za to, że jesteś sofistyczny i efektowny, wyssij go i zapytaj, jak by to zrobili i dlaczego (w sposób niekonfrontacyjny).

Edytuj w świetle -1:

Wiele księżyców temu znajdowałem się w tej samej sytuacji - miałem jednego szefa, który kuliłby się za każdym razem, gdy użyłem wskaźnika w Delfach lub „z konstrukcją”, innego, który groził, że mnie zwolni, jeśli nie przestanę zwierać wszystkich moich booleanów 0-1 i wszędzie używane zmienne jednoliterowe.

Nauczyłem się, bo zapytałem dlaczego, a oni zadali sobie trud wyjaśnienia, ponieważ myśleli, że mogę do czegoś dojść - LOL ....

Mikey
źródło
1
Cześć Mikey, szukamy czegoś więcej niż jednej linijki: strona jest przydatna tylko wtedy, gdy pytania są zestawiane z długimi, przemyślanymi odpowiedziami wypełnionymi doświadczeniami, faktami i referencjami. Czy możesz dodać coś jeszcze z własnego doświadczenia?
1

Czy czuję potrzebę popisywania się? Nie, już nie. Jak sobie z tym poradziłem? Jak większość ludzi przeżywa jakikolwiek inny zły nawyk ... świadome i celowe ćwiczenie właściwych technik. Zrobisz to wystarczająco, aby zrozumieć wartość najlepszych praktyk, a poprzez ich ciągłe stosowanie rozwiniesz dobre nawyki.

Uświadom sobie również, że skupiając się na funkcjonalnym oprogramowaniu, które jest terminowe i łatwe w utrzymaniu, zyskasz uznanie, którego szukasz. Przybędą do Ciebie doświadczeni programiści i powiedzą: „Ten moduł, który napisałeś, był dobrze zaprojektowany. Musiałem zaimplementować tylko jeden komponent, aby podłączyć go do mojego projektu”. w przeciwieństwie do „Musiałem przerobić cały moduł, który napisałeś, aby użyć go w innym komponencie? Czy słyszałeś nawet o Bobie Martinie lub Wardzie Cunninghama?”

TLDR: Nie jesteś sam. Uznanie umiejętności najlepiej osiągnąć jako produkt uboczny rozwiązywania problemów w inteligentny sposób.

Heath Lilley
źródło
0

Dla mnie zbyt sprytny kod często stara się rozwiązać wyobrażone przyszłe wymagania zamiast skupiać się na dzisiejszych wymaganiach. Wielka pułapka!

0% nadmiernie skomplikowanego kodu nie jest osiągalnym celem. Może nawet nie najlepszym celem do osiągnięcia. Zbyt skomplikowany kod jest zły, ale musisz próbować nowych rzeczy, aby rozwijać się jako programista. Nie powinieneś wypróbowywać ich na kodzie produkcyjnym, jeśli możesz tego uniknąć. W przeciwieństwie do maszyn ludzie popełniają błędy.

Pomoc w recenzowaniu kodu. Pomaga nam spędzanie lat na ustalaniu „sprytnego” kodu innych ludzi. Koncentracja na tym, czego naprawdę potrzebuje dzisiaj klient, pomaga.

Szkoły i firmy zatrudniają załogi personelu sprzątającego i konserwującego personel. Kod także wymaga czyszczenia i konserwacji! Jeśli to możliwe, posprzątaj bałagan (szczególnie twój własny)! Myślę, że to najlepsze, co można zrobić.

GlenPeterson
źródło
-2

Oprócz dobrych porad udzielonych do tej pory (przegląd kodu, debugowanie, podejście TDD) należy od czasu do czasu czytać (najlepsze książki imho) na temat dobrych praktyk kodowania:

  • Pragmatyczny programista
  • Kod ukończony
  • Wyczyść kod

i inne, w zależności od używanej technologii.

m3th0dman
źródło
-2

Pamiętaj tylko YAGNI - Nie będziesz go potrzebował .

programista nie powinien dodawać funkcjonalności, dopóki nie zostanie to uznane za konieczne ...

YAGNI jest zasadą stojącą za praktyką XP polegającą na „robieniu najprostszej rzeczy, która mogłaby ewentualnie działać” (DTSTTCPW). Jest przeznaczony do stosowania w połączeniu z kilkoma innymi praktykami, takimi jak ciągłe refaktoryzowanie, ciągłe automatyczne testy jednostkowe i ciągła integracja. Zastosowanie bez ciągłego refaktoryzacji może prowadzić do bałaganu i ogromnej przeróbki ...

Według tych, którzy opowiadają się za podejściem YAGNI, pokusa pisania kodu, który w tej chwili nie jest konieczny, ale może być w przyszłości, ma następujące wady:

  • Czas poświęcony jest na dodawanie, testowanie lub ulepszanie niezbędnej funkcjonalności.
  • Nowe funkcje muszą być debugowane, dokumentowane i obsługiwane.
  • Każda nowa funkcja nakłada ograniczenia na to, co można zrobić w przyszłości, więc niepotrzebna funkcja może uniemożliwić dodanie potrzebnych funkcji w przyszłości.
  • Dopóki ta funkcja nie jest faktycznie potrzebna, trudno jest w pełni zdefiniować, co powinna zrobić i przetestować. Jeśli nowa funkcja nie zostanie poprawnie zdefiniowana i przetestowana, może nie działać poprawnie, nawet jeśli w końcu będzie potrzebna.
  • Prowadzi to do wzdęcia kodu; oprogramowanie staje się większe i bardziej skomplikowane.
  • Jeśli nie ma specyfikacji i kontroli wersji, funkcja ta może nie być znana programistom, którzy mogliby z niej skorzystać.
  • Dodanie nowej funkcji może sugerować inne nowe funkcje. Jeśli te nowe funkcje również zostaną zaimplementowane, może to spowodować efekt kuli śnieżnej w kierunku pełzania funkcji ...
komara
źródło
3
Chociaż może to być prawda - więcej szczegółów sprawi, że będzie to znacznie lepsza odpowiedź.
ChrisF