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

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.

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.

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

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.

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.

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

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

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.

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.

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.

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ę :-)

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.

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.

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

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.

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

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.

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