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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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 .

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.

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.

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.

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.