Zauważyłem ostatnio wiele pytań związanych z różnymi technikami abstrakcyjnymi, a odpowiedzi mówią w zasadzie, że techniki te są „zbyt sprytne”. Sądzę, że częścią naszej pracy jako programisty jest ustalenie najlepszych rozwiązań problemów, które mamy rozwiązać, a spryt jest w tym pomocny.

Moje pytanie brzmi zatem: czy ludzie, którzy uważają, że pewne techniki abstrakcji są zbyt sprytne, w przeciwieństwie do sprytów per se , czy jest jakiś inny powód do sprzeciwu?

EDYCJA: Ten kombinator parsera jest przykładem tego, co uważam za sprytny kod. Pobrałem to i przeglądałem przez około pół godziny. Następnie przeszedłem przez makropolecenie na papierze i zobaczyłem światło. Teraz, kiedy to rozumiem, wydaje się on znacznie bardziej elegancki niż kombinator parsera Haskell.

Proste rozwiązania są lepsze do długoterminowej konserwacji. I nie zawsze chodzi tylko o znajomość języka. Złożona linia (lub linie) wymaga czasu, aby ją zrozumieć, nawet jeśli jesteś ekspertem w danym języku. Otwierasz plik i zaczynasz czytać: „ok, proste, proste, rozumiem, tak, WTF ?!” Twój mózg zatrzymuje się z piskiem, a teraz musisz zatrzymać się i rozszyfrować skomplikowaną linię. O ile nie istniał wymierny, konkretny powód tego wdrożenia, jest on „zbyt sprytny”.

Zrozumienie, co się dzieje, staje się coraz trudniejsze, gdy złożoność rośnie od sprytnej metody do sprytnej klasy i sprytnego wzorca. Oprócz dobrze znanych podejść musisz wymyślić proces myślowy, który doprowadził do stworzenia „sprytnego” rozwiązania, które może być dość trudne.

To powiedziawszy, nienawidzę unikać wzorca (gdy jego użycie jest uzasadnione) tylko dlatego, że ktoś może go nie zrozumieć. Jako programiści powinniśmy się uczyć, a jeśli czegoś nie rozumiemy, to jest powód, aby się tego uczyć, a nie tego unikać.

Zasada KISS

Niech to będzie możliwie proste. Sprytne rozwiązania są świetne, ale często najprostsze proste rozwiązanie jest najlepsze.

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

Brian Kernighan

Głupcy ignorują złożoność; pragmatycy cierpią; eksperci tego unikają; geniusze go usuwają. - Alan Perlis

Najlepsze rozwiązanie nie zawsze jest najmądrzejszym rozwiązaniem. Czasami proste rozwiązania są równie dobre.

W oprogramowaniu zawsze musisz myśleć w kategoriach łatwości konserwacji. Jeśli fragment kodu jest zbyt sprytny dla kogoś, kto go zachowa, powiedziałbym, że spryt nie jest tego wart.

Cytując 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ć. ”

spryt jest narzędziem; sam w sobie nie jest szkodliwy. Staje się szkodliwy tylko w kontekście, w którym nie jest to konieczne.

„Sprytny”, kiedy jest zastosowany do kodu, prawie zawsze jest tylko eufemizmem dla „niepotrzebnie skomplikowanego”.

Czytanie dobrego, przejrzystego, prostego kodu jest wystarczająco trudne. Czytanie „sprytnego” kodu jest jak ponowne studiowanie poezji łacińskiej.

Zamieszanie powstaje, ponieważ „sprytny” jako atrybut osoby ma zupełnie inne znaczenie. Ten przypadek można również traktować jako przykład, dlaczego projektowanie oprogramowania dla prawdziwych ludzi jest trudne: ponieważ są one niejednoznaczne.

A ponieważ niektórzy programiści cierpią na zrozumienie protokołów społecznych przestrzeganych przez większość ludzi, które zabraniają im bezpośredniego potępiania kodu jako „niepotrzebnie skomplikowanego”, może być im trudno rozróżnić dwa znaczenia słowa sprytne . W przeciwieństwie do tego, co niektórzy mogą myśleć, myślę, że ostatecznie lepsi „ludzie ludzie” (czyli ludzie, którzy mają empatię, introspekcję i cierpliwość) są lepszymi programistami. Ponieważ wiedzą, dla kogo pisać.

Większość ludzi koncentruje się na sprytności z aspektu „Kod wymaga zbyt dużego rozszyfrowania, aby zrozumieć, co robi” i wszystkich złych rzeczy, które się z tym wiążą, takich jak

1. Nikt inny nie może tego rozgryźć, nie mówiąc już o utrzymaniu go / debugowaniu.
2. Osoba, która napisała, nawet nie wie, co robi.
3. Na początek może nie być aż tak genialne
4. itp....

Wszystkie dobre punkty, ale jest jeszcze jeden negatywny aspekt sprytu i jest to problem starego ego. Powoduje to problemy podobne do

1. Ktoś, kto jest zbyt „inteligentny”, aby korzystać z rozwiązań innych osób. Po co sprawdzać, co zrobili inni ludzie, kiedy możesz wymyślić własny sposób na skórowanie tego samego kota?
2. Ktoś, kto myśli, że wynalazł najfajniejsze rozwiązanie problemu, często odmawia przyjęcia jakichkolwiek informacji.
3. Nie pozwolę nikomu modyfikować „swojego” kodu, nawet jeśli występują oczywiste problemy lub konieczna jest trywialna zmiana.
4. Wręcz przeciwnie, uważają, że są inteligentni i muszą użyć „najnowszej” techniki, aby udowodnić, jak są inteligentni, ale nie potrafią sobie z tym poradzić ani w osobistych projektach, ani w innych kodach nieprodukcyjnych, zanim przełożą go na krytyczne części system.

Wszyscy czasami jesteśmy winni zbyt dużego ego, ale kiedy przeszkadza zespołowi, stanowi problem.

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

Muszę się zastanawiać, czy wszyscy są sprytni.

Osobiście czuję się jak bystry, kiedy podjąłem trudny, złożony problem i wdrożyłem go w bardzo prosty i bezpośredni sposób, zachowując akceptowalny poziom wydajności.

tl; dr czuję się sprytnie, gdy podczas przeglądu kodu mój recenzent mówi „wow, to było łatwiejsze niż myślałem, że będzie”, w przeciwieństwie do „wtf to wszystko…”

Oprócz wymienionych odpowiedzi teoretycznych, często wykorzystuje się to w kontekście zbyt sprytnego dla wszystkich innych.

Poruszaj się czasem między zespołem pracującym na najwyższym poziomie i zespołem serwisowym średniego poziomu, aby zobaczyć rzeczywiste różnice w tym, co jest „zbyt sprytne”.

Pomijając argumenty teoretyczne, zbyt sprytny często opiera się na tym, z czym najmniej wykwalifikowani członkowie zespołu mogą rozsądnie pracować, więc jest bardzo zależny od środowiska.

Czasami byłem tak sprytny, że się myliłem.

Wydajne, łatwe w utrzymaniu, terminowe i tanie to sposoby, w jakie mierzę rozwiązanie. Wydaje mi się, że sprytny może być również częścią rozwiązania, o ile nie wpływa to negatywnie na te cechy.

Jeśli sprytny kod + ilość komentarzy wymaganych do uczynienia go zrozumiałym kodem <= prosty kod, to mówię: idź po sprytny kod. Każdego razu.

Myślę, że problem pojawia się, gdy ludzie, którzy piszą „sprytny kod” celowo nie komentują go poprawnie, ponieważ tylko dlatego, że początkowo niezrozumiały, przyszłe pokolenia, które go napotkają, będą musiały spędzić czas na „docenieniu” jego sprytności.

Przypomina mi się cytat, który widziałem przypisany wielu różnym ludziom, ponieważ często są to dobre cytaty.

Parafrazować:

Każda inteligentna osoba może zrobić prosty kompleks, potrzeba geniuszu, aby ten kompleks był prosty.

Podjęcie złożonego pomysłu i uproszczenie go, aby było zrozumiałe, pokazuje spryt konstruktora, ale przyjęcie prostego pomysłu i uczynienie go złożonym pokazuje, że konstruktor chce być postrzegany jako sprytny.

Jeśli trudno jest znaleźć „sprytne” rozwiązanie, nie należy go stosować. Na przykład, jeśli dzięki efektom ubocznym możesz zawrzeć złożone obliczenia w jednej linii, jest to sprytne. Ale jeśli ktoś potrzebuje godziny, aby dowiedzieć się, co zrobiłeś na świecie, jest to zbyt sprytne.

Moim zdaniem spryt per se nie stanowi problemu. Zwykle możemy wprowadzać w błąd co do „sprytnego” (bez sarkazmu) i „wnikliwego” kodu. To, co postrzegam jako problem, to fakt, że zwykle „sprytny” (z sarkazmem) kod zawiera ukryte niewidoczne wymagania, co utrudnia debugowanie i utrzymanie go z czasem.

Istnieje kilka znanych algorytmów, które są sprytne. Quicksort to jeden, IMO.

Kod „Clever” (z sarkazmem) zwykle przyjmuje założenia o ustawianych zmiennych i stanach systemu, które są praktycznie odłączone od „sprytnego” kodu (gdy pliki otwierane wcześniej, połączenia sieciowe, bazy danych itp.).

Ilość danych, które musisz załadować do swojego mózgu, aby poprawnie utrzymać „sprytny” kod, jest zwykle zbyt duża, aby mieć dobry stosunek kosztów do korzyści.

„Sprytny kod” to dowolny kod, dla którego programista musiał naprawdę mocno się zastanowić lub użyć zaawansowanych umiejętności, aby go napisać. Problem polega na tym, że nie uwzględnia potrzeby pewnego „marginesu sprytu”, najlepiej wyrażonego przez Briana W. 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ć”.

Bo to, co wygląda jak spryt do dewelopera w przypływie kreatywności może po prostu przejść jak bałagan i po prostu być nieczytelny , unmaintainable blok niejasnych zagadek dla innych.

Mimo to, miły, sprytny, dobrze działający blok zagadek, ale jeśli masz doświadczenie, często zdajesz sobie sprawę, że utrzymanie Twojej firmy (nie ciebie, programisty) będzie znacznie droższe, aby utrzymać ją na średnim poziomie - lub długoterminowe. Więc wolisz uspokoić zapał innych programistów, kiedy zostaną uniesieni.

Oczywiście z wyjątkiem uzasadnienia sprytu. A jeśli jest dobra dokumentacja dołączona do zaciemnionej rzeczy, którą właśnie napisałeś. Skomentowałeś ten sprytny fragment kodu, prawda? Wyjaśnij, co jest intencją, dlaczego musi być i jak się zachowuje?

Jeśli nie ma uzasadnienia, to prawdopodobnie jest to albo przedwczesna optymalizacja, nadmierna inżynieria, albo problem YAGNI. Jeśli potrzeba 15 poziomów pośrednich, aby zrobić coś prostego, istnieje duża szansa, że ​​znajdziesz się w poprzednich kategoriach. A jeśli nie jest to udokumentowane, to tylko kłopoty.

Świetny kod nie powinien wymagać od opiekuna 100% przez cały czas, aby go zrozumieć. Dobry kod jest sprytny. Świetny kod może być prawie tak samo wydajny, ale lepszy w wielu innych aspektach. Świetny kod nie powinien wymagać IDE z 15 widokami do śledzenia projektu Twojej aplikacji.

Uwaga: hej, napisałem kilka rzeczy, które uważałem za sprytne, ale to narysowało WTF? z ust - jeśli nie moich współtwórców - ustach mojego menedżera. Muszę spojrzeć na to z ich perspektywy.

Zwykle jestem sprytny , ale staram się być elegancki .

Opracuj kod teraz, aby inni nie próbowali go później unikać .

Oto moje rozumienie problemu w oparciu o moje doświadczenie i inne odpowiedzi:

1. Kod, który sprytnie napisał, ale wydaje się czytelny i łatwy do utrzymania, nie jest uważany za szkodliwy. Jednak większość programistów nie nazwałaby tego rodzaju kodu „sprytnym”; mogą używać innego terminu, na przykład „elegancki”. Może istnieć debata na temat istnienia takiego kodu.
2. Kod produkcyjny, który wymaga znacznego czasu i wysiłku, aby zrozumieć nawet doświadczony programista obeznany z językiem, jest „sprytny” i uważany przez wszystkich za szkodliwy.
3. Kod produkcyjny, który wymaga znacznego czasu i wysiłku przez niedoświadczonych programistów, jest przez niektórych uważany za szkodliwy. Tak czy inaczej widziałem odpowiedzi i współpracowałem z programistami, którzy wyraźnie powiedzieli, że wolą zachować wszystko „najniższym wspólnym mianownikiem”.

Znam faceta; jest prawdopodobnie najbardziej błyskotliwą osobą, jaką kiedykolwiek spotkałem. Jest zdecydowanie niewiarygodnym programistą, prawdopodobnie lepszym niż kiedykolwiek w całym moim życiu pod względem czystego programowania. Pisze kod, jakby pisał dokument tekstowy, i może odwrócić listę, której nie uwierzyłbyś. Jeśli chcesz porozmawiać o napisaniu bardzo złożonego kodu, to on jest twoim mężczyzną i jeśli napotkam niewiarygodnie trudny problem, zawsze zwracam się do niego. Jednak praca z nim nad projektem w środowisku zespołowym jest ekscytująca. Nie jest w stanie bezpośrednio ukierunkować problemu biznesowego i zapewnić logicznego, wydajnego i zwięzłego rozwiązania tego problemu. Dla niego lista kodów 1000 linii byłaby lepsza niż 100. Zamiast korzystać z narzędzi dostarczonych mu za pośrednictwem IDE lub frameworka, uruchomi własne superoptymalizowane narzędzie.

Podziwiam jego zdolność do robienia tak skomplikowanych rzeczy, ale potrzebuję kogoś, kto może rozwiązać problem i przejść dalej. Nie jest wspaniale powiedzieć ani przyznać, ale czasami w otoczeniu biznesowym czas jest wszystkim i musisz po prostu rozwiązać problem i rozpocząć życie, zawsze możesz wrócić do niego później i zrezygnować z niego, aby poprawić Twój kod. Jest cienka granica między byciem sprytnym a byciem w tyłku. Moją dewizą dla mojego zespołu jest zawsze to, co jest najprostszą możliwą rzeczą, która zadziała w tej sytuacji, a następnie odejdzie. Czasami prostsze nie zawsze jest odpowiedzią, ale jest to cholernie dobre miejsce na rozpoczęcie.

„Sprytny” w tym kontekście oznacza „zbyt sprytny dla własnego dobra”, tj. Coś, co działa teraz, ale będzie koszmarem do zrozumienia i zmiany w późniejszym czasie.

Zwłaszcza jeśli jest to sztuczka, która wykorzystuje niejasną funkcję języka programowania lub wykorzystuje dziwne efekty uboczne lub jest naprawdę dziwnym sposobem rozwiązania problemu w języku docelowym.

Wolę proste rozwiązania, bardzo podoba mi się rubinowy sposób. Gdy chcesz na przykład zsumować pierwsze 2 elementy z listy. najpierw wycinasz listę, aby miała rozmiar = 2, a następnie sumujesz.

Pamiętam, że kiedyś użyłem 1 listy zamiast 3 i stworzyłem jedną dużą funkcję, którą bardzo trudno było utrzymać / zmienić.

w dzisiejszym świecie nie musimy poświęcać przejrzystości kodu dla wydajności (z wyjątkiem c ++, nie muszą, ale będą).

Zwykle, gdy trzeba być „sprytnym”, można obejść problem z kodem. Jeśli jest to obejście i nie jest to bardzo proste, wówczas przy założeniu pewnych warunków otrzymasz wiele zdezorientowanych twarzy lub innych dziwnych efektów ubocznych (które mogą być w 100% poprawne w momencie pisania kodu)

Tak sprytne == mylące == złe :( Ale jest też niesamowite, ponieważ użyłem ich do praktycznych rozwiązań ograniczonych problemów.

Ponowne cytowanie w kontekście i łatwiejsze zrozumienie:

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

To, co napisał tutaj Brian Kernighan, oczywiście odnosi się do splotu i błędnie użył słowa sprytnie.

„Debugowanie jest przede wszystkim dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod w możliwie najbardziej skomplikowany sposób, z definicji nie jesteś wystarczająco inteligentny, aby go debugować”.

Skręt:

A thing that is complex and difficult to follow.

Sprytny:

Showing intelligence or skill; ingenious

Wykształceni programiści wiedzą, że prosty kod jest genialny. Kod, który jest tak sprytny, jak to tylko możliwe, powinien być z definicji prosty. Wykształceni programiści będą również unikać pracy i pisania skomplikowanego kodu, takiego jak plaga. Zamieniają również skręcony kod w sprytny kod, gdy tylko mają taką możliwość. Kod zwykle zaczyna się od zawiłości i zbliża się do sprytu, ponieważ wiedza na temat dziedziny i rozumienie ludzkich zdolności poznawczych w programowaniu jest lepiej rozumiana poprzez doświadczenie i wspólną wiedzę.

Ze względu na popularność tego cytatu i fakt, że Brian Kernighan jest dość popularny w branży, to niewłaściwe użycie tego słowa ma negatywny wpływ na społeczeństwo i szczerze chciałbym, aby to rozwiązał sam mężczyzna. Przed napisaniem tego artykułu starałem się sprawdzić, czy mogę po prostu wysłać mu wiadomość e-mail, ale nie mogłem znaleźć żadnych informacji kontaktowych, które rozumiem :(.

Negatywny wpływ społeczny, jaki widziałem, to inni programiści ostracalizujący swoich sprytniejszych rówieśników, ponieważ postrzegają spryt jako problem. Prawdziwym problemem są głupi rówieśnicy, którzy myślą, że są sprytni, robiąc rzeczy w nowy, jednodiomatyczny sposób, i stale wymyślają nowe rzeczy, gdy nie ma korzyści, zamiast zdobywać i rozumieć większą społeczność i jak najlepiej wykorzystywać sprytne pomysły.

Muszę jednak wyjaśnić, że często uzyskanie zrozumienia jest trudniejsze niż wymyślenie własnego. Ze względu na powszechny w branży problem nierealistycznych terminów, wymyślenie własnego dla mniejszej niszy pozwoli zaoszczędzić czas. Opiera się to na spostrzeżeniu, że użyteczne rzeczy wielokrotnego użytku zwykle są ukierunkowane na większą niszę lub stanowią przydatną abstrakcję dla wynalazku. Opiera się również na tym , że ludzie celują w duże nisze, aby zarobić więcej pieniędzy, co często sprawia, że ​​narzędzie jest niezwykle trudne w użyciu ze względu na złożoność związaną z tworzeniem czegoś użytecznego dla szerokiego zakresu zastosowań.

Innym negatywnym skutkiem społecznym jest to, że zapobiega postępowi i chęci zrozumienia, ponieważ w naszym egocentrycznym świecie natychmiast zaprzeczymy naszemu brakowi zrozumienia i skreślimy kodeks bycia zawiłym, nawet jeśli po zrozumieniu idea jest faktycznie całkiem sprytny.

DO ZROBIENIA Chciałbym zacytować niektóre referencje, ale chciałbym również, aby brak referencji nie utrudniał mojej zdolności do dzielenia się informacjami, więc szybko przytoczę to, co pamiętam jako źródła moich informacji i być może znajdę faktyczne informacje dzień (lub możesz to dla mnie znaleźć! :)

• Dyskusja Guido Van Rossuma na temat pętli wydarzeń i tego, jak je zrozumiał
• Pracownik GitHub, który stwierdził, że unikają zatrudniania mądrych ludzi na Y-Combinator
• Dużo dyskusji i nauki, które toczy się w społeczności Python. Społeczność Python jest szczególnie krytyczna wobec nowych pomysłów, ale nie odrzuca nowych pomysłów, których nie rozumieją z ręki, i zazwyczaj można zobaczyć funkcje, które początkowo były postrzegane jako zawiłe, ujrzeć światło dzienne jako podstawową funkcję / pakiet językowy.
• Moje własne doświadczenie i profesjonalna opinia oparte na moich 10000 obserwacjach stóp. Naprawdę nie widzę szczegółów, które należy oświecić z góry :( Mam nadzieję, że twoje doświadczenie i obserwacja powie ci to samo, a ktoś inny może komentować poniżej, aby dać tej odpowiedzi jakąś wartość.

Dodaj własne cytaty! Dodaj też przecinki do mojego tekstu. Od dłuższego czasu nie odświeżyłem swojej wiedzy na temat używania przecinków w języku angielskim ...

Ponieważ często ludzie nie znają języka, idiomów i wzorców. Mogli wziąć książkę i się jej nauczyć, ale nie robią tego. A przez te osoby powinieneś pisać prosty kod.

To nie jest spryt. To wiedza.

Nie mogłem znaleźć dyscypliny słowa nigdzie wspomniane tu, więc będę chip. Nie chcę, aby umieścić na odpowiedź, ale dzielić inną wiedzę na ten temat, może jeden, że oryginalne pytanie nie miał na myśli .

Sprytny programista to dobra rzecz.

Jednak przed sprytem pojawiają się inne cechy. Jak zapewne zauważyliście, będę mówić o dyscyplinie . Sprytny i niezdyscyplinowany programista może być bardzo zły dla długoterminowej łatwości konserwacji systemu.

Załóżmy, że pojawia się błąd lub pojawia się nowe wymaganie. Sprytny programista może wkrótce zrozumieć, że kilka lokalnych poprawek wykona zadanie w ciągu 2 minut. Jeśli ten programista zostanie zdyscyplinowany, powstrzyma się od stosowania tych poprawek do kodu źródłowego i zamiast tego znajdzie sensowny sposób na skomponowanie pożądanego zachowania w systemie. W ten sposób, następnym razem, gdy zajdzie potrzeba modyfikacji poszczególnych fragmentów kodu, opiekun będzie miał łatwy czas na zrozumienie kodu i wdrożenie nowych zmian bez przerywania czegokolwiek. Jeśli nie, to dostaniesz zdjęcie.