Dlaczego spryt jest uważany przez niektórych za szkodliwy w programowaniu?

89

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.

Larry Coleman
źródło
116
Myślę, że być może nie rozumiesz - spryt u danej osoby jest cnotą, ale spryt w systemie jest wadą. Systemy i kod nie powinny być sprytne, powinny być czyste jak kryształ. Często potrzeba mądrej osoby do stworzenia takich rzeczy.
nlawalker,
15
@nlawalker: Myślę, że teraz to rozumiem. Ludzie używają słowa „sprytny”, odnosząc się do kodu jako antonim dla „jasnego” lub „prostego”, ponieważ tak naprawdę chcą używać słowa, które jest antonimem dla „jasnego” lub „prostego”.
Larry Coleman,
2
@ Larry: Nie jestem pewien, co by to oznaczało. Sprytny jak w przypadku wynalazczości, oryginalności, pomysłowości i przez domniemanie, używając rzeczy w sposób, jakiego nigdy wcześniej nie widziałeś. Czasami jest świetny (wiele wzorów jest sprytnych), ale obcość rozwiązania może również utrudnić pracę.
doppelgreener
2
Czy nikt już nie komentuje? Tutaj wyjaśnisz spryt, aby ci, którzy pójdą za nim, mogli zrozumieć. Jak ty za 6 miesięcy.
Phil Lello,

Odpowiedzi:

207

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

Anna Lear
źródło
7
+1 Ładnie powiedziane. Myślę, że to kwestia równowagi. Jeśli mogę spodziewać się, że ktoś z dużą ilością wiedzy zrozumie kod przy odrobinie myślenia o sobie, możesz sprytnie i być może dodać komentarz. Jeśli zrozumienie kodu zajmuje cztery razy więcej czasu tylko dlatego, że ktoś chciał udowodnić swoje umiejętności kodowania - nie! Jeśli ktoś jest wystarczająco inteligentny, aby wymyślić sprytne rozwiązanie, powinien być wystarczająco inteligentny, aby zdecydować, czy jest to zrozumiałe, czy nie. W przeciwnym razie po prostu się popisuje.
Anne Schuessler,
Ostatni akapit lubię. Reszta jest prawdziwa, ale niefortunna.
Orbling
Wygląda na to, że widziałeś kod źródłowy Zend PHP :)
Tim Post
+1 Prosty wzorzec może nie działać tak dobrze, jak sprytny wzorzec i, jak powiedzieliście, to my, programiści, powinniśmy dalej przesuwać granice „sprytnego”, rozumiejąc go.
Stephen Furlani,
3
Jako ktoś, kto musiał usprawiedliwić robienie czegoś „sprytnego”, gdy było to naprawdę „minimalnie, ortogonalnie poprawne”, chciałbym dodać, że istnieje pewna subiektywność w kwestii tego, co dokładnie jest sprytne. Na przykład niektóre osoby zawsze będą chciały pisać if FuncX() then return true, else return falsei nigdy nie będą chciały, abyś tylko pisał return FuncX(). Nie żartuję, dosłownie miałem tę rozmowę. Ponieważ ludzie chcą gdzieś zawiesić swoje punkty przerwania lub coś takiego. :-)
Warren P
102

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

Josh K.
źródło
8
Z drugiej strony, jeśli piszesz kod tak sprytnie, jak potrafisz, musisz nauczyć się go debugować, dzięki czemu stajesz się bardziej sprytny. Czy coś takiego.
James McNellis,
11
@James: Albo po prostu się nie udaje. ;)
Josh K
10
@Josh K: Zawsze znałem KISS jako „Keep Simple, Głupi!” - en.wikipedia.org/wiki/KISS_principle
Orbling
1
@Orbling: Przypomniałem sobie inaczej, no cóż, teraz już wiem.
Josh K
1
„Czy to proste i głupie” , zgodnie z Wikipedią ? :) Czy to oznacza, że prostota jest głupia, czy że dla uproszczenia musisz być głupia ? : P
Mateen Ulhaq,
83

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

Martijn Verburg
źródło
5
+1 za miły cytat i za pierwszą odpowiedź bez domyślnego założenia, że ​​coś nie może być zarówno proste, jak i sprytne
Larry Coleman
15
Ważne jest to, że to programista powinien być sprytny, a nie kod.
Kristopher Johnson
O wiele lepiej zacytować niż idiota niewłaściwie używający słowa sprytnie w sprytny sposób.
Derek Litz
30

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.

Maniak
źródło
3
Proste rozwiązanie złożonego problemu jest tak sprytne, jak to tylko możliwe.
JeffO,
chociaż zawsze istnieje zastrzeżenie, którego nie chcesz nadmiernie upraszczać tylko dlatego, że opiekun nie może kodować (ani czytać).
Ken Henderson,
@confusedGeek - ale jeśli wiesz, że programista serwisowy nie jest w stanie sobie z tym poradzić, to sprytne rozwiązanie staje się bombą zegarową. Ważna jest tutaj równowaga - dotyczy to tylko osób, które znają zespół obsługi technicznej. Jeśli nie masz pojęcia, to najlepszą rzeczą jest bycie sprytnym.
Michael Kohne,
1
@Michael, ograniczenia wydajności mogą wymagać, aby Twój kod był sprytny. Obowiązkiem opiekuna jest uczyć się, a jeśli nie może, zatrudnić nowych opiekunów.
Stephen Furlani,
@Stephen, jeśli kod POTRZEBUJE być sprytny, programista powinien dołożyć wszelkich starań, aby wyjaśnić DLACZEGO musi być, aby opiekun nie musiał zaczynać od zera.
26

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

peterchen
źródło
„... Chyba że użyłeś poprawnej definicji sprytnego, a kod jest w rzeczywistości prosty do zrozumienia i debugowania”.
Derek Litz
To chyba zależy od tego, który słownik Ci się podoba. Z mojego doświadczenia wynika, że ​​każdy „sprytny” kod - łatwy do poprawienia lub nie - nadal wykorzystuje szczęśliwą kombinację w specyfikacji. Nawet jeśli jest to oczywiste, należy zaznaczyć, czy takie założenie może się zmienić i nie powinno przeciekać do różnych części kodu.
peterchen
Masz rację, ale chciałbym dodać zastrzeżenie, że zależy to od tego, jak łatwy jest język i implementacja do odczytania i zrozumienia, a twoje komentarze mogą być po prostu szumem kodu zamiast czegoś pomocnego. I chociaż powszechne jest używanie sprytnego oznaczania jego przeciwieństwa, powinniśmy starać się być bardziej klarownym, aby inni nie mogli błędnie interpretować rzeczy dla własnej korzyści.
Derek Litz
Bez sprzeciwu :)
peterchen
22

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

Steven A. Lowe
źródło
16

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

fzwo
źródło
5
Głosowałbym za tym, gdybyście nie głosili kazań na temat protokołów społecznych i „ludzi, osób [sic]”.
Jason Baker,
2
W porządku - i dziękuję za przypomnienie. Mam tendencję do zbyt głoszenia kazań. Ale jestem wkurzony zirytowany przez (wielu?) Niezdolność programistów i / lub niechęć do radzenia sobie ze zwykłymi ludzkimi zachowaniami oraz ogólny brak empatii i introspekcji, które widzę w naszej dziedzinie. Może powinienem był wstawiać „osoby osoby” w cudzysłowie zamiast kursywą. Angielski nie jest moim pierwszym językiem, po prostu nie wiedziałem, jak dojść do wniosku, że aby być świetnym programistą, musisz zrozumieć nie tylko kod, ale także ludzi. MOIM ZDANIEM.
fzwo
Edytowałem moją odpowiedź. Czysta / mniej obraźliwa teraz?
fzwo
+1 za pierwsze zdanie, które właściwie wyciągnąłem po otrzymaniu pierwszych kilku odpowiedzi.
Larry Coleman
Tak, dziękuję za wyjaśnienie, w jaki sposób głupi ludzie używają sprytnych ludzi w tym kontekście!
Derek Litz
9

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.

MIA
źródło
8

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
Interesująca odpowiedź, ale czy kod, który nazywasz „Bad Clever”, jest faktycznie nazywany „pięknym” itp. Przez kogokolwiek innego niż osobę, która napisała dany kod?
Larry Coleman
2
Zależy. W Objective-C / C ++ / C zjawisko to zwykle ogranicza się do pojedynczej osoby. W Perlu i Ruby często cała społeczność ma wspólną wartość dotyczącą tego, że Bad Clever jest „piękny”, „elegancki” itp.
użytkownik8865,
1
@ user8865: również kod „Good Clever” jest znacznie łatwiejszy do debugowania niż oryginał, ponieważ z definicji jest o 3 rzędy wielkości mniejszy.
Larry Coleman
2
Ach, więc programy w Perlu są - teraz prawie z definicji - wyjątkowo dobre Clever :) Miło wiedzieć!
7

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

Avatar_Squadron
źródło
1
LOL o tl; dr, jak myślisz, jak wolno programiści czytają? Tak, absolutnie nienawidzę niewłaściwego użycia sprytnego tutaj, aby oznaczać przeciwieństwo tego, co w rzeczywistości jest. Dumni / Ignorant / Evil programiści i menedżerowie faktycznie wykorzystują to, aby usprawiedliwić brak zatrudnienia kogoś, kto ich zdaniem może być „zbyt inteligentny”.
Derek Litz
6

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.

Rachunek
źródło
Znakomity: „zbyt sprytny często opiera się na tym, z czym najmniej wykwalifikowani członkowie zespołu mogą współpracować w rozsądny sposób”
Orbling
w zależności od Twojej lokalizacji jest to czasem nieco mniej niż „doskonałe” :-)
Bill
Kogo obchodzi najmniej wykwalifikowany członek zespołu? Prawie każdy zespół (choć jestem pewien, że jest kilka wyjątków) ma co najmniej jednego członka, który absolutnie nie ma biznesu, nazywając go programistą.
dsimcha
1
Mamy nadzieję, że sprawisz, że będą lepsi, ale nawet jeśli to się nie powiedzie, nadal musisz poradzić sobie z nimi jako członek zespołu i muszą oni być w stanie wziąć udział w niektórych pracach. Obecnie widzę to w wyrażeniach lambda. Wiele osób, z którymi pracuję, jeszcze ich nie rozumie, więc uważają ich za zbyt sprytnych. Jest to niefortunne, ponieważ rozwiązują wiele naszych problemów dość skutecznie i elegancko, ale jeśli żaden z nich nie dostanie ich, przejdą do zarządzania, ponieważ oprogramowanie nie jest obsługiwane.
Bill
@Bill: Funkcje Lambda ??? Każdy, kto nie jest w stanie zrozumieć czegoś tak prostego, nawet po wyraźnym poproszeniu o zapoznanie się z nimi, nie powinien być profesjonalnym programistą.
dsimcha
6

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

Jan
źródło
1
To może się zdarzyć. A czasami coś jest tak nie tak, to dobrze.
bobobobo
Nazywają te teorie Janem. Teorie mogą i powinny być błędne raz na jakiś czas :), nie oznacza to, że powinniśmy przestać być sprytni i dążyć do bycia tak sprytnymi, jak to możliwe. Jak inaczej zostaniemy liderami na tym świecie! „Ach, ale zasięg człowieka powinien przekraczać jego zasięg - a po co jest niebo?”
Derek Litz
4

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.

Heath Lilley
źródło
+1 za użycie „taniego” jako pozytywu w odniesieniu do rozwoju
Gary Rowe
Widziałem zbyt wiele „sprytnych” kodów, które nie są wydajne!
HLGEM,
Są bardziej wartościowe wskaźniki, ale mogą być dobre, w zależności od projektu, i często są ze sobą sprzeczne, więc aby odnieść sukces, musisz podkreślać jeden nad drugim.
Derek Litz
3

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.

thesunneversets
źródło
Cóż, albo dlatego, że po prostu nie myślą o następnym facecie, czy coś takiego. Nie jestem pewien, czy przypisałbym egoizmowi intelektualnemu, co można odpowiednio wytłumaczyć bezmyślnym lenistwem i złym nawykiem. Ale faktem jest, że jeśli twój kod nie może być zrozumiany na pierwszy rzut oka, potrzebuje komentarzy, a jeśli kod + komentarze jest dłuższy (w LOC lub czasie) niż w inny sposób, pracujesz ciężej niż trzeba.
Dan Ray
Dobra odpowiedź (nie można dać +1, nikt nie został, później). Jeśli ludzie nie spędzają czasu na pisaniu sprytnego kodu, a inni nie spędzają czasu na jego zrozumieniu, preferują mniej skomplikowany prosty kod, nawet jeśli jest mniej wydajny. Wówczas nie nastąpi żaden rozwój umiejętności.
Orbling
Najlepsza odpowiedź. Mantra: napisz prostą linię bazową, kod startowy, który jest braindead i powolny, gdy wszyscy wstają ... a następnie zrób komentarz, gdy sprowadzisz go do nieczytelnego jednowierszowego. W ten sposób uczysz się wszystkich brudnych sztuczek w swoim języku!
Droogans,
Jeśli uważam, że używasz sprytnego, by oznaczać zawiłego, osobiście napisałem trochę skomplikowanego kodu, który stał się zrozumiały dzięki logowaniu. Chociaż nie planowałem pisać zawiłego kodu, wtedy zaoszczędziłem trochę czasu, ale dodałem # TODO, że prawdopodobnie powinien być przepisany, aby był prosty, jeśli musimy go znacznie zmodyfikować.
Derek Litz
3

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.

Pickle Pumper
źródło
Tak, to egocentryczny pomysł chęci bycia sprytnym sprawia, że ​​twoja baza kodu jest skomplikowana. Jesteś albo nie jesteś mądry. Niestety, na początkowych etapach uczenia się ludzie myślą, że są mądrzejsi niż oni. Później zdają sobie sprawę, że nie są sprytni, i tak naprawdę piszą sprytny kod, gdy wypełniają luki w wiedzy.
Derek Litz
2

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.

Michael K.
źródło
2
W porządku, ale czy twoja odpowiedź się zmieni, jeśli osoba, która nie jest w stanie zrozumieć kodu, nie zna wszystkich funkcji języka?
Larry Coleman,
2
To jest inne, przynajmniej IMO. Jeśli dana osoba nie zna funkcji języka, nie jest w stanie ocenić, co jest mądre, czy nie.
Joe D
@ Larry: Niekoniecznie. Zakładam, że osoba czytająca jest na poziomie podstawowym / niskim zaawansowanym. A jeśli zacznie się tworzyć niemożliwy do odzyskania kompleks, nadszedł czas, aby wstawić komentarz blokowy wyjaśniający, co powinien zrobić kod, co pomoże ustalić ramy odniesienia dla zrozumienia, co faktycznie robi. Komentarz powinien być jednak na wysokim poziomie - wypisz obliczenia, wyjaśnij proces; nie powtarzaj kodu. Osoba w powinna (najlepiej) być w stanie zrozumieć kod podczas jego czytania. W każdym razie taki jest cel.
Michael K,
2

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.

Machado
źródło
1

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

Alex
źródło
1

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.

Haylem
źródło
Dziękuję za odpowiedź. Wygląda na to, że zgadzasz się z innymi, którzy twierdzą, że „sprytny” nie oznacza tego, co myślałem, że to zrobiło.
Larry Coleman
1

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

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

kevpie
źródło
1
Chodź ... sprytny jest synonimem elegancji, twój mózg został wprowadzony na rynek. Tak, wymyśliłem to słowo, oznacza to, że marketing ma wpływ marketingu zamiast prawdy.
Derek Litz
Elegancki: prosty i sprytny. @DerekLitz +1 za cromulent cokolwiek.
kevpie
1

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”.
Larry Coleman
źródło
Wydaje mi się, że cała współczesna kultura zachodnia to LCD. niedobrze.
Orbling
@Orbling: Tak, ale nie zapomnij o natychmiastowej satysfakcji.
Larry Coleman
Lubię twoje punkty doświadczenia. To smutne, że ludzie nie dążą do iteracyjnej poprawy i inwestują w siebie nawzajem, dzieląc się wiedzą i zrozumieniem. Zamiast tego wolą, abyśmy byli zębami na kole, abyśmy mogli łatwo je wymienić, gdy nadejdzie czas. W ten sposób hamujemy postęp. Sprzedajemy się również krótko ...
Derek Litz
1

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.

Nodey The Node Guy
źródło
Niestety, pomimo jakości tej osoby, którą spotkałeś, aby móc kodować skomplikowane rzeczy, jest głupi. Ludzie mogą być i są głupi, niezależnie od innych cech. Twoje stwierdzenia o tym, czego naprawdę chcesz od rozwoju, są oczywiste dla utalentowanej osoby. Jeśli jest naprawdę inteligentny, powinieneś wyświadczyć mu przysługę i skonfrontować go zamiast pozwolić, by robił głupie rzeczy swoim talentem. Wyrządzacie mu krzywdę i wszystkim dookoła, pozostając bezczynnymi i narzekając za jego plecami. Jeśli nie jest inteligentny, powinieneś go zwolnić, może to dostanie.
Derek Litz
Mam związek z podstawowym zasobem, który codziennie zajmuje się inteligentnymi ludźmi od dziesięcioleci, a niektórym z nich brakuje tylko kilku informacji, aby być produktywnym w środowisku zespołowym. Mogą to rozwiązać samodzielnie, jeśli przynajmniej powiesz im o problemie.
Derek Litz
1

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

Andres F.
źródło
0

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

IAdapter
źródło
0

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.

użytkownik2528
źródło
0

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

Derek Litz
źródło
-1

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.

Abyx
źródło
2
Z pewnością się z tym nie zgadzam (choć nie jest to warte -1). Za pomocą tego argumentu można powiedzieć, że nie zaimplementujesz wzorca poleceń do obsługi stosu transakcji Cofnij / Ponów, ponieważ opiekunowie byli świeżo po szkole i nie rozumieli, co się dzieje. W pewnym momencie musisz po prostu powiedzieć, że jeśli nie wiedzą, muszą się tego nauczyć.
Ken Henderson
@confusedGeek Całkiem słusznie, gdzie wyznaczasz linię ignorancji?
Orbling
@Orbling, szczerze mówiąc, to najtrudniejsza część i do pewnego stopnia zależy od sytuacji. Ogólny przewodnik, którego zwykle używam, to jest, jeśli rozsądny programista (posiadający wiedzę na temat zastosowanych technologii) może go omoknąć, to prawdopodobnie jest w porządku. Jeśli nie mogą, należy to zmienić (lub przejrzeć praktyki zatrudniania).
Ken Henderson
@confusedGeek Aye, brzmi rozsądnie. Test lakmusowy jest prawdopodobnie, czy deweloper tego samego kalibru jak ty łatwo zrozumie, co zrobiłeś wystarczająco szybko. Jeśli nie i istnieje łatwiejszy sposób, należy go zmienić. Czasami nie ma prostszego sposobu.
Orbling
-1. Nie koduj najniższego wspólnego mianownika. Niepotrzebna złożoność jest zła, ale jeśli pewna spryt sprawi, że kod będzie znacznie bardziej SUCHY itp., Może warto.
dsimcha
-1

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.

dkateros
źródło
„Bicie potrwa, dopóki Morale się nie poprawi”
komnata
@gnat Znaczenie? Aby trochę wyjaśnić; Nie uważam dyscypliny za wymuszanie na programistach. To dobra cecha osobowości. Ten, który jest zwykle rozwijany przez inteligentnych ludzi po pewnym czasie utrzymywania oprogramowania. Problem pojawia się w przypadku sprytnych ludzi, którzy nie byli wystarczająco na stanowisku opiekuna i zostawiają wszędzie sprytne bomby, aby inni mogli je znaleźć.
dkateros