Jak wygląda kod dobrego programisty? [Zamknięte]

Jestem programistą hobbystą (zacząłem od VBA, aby przyspieszyć osiąganie doskonałości) i pracuję z VB.NET / C # .NET i próbuję nauczyć się ADO.NET.

Aspektem programowania, który zawsze mnie frustrował, jest to, jak wygląda „dobre”? Nie jestem profesjonalistą, więc nie mam z czym porównać. Co czyni lepszego programistę? Czy to:

• Lepiej rozumieją wszystkie obiekty / klasy / metody w danym języku?
• Ich programy są bardziej wydajne?
• Projekt ich programów jest znacznie lepszy pod względem lepszej dokumentacji, dobrego wyboru nazw funkcji itp.?

Innymi słowy, gdybym miał spojrzeć na kod profesjonalnego programisty, jaka jest pierwsza rzecz, którą bym zauważył w jego kodzie w stosunku do mojego? Na przykład czytam książki takie jak „Professional ASP.NET” wydawnictwa Wrox press. Czy przykłady kodu w tej książce są „światowej klasy”? Czy to szczyt? Czy któryś z najlepszych programistów spojrzałby na ten kod i pomyślałby, że to dobry kod?

Poniższa lista nie jest wyczerpująca, ale właśnie o tym pomyślałem, rozważając twoje pytanie.

• Dobry kod jest dobrze zorganizowany. Dane i operacje w klasach pasują do siebie. Nie ma żadnych zewnętrznych zależności między klasami. Nie wygląda jak „spaghetti”.

• Dobre komentarze do kodu wyjaśniają, dlaczego coś się robi, a nie to, co się robi. Sam kod wyjaśnia, co się dzieje. Potrzeba komentarzy powinna być minimalna.

• Dobry kod używa znaczących konwencji nazewnictwa dla wszystkich obiektów oprócz tych najbardziej przejściowych. nazwa czegoś informuje o tym, kiedy i jak używać obiektu.

• Dobry kod jest dobrze przetestowany. Testy służą jako wykonywalna specyfikacja kodu i przykłady jego użycia.

• Dobry kod nie jest „sprytny”. Robi rzeczy w prosty, oczywisty sposób.

• Dobry kod jest tworzony w małych, łatwych do odczytania jednostkach obliczeniowych. Te jednostki są ponownie wykorzystywane w całym kodzie.

Jeszcze tego nie przeczytałem, ale książka, którą zamierzam przeczytać na ten temat, to Clean Code autorstwa Roberta C. Martina.

Pierwszą rzeczą, jaką można zauważyć, jest to, że ich kod jest zgodny ze spójnym stylem kodowania . Zawsze piszą te same bloki struktury, wciskają religijnie i komentują w razie potrzeby.

Drugą rzeczą, którą można zauważyć, jest to, że ich kod jest podzielony na małe metody / funkcje obejmujące maksymalnie kilkadziesiąt linii. Używają również samoopisujących się nazw metod i generalnie ich kod jest bardzo czytelny.

Trzecią rzeczą, którą zauważysz, po tym, jak trochę pomieszałeś z kodem, jest to, że logika jest łatwa do naśladowania, łatwa do modyfikacji - a zatem łatwa w utrzymaniu.

Następnie będziesz potrzebować pewnej wiedzy i doświadczenia w zakresie technik projektowania oprogramowania, aby zrozumieć konkretne wybory, których podjęli się przy tworzeniu architektury kodu.

Jeśli chodzi o książki, nie widziałem wielu książek, w których kod można by uznać za „światowej klasy”. W książkach starają się głównie przedstawiać proste przykłady, które mogą być przydatne przy rozwiązywaniu bardzo prostych problemów, ale nie odzwierciedlają bardziej złożonych sytuacji.

Cytując Fowlera, podsumowując czytelność:

Każdy głupiec może napisać kod zrozumiały dla komputera.
Dobrzy programiści piszą kod zrozumiały dla ludzi.

nie powiedział.

Osobiście będę musiał zacytować „Zen Pythona” Tima Petersa. Mówi programistom Pythona, jak powinien wyglądać ich kod, ale uważam, że dotyczy to w zasadzie całego kodu.

Piękne jest lepsze niż brzydkie.
Jawne jest lepsze niż niejawne.
Proste jest lepsze niż złożone.
Złożone jest lepsze niż skomplikowane.
Płaskie jest lepsze niż zagnieżdżone.
Rzadkie jest lepsze niż gęste.
Liczy się czytelność.
Specjalne przypadki nie są na tyle wyjątkowe, aby łamać zasady.
Chociaż praktyczność przewyższa czystość.
Błędy nigdy nie powinny przejść bezgłośnie.
Chyba że wyraźnie uciszono.
W obliczu niejasności odrzuć pokusę zgadywania.
Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób na zrobienie tego.
Chociaż na początku może to nie być oczywiste, chyba że jesteś Holendrem.
Teraz jest lepiej niż nigdy.
Chociaż nigdy nie jest często lepsze niżprawo teraz.
Jeśli implementacja jest trudna do wyjaśnienia, to zły pomysł.
Jeśli implementacja jest łatwa do wyjaśnienia, może to być dobry pomysł.
Przestrzenie nazw to jeden wspaniały pomysł - zróbmy ich więcej!

Kod to poezja.

Zacznij od tego punktu logiki, a będziesz mógł wyprowadzić wiele pożądanych cech kodu. Co najważniejsze, zauważ, że kod jest czytany znacznie częściej niż jest napisany, dlatego pisz kod dla czytelnika. Przepisuj, zmieniaj nazwę, edytuj i refaktoryzuj dla czytelnika.

Następujący wniosek:

Czytelnik będzie Tobą w czasie n od daty utworzenia kodu. Opłatą za pisanie kodu dla czytelnika jest monotonicznie rosnąca funkcja n. Czytelnik, który po raz pierwszy patrzy na twój kod, jest oznaczony przez n == nieskończoność.

Innymi słowy, im większa przerwa czasowa od momentu napisania kodu do ponownego odwiedzenia kodu, tym bardziej docenisz wysiłki związane z pisaniem dla czytelnika. Ponadto każdy, komu przekażesz swój kod, odniesie duże korzyści z kodu napisanego z czytelnikiem jako najważniejszej rzeczy.

Drugi wniosek:

Kod napisany bez uwzględnienia czytelnika może być niepotrzebnie trudny do zrozumienia lub użycia. Kiedy zysk dla czytelnika spadnie poniżej pewnego progu, czytelnik czerpie z kodu mniejszą wartość niż wartość uzyskana przez przepisanie kodu. W takim przypadku poprzedni kod jest wyrzucany i, tragicznie, wiele pracy jest powtarzanych podczas przepisywania.

Trzeci wniosek:

Wniosek drugi jest znany z wielokrotnego powtarzania się w błędnym kole źle udokumentowanego kodu, po którym następuje wymuszone przepisanie.

Programuję od 28 lat i trudno mi odpowiedzieć na to pytanie. Dla mnie dobry kod to kompletny pakiet. Kod jest napisany przejrzyście, ze znaczącymi nazwami zmiennych i metod. Zawiera dobrze umieszczone komentarze, które komentują intencję kodu i nie tylko zwracają kod, który już możesz przeczytać. Kod robi to, co powinien, w efektywny sposób, bez marnowania zasobów. Musi być również napisany z myślą o łatwości konserwacji.

Najważniejsze jest jednak to, że oznacza to różne rzeczy dla różnych ludzi. To, co mogę nazwać dobrym kodem, którego ktoś inny może nienawidzić. Dobry kod będzie miał kilka wspólnych cech, które, jak sądzę, zidentyfikowałem powyżej.

Najlepszą rzeczą, jaką możesz zrobić, jest wystawienie się na kod. Spójrz na kod innych ludzi. Projekty Open Source są do tego dobrym źródłem. Znajdziesz dobry kod i zły kod. Im więcej na to patrzysz, tym lepiej rozpoznasz to, co określisz jako dobry i zły kod.

Ostatecznie będziesz swoim własnym sędzią. Kiedy znajdziesz style i techniki, które lubisz je przyjąć, z czasem wymyślisz swój własny styl, który z czasem się zmieni. Nie ma tu osoby, która mogłaby machać różdżką i powiedzieć, co jest dobre, a co inne złe.

Przeczytaj książkę Code Complete. To wyjaśnia wiele pomysłów na temat struktury kodu i powodów takiego postępowania. Czytanie jej powinno skrócić czas do zdobycia doświadczenia niezbędnego do odróżnienia dobra od zła.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Sam programując od prawie 10 lat i pracując z innymi, mogę bez uprzedzeń powiedzieć, że nie ma różnicy między dobrym programistą a przeciętnym programistą.

Wszyscy programiści na kompetentnym poziomie:

• Skomentuj poprawnie
• Struktura efektywnie
• Dokumentuj czysto

Kiedyś usłyszałem, jak współpracownik powiedział: „ Zawsze byłem bardzo logiczny i racjonalny. Myślę, że właśnie dlatego lubię się rozwijać ”

Moim zdaniem taki jest umysł przeciętnego programisty. Ten, kto postrzega świat w kategoriach reguł i logiki i ostatecznie przestrzega tych zasad podczas projektowania i pisania programu.

Doświadczony programista rozumie zasady, ale także ich kontekst. To ostatecznie prowadzi do nowych pomysłów i wdrożeń, co jest znakiem eksperta programisty. Programowanie jest ostatecznie formą sztuki.

Krótko mówiąc, kod dobrego programisty można odczytać i zrozumieć.

Moim zdaniem dobry kod programisty jest niezależny od języka ; dobrze napisany kod można odczytać i zrozumieć w krótkim czasie przy minimalnym myśleniu, niezależnie od używanego języka programowania. Niezależnie od tego, czy kod jest napisany w Javie, Pythonie, C ++ czy Haskell, dobrze napisany kod jest zrozumiały dla osób, które nawet nie programują w tym konkretnym języku.

Niektóre cechy łatwego do odczytania kodu to: dobrze nazwane metody, brak "sztuczek" i zawiła "optymalizacja", klasy są dobrze zaprojektowane, by wymienić tylko kilka. Jak wspominali inni, styl kodowania jest spójny, zwięzły i prosty .

Na przykład pewnego dnia przyjrzałem się kodowi TinyMCE, aby odpowiedzieć na jedno z pytań dotyczących przepełnienia stosu. Jest napisany w JavaScript, języku, którego prawie nie używałem. Jednak ze względu na styl kodowania i zawarte w nim komentarze, a także strukturę samego kodu, było to dość zrozumiałe i mogłem przejść przez kod w kilka minut.

Jedną z książek, która otworzyła mi oczy w kwestii czytania dobrego kodu programisty, jest Piękny kod . Zawiera wiele artykułów napisanych przez autorów różnych projektów programistycznych w różnych językach programowania. Jednak kiedy to przeczytałem, mogłem zrozumieć, co autor pisze w swoim kodzie, mimo że nigdy nie programowałem w tym konkretnym języku.

Być może powinniśmy pamiętać, że programowanie to także komunikacja, nie tylko z komputerem, ale z ludźmi , więc dobry kod programisty jest prawie jak dobrze napisana książka, która może przekazać czytelnikowi idee, które chce przekazać .

• Łatwe do odczytania
• łatwe do napisania
• łatwe w utrzymaniu

wszystko inne jest filigranowe

Dobry kod powinien być łatwy do zrozumienia.
Powinien być dobrze skomentowany.
Trudne fragmenty należy jeszcze lepiej skomentować.

Dobry kod jest czytelny. Nie miałbyś problemu ze zrozumieniem, co robi kod po pierwszym przeczytaniu kodu napisanego przez dobrego profesjonalnego programistę.

Zamiast powtórzyć wspaniałe sugestie innych, zasugeruję, abyś przeczytał książkę Code Complete autorstwa Steve'a McConnella

Zasadniczo jest to książka pełna najlepszych praktyk programistycznych dotyczących zarówno funkcjonalności, jak i stylu.

[Czysto subiektywna odpowiedź]
Dla mnie dobry kod jest formą sztuki, podobnie jak obraz. Mógłbym pójść dalej i powiedzieć, że to właściwie rysunek, który zawiera znaki, kolory, „formę” lub „strukturę” kodu, a wszystko to jest tak czytelne / wydajne. Kombinacja czytelności, struktury (tj. Kolumny, wcięcia, a nawet nazw zmiennych o tej samej długości!), Koloru (nazwy klas, nazwy zmiennych, komentarze itp.) - wszystko to sprawia, że ​​to, co lubię widzieć jako „piękny” obraz, który może czynią mnie albo bardzo dumnym, albo bardzo odrażającym z mojego własnego kodu.

(Jak powiedziałem wcześniej, bardzo subiektywna odpowiedź. Przepraszam za mój angielski.)

Popieram rekomendację „Clean Code” Boba Martina.

„Piękny kod” spotkał się z dużym uznaniem kilka lat temu.

Warto przeczytać każdą książkę McConnella.

Być może „Pragmatyczny programista” też by się przydał.

%

Chciałem tylko dodać moje 2 centy ... komentarze do twojego kodu - i ogólnie twój kod - powinny powiedzieć, co robi twój kod, teraz jak to robi. Kiedy już masz pojęcie kodu „klienta”, czyli kodu wywołującego inny kod (najprostszym przykładem jest kod wywołujący metodę), zawsze powinieneś się najbardziej martwić o to, aby kod był zrozumiały z perspektywy „klienta”. Wraz z rozwojem kodu zobaczysz, że to jest ... hm, dobrze.

Wiele innych rzeczy związanych z dobrym kodem dotyczy skoków mentalnych, które wykonasz (zdecydowanie, jeśli zwrócisz uwagę) ... 99% z nich ma do czynienia z odrobiną pracy teraz, aby zaoszczędzić ci mnóstwo pracować później i wielokrotnego użytku. A także z robieniem rzeczy dobrze: prawie zawsze chcę działać w drugą stronę, zamiast używać wyrażeń regularnych, ale za każdym razem, gdy wchodzę w to, rozumiem, dlaczego wszyscy używają ich w każdym języku, w którym pracuję (są zawiłe, ale pracy i prawdopodobnie nie mogło być lepiej).

Co do tego, czy patrzeć na książki, powiedziałbym zdecydowanie nie z mojego doświadczenia. Spójrz na interfejsy API, frameworki, konwencje kodowe i kod innych ludzi, użyj własnych instynktów i spróbuj zrozumieć, dlaczego rzeczy są takie, jakie są i jakie są tego konsekwencje. To, czego kod w książkach prawie nigdy nie robi, to planowanie nieplanowanych, i właśnie o to chodzi w sprawdzaniu błędów. Opłaca się to tylko wtedy, gdy ktoś wyśle ​​Ci wiadomość e-mail i powie: „Mam błąd 321” zamiast „hej, aplikacja jest zepsuta”.

Dobry kod jest napisany z myślą o przyszłości, zarówno z perspektywy programisty, jak i użytkownika.

Odpowiedzi na to całkiem dobrze można znaleźć w książce Fowlera „Refaktoryzacja”. To brak wszystkich „zapachów”, które opisuje w całej książce.

Nie widziałem „Professional ASP.NET”, ale zdziwiłbym się, gdyby było lepsze niż OK. Zobacz to pytanie w przypadku niektórych książek z naprawdę dobrym kodem. (Oczywiście jest różny, ale akceptowana odpowiedź jest trudna do pokonania).

Wydaje się, że to (powinno być) FAQ. Jest ACM artykuł o pięknej kodu niedawno. Wydaje się, że duży nacisk kładzie się na łatwość czytania / zrozumienia. Kwalifikowałbym to jako „łatwe do odczytania / zrozumienia przez ekspertów dziedzinowych”. Naprawdę dobrzy programiści mają tendencję do używania najlepszych algorytmów (zamiast naiwnych, łatwych do zrozumienia algorytmów O (n ^ 2)) dla danych problemów, co może być trudne do zrozumienia, jeśli nie znasz algorytmu, nawet jeśli dobrze programista podaje odniesienie do algorytmu.

Nikt nie jest doskonały w tym dobrych programistów, ale ich kod wydają się dążyć do:

1. Poprawność i wydajność dzięki sprawdzonym algorytmom (zamiast naiwnych i doraźnych hacków)
2. Jasność (komentarz intencyjny w odniesieniu do nietrywialnych algorytmów)
3. Kompletność obejmująca podstawy (konwencja kodowania, wersjonowanie, dokumentacja, testy jednostkowe itp.)
4. Zwięzłość (SUCHA)
5. Solidność (odporność na arbitralne dane wejściowe i zakłócenia żądań zmian)

popieram rekomendację dotyczącą „czystego kodu” wuja Bob. ale możesz rzucić okiem na http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091, ponieważ myślę, że to lepiej rozwiązuje Twoje konkretne pytanie. dobry kod powinien wyskoczyć ze strony i powiedzieć Ci, co robi / jak działa.

Jeff Atwood napisał fajny artykuł o tym, jak programiści są pierwszym odniesieniem do maszynistek: http://www.codinghorror.com/blog/archives/001188.html

Jako maszynistka zawsze musisz być elegancki w swojej pracy, bardzo ważna jest struktura i odpowiednia „gramatyka”. Teraz przekonwertowanie tego na typowanie „programowe” przyniosłoby ten sam wynik.

Struktura

Komentarze

Regiony

Jestem inżynierem oprogramowania, co oznacza, że ​​podczas mojej edukacji spotkałem się z wieloma różnymi językami, ale moje programowanie zawsze „czuję” to samo, podobnie jak moje pisanie na fekberg.wordpress.com, mam „specjalny” sposób pisania.

Teraz programując różne aplikacje w różnych językach, takich jak Java, C #, Assembler, C ++, C Doszedłem do „standardu” pisania, który lubię.

Widzę wszystko jako „pudełka” lub regiony, a każdy region ma swoje wyjaśnienia. Region może być „klasą Person”, a wewnątrz tego regionu mam kilka metod określania właściwości, które mogę nazwać „metodami dostępu” lub takimi, a każda właściwość i region mają własne wyjaśnienia.

Jest to bardzo ważne, zawsze postrzegam mój kod, który robię, jako „część interfejsu API”, podczas tworzenia struktury API, a elegancja jest BARDZO ważna.

Pomyśl o tym. Przeczytaj także mój artykuł, w Communication issues when adapting outsourcingktórym wyjaśnia w przybliżeniu, w jaki sposób zły kod może kolidować, Enterpret as you like: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Dobry kod jest łatwy do zrozumienia, łatwy w utrzymaniu i łatwy do dodania. W idealnym przypadku jest również tak skuteczny, jak to tylko możliwe, bez poświęcania innych wskaźników.

Dla mnie świetny kod to coś, co jest łatwe do zrozumienia, a jednocześnie wyrafinowane. Rzeczy, które sprawiają, że idziesz, „wow, oczywiście, dlaczego nie pomyślałem o tym w ten sposób?”. Naprawdę dobry kod nie jest trudny do zrozumienia, po prostu rozwiązuje problem w prosty sposób (lub rekurencyjnie, jeśli to jest jeszcze prostsze).

Dobry kod to miejsce, w którym wiesz, co robi metoda z nazwy. Zły kod to miejsce, w którym musisz dowiedzieć się, co robi kod, aby nadać sens nazwie.

Dobry kod to miejsce, w którym, jeśli go przeczytasz, możesz zrozumieć, co robi, w niewiele więcej czasu niż potrzeba, aby go przeczytać. Zły kod polega na tym, że patrzysz na niego przez wieki, próbując dowiedzieć się, jak to działa.

Dobry kod ma rzeczy nazwane w taki sposób, że trywialne komentarze są niepotrzebne.

Dobry kod jest zazwyczaj krótki.

Dobry kod może być ponownie użyty, aby robić to, co robi gdziekolwiek indziej, ponieważ nie opiera się na rzeczach, które są naprawdę niezwiązane z jego przeznaczeniem.

Dobry kod to zwykle zestaw prostych narzędzi do wykonywania prostych zadań (połączonych w dobrze zorganizowany sposób, aby wykonywać bardziej wyrafinowane zadania). Zły kod jest zwykle ogromnymi narzędziami wielofunkcyjnymi, które są łatwe do złamania i trudne w użyciu.

Kod jest odzwierciedleniem umiejętności i sposobu myślenia programisty. Dobrzy programiści zawsze patrzą w przyszłość - jak będzie działał kod, gdy wymagania lub okoliczności nie będą dokładnie takie, jakie są dzisiaj. Jak bardzo będzie to skalowalne? Jak wygodne będzie, gdy to nie ja obsługuję ten kod? Jak kod będzie nadający się do ponownego wykorzystania, aby ktoś inny wykonujący podobne czynności mógł ponownie użyć kodu i nie pisać go ponownie. A co, gdy ktoś inny próbuje zrozumieć napisany przeze mnie kod.

Kiedy programista ma takie nastawienie, wszystkie inne rzeczy ładnie się układają.

Uwaga: Podstawa kodu jest opracowywana przez wielu programistów z biegiem czasu i zazwyczaj nie ma konkretnego wyznaczenia podstawy kodu dla programisty. Dlatego dobry kod jest odzwierciedleniem wszystkich standardów firmy i jakości jej pracowników.

(Używam „on” poniżej, ponieważ jest to osoba, do której aspiruję , czasami z sukcesem).

Wierzę, że sednem filozofii dobrego programisty jest to, że zawsze myśli "Piszę dla siebie w przyszłości, kiedy zapomnę o tym zadaniu, dlaczego nad nim pracowałem, jakie były zagrożenia, a nawet jak to kod miał działać ”.

W związku z tym jego kod musi:

1. Praca (nie ma znaczenia, jak szybko kod dostanie złą odpowiedź. W prawdziwym świecie nie ma częściowego kredytu).
2. Wyjaśnij, skąd wie, że ten kod działa. Jest to połączenie dokumentacji (javadoc jest moim ulubionym narzędziem), obsługi wyjątków i kodu testowego. W bardzo realnym sensie uważam, że wiersz po wierszu, kod testowy jest cenniejszy niż kod funkcjonalny, jeśli nie z innego powodu niż wyjaśnia „ten kod działa, tak powinien być używany i dlatego powinienem dostać płatny."
3. Być utrzymywanym. Martwy kod to koszmar. Utrzymanie starego kodu jest obowiązkiem, ale trzeba go wykonać (pamiętaj, że jest „dziedzictwem” w chwili, gdy opuszcza Twoje biurko).

Z drugiej strony uważam, że dobry programista nigdy nie powinien robić takich rzeczy:

1. Obsesja na punkcie formatowania. Istnieje wiele IDE, edytorów i ładnych drukarek, które mogą formatować kod dokładnie według standardowych lub osobistych preferencji, które uważasz za odpowiednie. Używam Netbeans, raz konfiguruję opcje formatu i od czasu do czasu wciskam alt-shift-F. Zdecyduj, jak chcesz wyglądać kod, skonfiguruj środowisko i pozwól narzędziu wykonać podstawową pracę.
2. Obsesja na punkcie konwencji nazewnictwa kosztem komunikacji międzyludzkiej. Jeśli konwencja nazewnictwa prowadzi cię do nadawania nazw klasom „IElephantProviderSupportAbstractManagerSupport” zamiast „Zookeeper”, zmień standard, zanim utrudnisz go następnej osobie.
3. Zapomnij, że pracuje jako zespół z prawdziwymi ludźmi.
4. Zapomnij, że głównym źródłem błędów kodowania jest teraz jego klawiatura. Jeśli jest pomyłka lub pomyłka, powinien najpierw spojrzeć na siebie.
5. Zapomnij o tym, co się dzieje. Każda praca, którą wykonuje teraz, aby uczynić swój kod bardziej dostępnym dla przyszłych czytelników, prawie na pewno przyniesie mu bezpośrednie korzyści (ponieważ kto będzie pierwszą osobą poproszoną o sprawdzenie jego kodu?

1. To działa
2. Posiada testy jednostkowe, które dowodzą, że to działa

Reszta to lukier ...

• Najlepszy kod ma pewną elegancję, którą rozpoznajesz, gdy tylko go zobaczysz.
• Wygląda na wykonany z dbałością i dbałością o szczegóły. Jest oczywiście wyprodukowany przez kogoś z umiejętnościami i ma w sobie sztukę - można powiedzieć, że wygląda na wyrzeźbiony i wypolerowany, a nie szorstki i gotowy.
• Jest spójny i łatwo się czyta.
• Jest podzielony na małe, bardzo spójne funkcje, z których każda wykonuje jedną rzecz i robi to dobrze.
• Jest minimalnie sprzężony, co oznacza, że ​​zależności są nieliczne i ściśle kontrolowane, zwykle przez ...
• Funkcje i klasy mają zależności od abstrakcji, a nie od implementacji.

Jak na ironię, im lepszy programista, tym mniej niezbędny staje się, ponieważ wyprodukowany kod jest łatwiejszy w utrzymaniu przez każdego (zgodnie z ogólną zgodą Erana Galperina).

Z mojego doświadczenia wynika, że ​​jest też odwrotnie. Im gorszy programista, tym trudniejszy jest jego / jej kod, tym bardziej staje się niezbędny, ponieważ żadna inna dusza nie jest w stanie zrozumieć stworzonych zagadek.

Mam dobry przykład:

Przeczytaj kod źródłowy GWT (google web tookit), zobaczysz, że każdy głupiec to rozumie (niektóre angielskie książki są trudniejsze do odczytania niż ten kod).