Czy programiści czasami celowo nadmiernie komplikują kod? [Zamknięte]

26

Wydaje się, że wiele razy przy przepełnieniu stosu ludzie (szczególnie programiści) mają tendencję do nadmiernego komplikowania rozwiązania problemu, w którym rozwiązanie jest znacznie bardziej skomplikowane niż pierwotny problem? W żadnym wypadku nie jestem ekspertem, ale czasami próbuję zastosować najprostsze rozwiązanie, które działa (i oczywiście to NIE działa WSZĘDZIE), ale udało mi się zasugerować proste rozwiązania w pracy, które wydają się ludziom przeoczyć DUŻO bardziej skomplikowanych rozwiązań?

Czy to jest coś normalnego dla programistów ..... czy po prostu nie myślę we właściwej perspektywie.

6791
źródło
5
1. Tak, czasami myślę. 2. Tak, przynajmniej niektórzy programiści przynajmniej przez pewien czas nadmiernie komplikują kod, przynajmniej czasami celowo. 3. Sprawy zamknięte.
Job
3
Czy kiedykolwiek ktoś krzyczał na ciebie „Powinieneś o tym pomyśleć!” kiedy przegapiłeś jakieś wymaganie, które nie zostało określone podczas wstępnego gromadzenia wymagań? To może doprowadzić do tego, że niektóre rzeczy będą bardziej złożone niż to konieczne.
JB King

Odpowiedzi:

18

Oczywiście niektórzy programiści chętnie pokazują, jak są sprytni, tworząc skandalicznie skomplikowany kod, którego nikt nie rozumie. Inni programiści strzelają na tak wysokim poziomie, że skomplikowanie rozwiązań jest naturalną ewolucją.

Jednym z najgorszych kodów, jakie kiedykolwiek widziałem, była metoda zawierająca ponad 2000 linii kodu. Bez wątpienia ten kod był złożony, ale także bardzo słaby.

Myślę, że dobry programista unika zbyt skomplikowanego kodu. Obejmuje to unikanie pokusy, aby zmusić wzór projektowy do dopasowania do rozwiązania, które tak naprawdę go nie wymaga. Obejmuje to także unikanie obiektów Boga, magicznych przycisków, przedwczesnej optymalizacji, przedwczesnego uogólnienia i innych anty-wzorów.

Ciągle refaktoryzuję i szukam możliwości uproszczenia moich rozwiązań, ponieważ wzrost złożoności jest sprawą organiczną. Podobnie jak wiele innych rzeczy organicznych, musi być przycinany i przycinany, jeśli chcemy, aby nadal był użyteczny. Nienawidzę konieczności interakcji z nadmiernie skomplikowanymi rozwiązaniami, ponieważ wraz ze wzrostem złożoności rośnie prawdopodobieństwo złamania kodu.

Myślę, że czytelność jest najważniejszym elementem konserwacji kodu, a zbyt skomplikowane rozwiązania prawie zawsze zmniejszają czytelność i zwiększają koszty utrzymania.

Tim Claason
źródło
32

Widziałem dużo kodu, który był bardziej złożony, niż musiał być i prawie zawsze z tych trzech powodów:

1) Przeprojektowane z powodu przedwczesnego uogólnienia lub próby przewidywania przyszłych potrzeb, które nigdy nie powstały

2) Deweloperzy chcieli nauczyć się / eksperymentować z nowym wzorcem projektowym lub technologią, z której nie korzystali wcześniej, i opracowali go nawet wtedy, gdy było to przesadne. Robią to, ponieważ dzięki temu ich praca jest ciekawsza i uczą się czegoś nowego.

3) Dodano funkcje i poprawki błędów, ale istniejący kod nie był wówczas poprawnie refaktoryzowany. Może to być tylko niewielki fragment lub powielenie innego argumentu flagi na metodzie, ale wszystko się sumuje. W efekcie hacki są dodawane i nie trzeba długo czekać, aż wszystko stanie się nadmiernie skomplikowane z powodu wszystkich zapachów kodu. Jest to najczęstsze i zwykle z powodu braku wiedzy lub presji czasu.

Alb
źródło
Obawiam się, że jestem winny # 2. Z doświadczeniem (i dojrzałością?) Teraz raczej się powstrzymuję ... i zamiast tego eksperymentuję w domu :)
Matthieu M.
Widzę, że ludzie robią 1 cały czas, w końcu tworzą 5 razy więcej pracy dla siebie
Ally
11

To absolutnie powszechna sprawa. Jak mówi większość książek, dobry programista wie, jak to zrobić. Po prostu zbyt łatwo jest skomplikować coś za pomocą nowej technologii lub „fajnego” frameworku, który właśnie znalazłeś, więc zaczynasz szukać sposobów korzystania z niej, zamiast myśleć z perspektywy problemów.

Jak powiedział Martin Fowler, ci, którzy uczą się nowej technologii, mają krótkoterminowy problem, w którym jej rozwiązania oparte na „technologii”.

Martin Blore
źródło
4
-1: Jak mówi większość książek, dobry programista umie to uprościć. - Masz absolutną rację co do tego. Ale potem zasugerowałeś, że nadużycie nowej technologii jest największą przyczyną nadmiernej komplikacji kodu. Mylisz się co do tego. Uwierz mi, istnieje wiele nadmiernie skomplikowanych kodów, które nie mają nic wspólnego z nadużywaniem nowych technologii.
Jim G.
Gdzie dokładnie zasugerowałem, że jest to „największa przyczyna nadmiernego komplikowania kodu”? Z pewnością jest to problem: „Hej, właśnie nauczyłem się wzoru X, do którego mogę się zastosować” - Patternitus. Naprawdę wkładasz mi słowa do ust, Jim.
Martin Blore,
4
„Stworzyłem ten list dłużej niż zwykle, tylko dlatego, że nie miałem czasu, aby go skrócić”. - Blaise Pascal Również tutaj ma zastosowanie. „Skomplikowane” jest często oznaką pośpiesznego, leniwego lub niekompetentnego kodowania.
Bill
@Bill Interesującą rzeczą jest to, że jest to dobry argument za bardziej złożonym kodem z biznesowego punktu widzenia - jeśli otrzymujesz stałą kwotę za wdrożenie czegoś i zajmuje to więcej czasu refaktoryzacja lub skrócenie go, chyba że możesz to zrobić dokładnie za pierwszym razem (kto może?) zasadniczo grozi kara za uczynienie już działającego kodu mniej skomplikowanym.
Michael
10

Nie sądzę, że jest to normalne dla wszystkich programistów, ale zdecydowanie widziałem, jak wielu programistów to robi.

Myślę, że niektórzy uważają, że niektórzy uważają, że tworzenie czegoś naprawdę prostego jest „zbyt łatwe” i że nie jest to dobra prezentacja ich umiejętności. Dlatego muszą stworzyć duże, złożone rozwiązanie, w którym można powiedzieć „patrz, co mogę zrobić!”, Nawet jeśli nie jest to najlepsze rozwiązanie dla danego problemu.

GSto
źródło
1
Tak na to patrzę. IE, jeśli jest to zbyt łatwe, nie warto używać?
@Mercfh Nie rozumiem widoku. Co łatwość rozwiązania ma wspólnego z jego skutecznością?
GSto
Komentowałem jego komentarz, mówiąc: „Tak, zgadzam się”, że programiści czasami myślą: „Och, jeśli to zbyt proste, to nie jest zbyt dobre”.
7

Widziałem, jak programiści często piszą kilka wierszy kodu, aby wykonać zadanie, o którym nie wiedzieli, że jest już wbudowane w język. Nie jest to celowe, ale z pewnością można temu zapobiec.

JD Isaacks
źródło
Widziałem programistów, którzy napisali pętlę dla każdej kopii łańcucha. Nigdy nie używał wywołania standardowej funkcji biblioteki. (Gorzej jest, że kopia platform została zoptymalizowana pod kątem odczytywania słów na raz.)
BillThor
7

To zależy od tego, co nazywacie „prostym”. Niektóre osoby postrzegają wysoce zreformowany kod jako bardziej „złożony”, ponieważ jest więcej kodu i więcej wykresów połączeń. Jednak ten kod jest bardziej „prosty”, ponieważ znacznie łatwiej jest wprowadzać zmiany.

Często stwierdzam, że duża funkcja wygląda na „prostą”, dopóki nie trzeba będzie wprowadzać zmian, a następnie szybko się komplikuje.

Innymi słowy, w wielu przypadkach prosty jest w oku patrzącego.

Erik Funkenbusch
źródło
2
+1: zbyt wielu programistów nie myśli o tym
Luca
5

Problem polega na tym, że albo nie widzisz wyraźnie prostych rozwiązań (w tym miejscu pojawiają się dyskusje z kolegami), albo zbyt wcześnie przesadzasz.

Innymi słowy, tworzysz proste pętle do zaawansowanych funkcji bibliotecznych, ponieważ uważasz , że i tak będziesz potrzebować do następnego projektu (z wyjątkiem tego, że nie będziesz w tej dokładnie formie). Rób to zbyt długo, a otrzymasz niezwykle złożoną aplikację z bardzo prostym rdzeniem.

Może się również okazać, że musisz mieć bardzo solidny kod, a cała ta odporność domyślnie czyni go złożonym. Jednak nie sądzę, że to twój problem.

użytkownik1249
źródło
4

W niektórych przypadkach może to być po prostu złożoność opracowania czystego / prostego rozwiązania.

Jest cytat, którego nie pamiętam ani nie stwierdzam, że idzie to w pojedynkę. Wiersz „Kod nie jest kompletny, gdy już napisałeś wszystko, co musisz napisać, ale uzupełnij dopiero, gdy nie masz już nic do usunięcia”

Brak jasności utrudni ludziom usunięcie całego nadmiaru.

Stephen Bailey
źródło
4
Kolejny istotny cytat brzmi: „napisałbym krótszy list, ale nie miałbym czasu”.
user16764
3
„Semble que la perfection soit atteinte non quand il n'y plus rien à ajouter, mais quand il n'y plus rien à retrancher.” („Wygląda na to, że doskonałości nie osiąga się, gdy nie ma nic więcej do dodania, ale kiedy nie ma nic więcej do usunięcia. ”) - francuski pilot, poeta i inżynier Antoine Marie Roger Vicomte de Saint-Exupéry, 1939 (z książki Terre des Hommes ( Wind, Sand and Stars )).
Jörg W Mittag
Dzięki, wygląda na to, że nigdy nie znałem prawdziwego pochodzenia :-) Fajnie.
Stephen Bailey,
3

Najlepsi inżynierowie potrafią podejmować naprawdę skomplikowane problemy i przekształcać je w łatwe do wdrożenia i łatwe do zrozumienia rozwiązania. Brzmi prosto, ale nie ma wielu takich inżynierów / programistów. W rzeczywistości nie ma wielu takich ludzi. W rzeczywistości większość ludzi robi dokładnie odwrotnie. Podejmują proste problemy i komplikują je nie do poznania. Spójrz tylko na naszych polityków na przykład ludzi, którym udaje się rozwiązać proste problemy i zmienić ich w totalny chaos. Programiści nie różnią się pod tym względem.

Maczać
źródło
3
Ojej! Właśnie miałem dać +1, ale potem zobaczyłem twoją analogię do polityki, a to w najlepszym razie słabe. // To prawda - w polityce jest dużo zaciemnienia, zmarnowanego ruchu, machania ręką i specjalnych zainteresowań, w wyniku czego rachunki mogą się komplikować. Ale nadmierne powikłanie jest produktem ubocznym zaciemnienia, zmarnowanego ruchu, machania ręką i szczególnych zainteresowań. Nie podstawowa przyczyna.
Jim G.
Bez względu na przyczynę, istnieją bardzo proste rozwiązania wielu problemów kraju, ale politycy decydują się uczynić je trudniejszymi niż potrzebują. Zakładamy, że dzieje się tak z powodu pieniędzy, władzy lub głosów, ale uważam również, że w dużej mierze dotyczy to możliwości. W takim przypadku moja analogia jest solidna.
Dunk
1
@JimG. Tak, zgadzam się z tobą ... wydaje mi się, że wiele problemów z rozwiązaniami politycznymi to politycy, którzy twierdzą, że istnieje łatwe (ich!) Rozwiązanie naprawdę skomplikowanego problemu, który tak naprawdę nie ma łatwego rozwiązania.
Michael
2

Osobiście nigdy nie próbowałem komplikować oprogramowania. Jednak skończyłem coś i pomyślałem „wow, to zbyt skomplikowane”, wróciłem do tego i zrekonstruowałem. Niektórzy ludzie mogą to zobaczyć i po prostu myśleć, że to działa i jest wystarczająco dobre, a nie refaktoryzować.

jmq
źródło
1

Mądry człowiek rzekomo powiedział, należy zachować rzeczy tak proste, jak to możliwe, ale nie prostsze. To samo może dotyczyć kodu. Czasami musisz użyć techniki, którą niektórzy uważają za złożoną (rekurencja może być dobrym przykładem, często przeraża młodszych programistów).

Ogólnie jednak uważam, że złożony kod często powstaje w sposób organiczny. Prosty problem jest rozwiązywany za pomocą kodu, który jest prosty, następnie zakres rozszerza się i kod jest modyfikowany bez zbytniego zastanowienia, a wraz z upływem czasu otrzymujesz kod, który próbuje pokryć nowy problem, ale naprawdę został zaprojektowany, aby rozwiązać inny problem. Staje się patchworkową kołdrą z różnych elementów logiki. Taki kod może wtedy często wydawać się znacznie bardziej skomplikowany, niż wymaga tego problem, ale osiągnął ten cel, ponieważ każda mała zmiana wydawała się być wówczas najłatwiejszym sposobem na działanie kodu.

Nie sądzę, że większość programistów celowo postanowiła skomplikować kod (choć często popadasz w dziwne popisywanie się, kto użyje jakiejś techniki, aby udowodnić swoje umiejętności), ale myślę, że kod po prostu tak się stanie, jeśli nie będzie agresywnie utrzymywany i refaktoryzowany .

Steve
źródło
To zadziwiające, jak wiele systemów zaczyna się od naprawdę prostego rdzenia, który prawie spełnia wymagania, ale brakuje go na wiele różnych sposobów, a następnie dodaje wiele komplikacji, aby poradzić sobie z wieloma lukami, których można by uniknąć przy nieco bardziej skomplikowanym projekcie. Rozważ prostą konstrukcję typów całkowitych C i niektóre dziwacznie złożone reguły, które się z nimi wiążą. Gdyby dla każdego typu istniała opcja „powinna to być promocyjna”, nominalnie podwoiłaby liczbę typów (choć tak naprawdę nie różni się niczym od kwalifikatora volatileitp.), Ale…
supercat
... znacznie złagodziłoby zasady promocji / równoważenia. Nieulegające promocji krótkie spodenki dodane do nadającego się do int możliwego do uzyskania dałyby niepodlegające promocji krótkie spodenki bez względu na to, czy shortsą tak duże jak int. Promotable unsigned shortdodane do promotora intdałoby int. Dodanie podpisanych i niepodpisanych rzeczy o tym samym rozmiarze lub dodanie rzeczy niepodlegających promocji o różnych rozmiarach byłoby błędem. Dodaj odrobinę złożoności z przodu, a dziwne narożne skrzynie na dole znikną.
supercat
1

Innym powodem, który nie został jeszcze podniesiony, jest to, że ludzie mogą nadmiernie komplikować dostarczone rozwiązania, aby mieć pewność, że będą oni potrzebować ich usług w celu późniejszego wsparcia tych rozwiązań. Innymi słowy: dla bezpieczeństwa pracy.

quant_dev
źródło
Nie jestem pewien, dlaczego zostało to zanegowane, natknąłem się na wyjątkowo duże projekty zakodowane przez jednego człowieka, który stworzył własne środowisko i płacono co godzinę wyłącznie za ten projekt. Gdyby pracodawca go wkurzył, cała linia produktów byłaby zepsuta. Innemu deweloperowi zajęło by całe miesiące dokładne zrozumienie kodu, natomiast „wszechwiedzący” programista zaktualizowałby swój bałagan spaghetti.
SSH,
0

Może problem klasycznej pomyłki?

30. Pozłacanie programistów.

Programiści są zafascynowani nową technologią i czasami chcą wypróbować nowe funkcje swojego języka lub środowiska lub stworzyć własną implementację zręcznej funkcji, którą widzieli w innym produkcie - niezależnie od tego, czy jest to wymagane w ich produkcie. Wysiłek związany z projektowaniem, wdrażaniem, testowaniem, dokumentowaniem i obsługą funkcji, które nie są wymagane, wydłuża harmonogram.

  • Steve McConnell, Rapid Development.
Krewetki Krakersy
źródło
0

Tak, czasami nadmiernie komplikujemy kod, aby się bawić. Przeważnie jednak wrażenie, że kod jest nadmiernie skomplikowany, pochodzi od ignoranta lub młodszego uczestnika projektu.

P. Roe
źródło
1
-1 Starsi programiści, którzy kategorycznie obwiniają problemy młodszych programistów, prawdopodobnie nie rozumieją motywacji do własnej pracy lub pracy innych. Jeśli młodszym programistom trudno jest podążać za twoim kodem, IT jest zbyt skomplikowane.
Brandon,
Powiem, że jeśli programista Jr uzna kod za niemożliwy do zrozumienia, jest to zapach kodu i może być tak, że kod jest zbyt skomplikowany, ale używasz tutaj daleko, aby szeroko rozprowadzić pędzel. Ten zapach kodu może po prostu istnieć, ponieważ ten programista Jr potrzebuje pomocy w zrozumieniu zaawansowanej techniki, a nie samej winie.
P. Roe
-1

TAK ... i zapłaciłem cenę zbyt wiele razy.

Moja tablica ma teraz napis w gwiazdkach na samej górze, który czyta

„Jeśli to nie jest proste, to nie jest właściwe”

... i za każdym razem, gdy prototypuję coś na tablicy, zawsze przykuwa moją uwagę.

To naprawdę działa dla mnie, ponieważ moje złożone projekty stają się znacznie prostsze, co przekłada się na czystszy kod.

Dal
źródło