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.
źródło
Odpowiedzi:
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ć.
źródło
if FuncX() then return true, else return false
i 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. :-)Zasada KISS
Niech to będzie możliwie proste. Sprytne rozwiązania są świetne, ale często najprostsze proste rozwiązanie jest najlepsze.
Brian Kernighan
źródło
Głupcy ignorują złożoność; pragmatycy cierpią; eksperci tego unikają; geniusze go usuwają. - Alan Perlis
źródło
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.
źródło
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ć. ”
źródło
spryt jest narzędziem; sam w sobie nie jest szkodliwy. Staje się szkodliwy tylko w kontekście, w którym nie jest to konieczne.
źródło
„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ć.
źródło
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
Wszystkie dobre punkty, ale jest jeszcze jeden negatywny aspekt sprytu i jest to problem starego ego. Powoduje to problemy podobne do
Wszyscy czasami jesteśmy winni zbyt dużego ego, ale kiedy przeszkadza zespołowi, stanowi problem.
źródło
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”.
źródło
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…”
źródło
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.
źródło
Czasami byłem tak sprytny, że się myliłem.
źródło
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.
źródło
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.
źródło
Przypomina mi się cytat, który widziałem przypisany wielu różnym ludziom, ponieważ często są to dobre cytaty.
Parafrazować:
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.
źródło
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.
źródło
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.
źródło
„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ć”.
źródło
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.
źródło
Zwykle jestem sprytny , ale staram się być elegancki .
Opracuj kod teraz, aby inni nie próbowali go później unikać .
źródło
Oto moje rozumienie problemu w oparciu o moje doświadczenie i inne odpowiedzi:
źródło
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.
źródło
„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.
źródło
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ą).
źródło
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.
źródło
Ponowne cytowanie w kontekście i łatwiejsze zrozumienie:
To, co napisał tutaj Brian Kernighan, oczywiście odnosi się do splotu i błędnie użył słowa sprytnie.
Skręt:
Sprytny:
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źć! :)
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 ...
źródło
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.
źródło
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.
źródło