Skąd miałbyś wiedzieć, czy napisałeś czytelny i łatwy w utrzymaniu kod?

336

Skąd można wiedzieć, czy utworzony przez siebie kod jest łatwy do odczytania, zrozumienia i utrzymania? Oczywiście z punktu widzenia autora kod jest czytelny i łatwy do utrzymania, ponieważ autor napisał go i zredagował na początek. Jednak musi istnieć obiektywny i wymierny standard, według którego nasz zawód może mierzyć kod.

Cele te są osiągane, gdy można wykonać następujące czynności przy użyciu kodu bez porady eksperta oryginalnego autora:

  • Możliwe jest odczytanie kodu i zrozumienie na poziomie podstawowym przepływu logiki.

  • Na głębszym poziomie można zrozumieć, co robi kod, aby uwzględnić dane wejściowe, wyjściowe i algorytmy.

  • Inni programiści mogą wprowadzać znaczące zmiany w oryginalnym kodzie, takie jak poprawki błędów lub refaktoryzacja.

  • Można napisać nowy kod, taki jak klasa lub moduł, który wykorzystuje oryginalny kod.

Jak kwantyfikujemy lub mierzymy jakość kodu, aby wiedzieć, że jest on czytelny, zrozumiały i łatwy w utrzymaniu?

22815
źródło
154
Obowiązkowy link ( choć raz nie do xkcd): osnews.com/images/comics/wtfm.jpg
Jerry Coffin
3
Po prostu nonszalancko powiem, że znasz go, gdy go widzisz, ale ten argument był zasadniczo wadliwy i zawstydzający nawet w jego oryginalnej formie, nie wspominając o kodzie źródłowym.
Konrad Rudolph
6
„Oczywiście z twojego punktu widzenia twój kod jest czytelny” - nie takie oczywiste!
UncleZeiv
24
Powiedziałbym, że wiesz, kiedy widzisz to kilka miesięcy po napisaniu.
JeffO
2
@asfallows: Pokazałem trochę kodu mojej żonie, a ona pomyślała, że ​​to naprawdę zły kod, ponieważ mogła go przeczytać! (Zbyt wiele angielskich słów i za mało znaków @ [! ^ $ & *) ...)
gnasher729

Odpowiedzi:

369

Twój rówieśnik powie ci po przejrzeniu kodu.

Nie możesz tego ustalić sam, ponieważ jako autor wiesz więcej niż sam kod mówi. Komputer nie może ci powiedzieć z tych samych powodów, z których nie może stwierdzić, czy obraz jest sztuką, czy nie. Dlatego potrzebujesz innego człowieka - zdolnego do utrzymania oprogramowania - aby spojrzeć na to, co napisałeś i wyrazić swoją opinię. Formalna nazwa tego procesu to wzajemna ocena .

1249
źródło
6
Nic nie przebije testów empirycznych.
Inżynier świata
25
+1 Twoja najważniejsza publiczność to twoi rówieśnicy, którzy są zanurzeni z tobą, wiedząc, dlaczego i jak rozwiązujesz problem. Dobry kod odzwierciedla bieżące rozumienie tego przez twoją grupę rówieśniczą. Zakładając, że zespół jest zdolny, przemyślany i otwarty na nowe pomysły, „twój kolega mówi ci, że jest dobry / łatwy do utrzymania”, z mojego doświadczenia jest zdecydowanie lepszą definicją niż jakakolwiek inna.
Doug T.
69
Z mojego doświadczenia wynika, że ​​działa to tylko wtedy, gdy twój kolega wie, co jest dobre, a co złe. W przeciwnym razie będzie to brzmiało następująco: „Powinieneś napisać ten kod tą samą metodą, łatwiej jest znaleźć kod”
Rangi Lin
12
@RangiLin, cóż, twój kolega może mieć rację.
11
@Rangi Musisz współpracować z kolegami, których masz. jeśli uznają twój kod za trudny, jest to problem z twoim kodem. W dłuższej perspektywie, można ich kształcić, albo postarać się o lepsze współpracowników (można przenieść czy można wpływać na proces rekrutacji) ... Aha, i robić zawsze pamięta, że mogą mieć rację.
MarkJ
220

Czasami najlepszym sposobem na to jest powrót do kodu napisanego sześć miesięcy temu i próba zrozumienia, co zostało napisane.

Jeśli szybko to zrozumiesz - jest czytelny.

Alex In Paris
źródło
28
Tak, to brzmi dobrze (i to prawda), ale nie jest to zbyt dobre podejście do decydowania o tym, co / jak dziś zrobić ...
Michael Durrant
10
Wycięcie sugeruje, że zajmuje to trochę czasu i musisz to zrobić ostrożnie ...
deworde
3
Mogę skrócić ramy czasowe ponownej wizyty do miesiąca, a nawet krócej, na pierwszą wizytę. Myślę, że zależy to od złożoności projektu i dziedziny, a także od twojego mentalnego podejścia. Uważam, że po sześciu miesiącach rozprasza mnie widok możliwości refaktoryzacji lub optymalizacji przy użyciu narzędzi lub technik, których się nauczyłem, odkąd napisałem kod, zamiast prawdziwej czytelności.
Chris Bye
1
@MichaelDurrant Za każdym razem, gdy przeglądasz stary kod, znajdziesz fragmenty, które powinny być napisane inaczej, a następnie bierzesz to pod uwagę w kodzie, który piszesz „dzisiaj”. Tak, nauka pisania dobrego kodu zajmuje trochę czasu.
dj18
1
@MichaelDurrant nadal tak jest, ponieważ możesz dowiedzieć się, jakie niejasne rzeczy robiłeś sześć miesięcy temu, i nie rób tego dzisiaj.
djechlin
94

To jest:

  1. utrzymywalne, jeśli możesz to utrzymać .
  2. łatwe do utrzymania, jeśli ktoś inny może go utrzymać bez proszenia cię o pomoc
  3. czytelne, jeśli ktoś inny po przeczytaniu poprawnie zrozumie projekt, układ i zamiar

Prawdziwym testem na 1. jest (jak twierdzą Alex w Paryżu i quant_dev ), że możesz go odzyskać po kilku miesiącach robienia czegoś innego.

Test na 2. i 3. polega na tym, że ktoś inny może go podnieść i dowiedzieć się, jak rozszerzyć lub naprawić kod, postępując zgodnie z projektem. Jeśli nie potrafią zrozumieć projektu, jego związku z przestrzenią problemową lub sposobu, w jaki twój kod ma być używany, zamiast tego zhakują rozwiązanie w poprzek ziarna.

Istnieją zasady praktyczne, zasady (tj. Zasady praktyczne, które ktoś ładnie napisał i podał imię) oraz wszelkiego rodzaju sugestie, które mogą poprowadzić cię we właściwym kierunku lub z dala od typowych pułapek. Żaden z nich nie gwarantuje jednak jakości, o którą prosisz.

Nieprzydatny
źródło
2
Co powiesz na rozważenie czasu poświęconego na naprawę błędu lub zmodyfikowanie istniejącego zachowania jako czynnika umożliwiającego utrzymanie? Fragment kodu, który wymaga mniej czasu na wykonanie tej samej zmiany, powinien być łatwiejszy w utrzymaniu, prawda?
VCD
1
Zależy; czasami dobre wykonanie modyfikacji będzie wymagało refaktoryzacji (co można powiedzieć, że jest potrzebne, ponieważ czytelny kod wyjaśnia, że ​​nie jest przeznaczone do takiego użycia), co trwa dłużej niż włamanie w specjalnym przypadku (który nieczytelny kod zachęca, ponieważ zamiar jest niejasny ).
Bezużyteczne
30

Jeśli Twój kod jest zgodny z zasadami SOLID i DRY i ma w nim dobry zestaw testów jednostkowych, prawdopodobnie można go utrzymać.

Czy to jest czytelne? Przeczytaj to. Czy nazwy metod i zmiennych mają sens? Czy potrafisz bez problemu podążać za logiką programu? Jeśli odpowiedź brzmi „tak”, kod jest czytelny.

Oded
źródło
8
... a po przeczytaniu podaj go komuś innemu, aby spróbował przeczytać.
jcmeloni
19
To nie jest szczególnie dobry test. Wiele zastosowań tych reguł jest subiektywnych i prawie zawsze możesz przeczytać swój kod zaraz po jego napisaniu.
DeadMG
1
„Jeśli odpowiedź brzmi„ tak ”, kod jest czytelny”… przez ciebie . Aby zobaczyć, czy jest czytelny dla innych, inni muszą go przeczytać.
2
IMO, SOLID jest przereklamowany. Zwłaszcza „S.” To lub wszyscy źle to interpretują.
Erik Reppen
Wiele razy napotkałem kod, który był SUCHY i SOLIDNY, a jednak okropny. Przestrzeganie zasad może dawać fałszywe wrażenie, że to, co piszesz, nie jest gównem.
Jakub Arnold
24

Czytanie, jak pisać nieusuwalny kod - Roedy Green zapewnia pracę na całe życie , śmiejąc się i ucząc.

... jak napisać kod, który jest tak trudny w utrzymaniu, że ludzie, którzy przyjdą po ciebie, będą latami wprowadzać nawet najprostsze zmiany. Ponadto, jeśli będziesz przestrzegać tych wszystkich zasad religijnie, zagwarantujesz sobie nawet dożywotnią pracę, ponieważ nikt oprócz ciebie nie ma nadziei na utrzymanie kodu ...

Esej zawiera wiele przykładów pisania złego kodu, przy użyciu wielu zabawnych przykładów. W dalszym ciągu wyjaśnia, w jaki sposób wykorzystać twórczą pisownię , ponowne użycie nazw , wysoko cenioną technikę ponownego wykorzystywania nazw globalnych jako prywatnych .

W zabawny sposób esej uczy, jak unikać wszystkich przykładów nieczytelnego i niemożliwego do utrzymania kodu.

W rzeczywistości trudno mi było uwierzyć, że ktoś napisałby kod podobny do przykładów w tekście. To było, kiedy byłem świeżo po szkole. Ale po kilku latach pracy codziennie widzę kod z tekstu…

iikkoo
źródło
Zobacz także waterfall2006.com/gorman.html Przebudowa to proces pobierania dobrze zaprojektowanego fragmentu kodu i, poprzez serię małych, odwracalnych zmian, czyniąc go całkowicie niemożliwym do utrzymania dla nikogo oprócz ciebie.
Sjoerd,
22

Pomimo tego, jak się wydaje, istnieją pewne dość obiektywne środki, które można rozważyć. Książki takie jak Standardy kodowania C ++ , Refaktoryzacja i Czysty kod mają długie listy kryteriów, według których można oceniać kod, patrząc na takie znaczące nazwy, rozmiary funkcji, zasady takie jak łączenie i spójność, projektowanie obiektów, testowanie jednostek, kolejne udoskonalanie itp.

Lista jest zbyt duża, aby można ją było dostosować do listy kontrolnej, ale czytasz książkę i wybierasz kilka kluczowych rzeczy, nad którymi chcesz popracować, a następnie po kilku miesiącach przeczytaj ją jeszcze raz, aby poprawić.

Karl Bielefeldt
źródło
4
+1 za stopniowe uczenie się i nie próbowanie stać się doskonałym z dnia na dzień
dj18
19

Dowód jest w budyniu. Zobacz, co się stanie po przekazaniu go rozsądnie kompetentnej osobie. Jeśli nie muszą zadawać wielu pytań dotyczących trudności kodu, wykonałeś dobrą robotę.

To była wczesna lekcja w mojej karierze. Mentor powiedział: „Dokumentuj wszystko, abyś mógł później uciec z programu. Jeśli nie spodziewasz się pytań, kiedy odpowiedzi będą świeże w twoim umyśle, będziesz musiał je zrozumieć, kiedy nie są”.

MathAttack
źródło
10
Uważaj, aby ludzie nie zadawali pytań z obawy przed ujawnieniem swojej niewiedzy. Możesz nawet postrzegać tych ludzi jako „rozsądnie kompetentnych” przede wszystkim ze względu na ich skłonność do powstrzymywania się od ich ujawnienia. Więc brak pytań może nie być dobrą rzeczą, chyba że wiesz, że jesteście szczerzy.
Hermann Ingjaldsson,
1
@HermannIngjaldsson - Wystarczająco uczciwy. Oczywiście, jeśli nie są kompetentni i coś się zepsuje, usłyszysz o tym wkrótce. "Wsparcie!!!!"
MathAttack 11.11.12
wydaje się to jedynie powtórzeniem tego, co zostało powiedziane w pierwszej odpowiedzi
komnata
17

Przeczytałem wszystkie odpowiedzi i zauważyłem, że nikt nie wspomniał o złożoności kodu.

Istnieje ścisła korelacja między złożonością kodu a czytelnością / utrzymywalnością. Istnieje wiele algorytmów oceny złożoności kodu, ale porozmawiam o tym, jak działa ocenianie złożoności McCabe.

Zasadniczo, punktacja McCabe czyta twój kod i oblicza liczbę unikalnych „ścieżek”, które przez niego przechodzą. Jeśli użyjesz McCabe jako licznika, a wierszy kodu jako mianownika, uzyskasz całkiem niezłe przybliżenie „czytelności”.

Jeśli masz 10 linii kodu i istnieje 300 ścieżek przez ten kod, to jest to dość nieusuwalny kod (trudny do zmiany w bezpieczny i łatwy sposób) i prawdopodobnie nie jest bardzo czytelny. I odwrotnie, jeśli masz 300 linii kodu, ale jest tylko jedna ścieżka (nie ma żadnych warunków), jest on czytelny i łatwy w utrzymaniu.

Jednak McCabe upada w tym ostatnim przykładzie. Jeśli mam 300 linii kodu bez żadnych warunków, to jest naprawdę duża szansa, że ​​zrobiłem „ponowne użycie kopiuj / wklej”, i oczywiście to też nie jest dobra rzecz. Istnieją więc ogólnosystemowe wskaźniki, które stosujesz oprócz McCabe - takie jak wykrywanie duplikatów lub prawie duplikatów.

Joe Rounceville
źródło
2
To powinna być odpowiedź. Pomiar. Inne odpowiedzi są bardziej opiniami niż faktami, jeśli mogę to zrozumieć, to musi być dobre? Najpierw zmierz za pomocą analizy złożoności, a następnie ludzkiego refaktora, aby poszukać duplikacji itp.
Jon Raynor
1
Ostatni akapit, w którym wspominasz o wadach wyniku McCabe podzielonego przez LOC, raczej podważa cały pomysł. Jeśli potrzebujesz 300 ścieżek w swoim kodzie, dlaczego, u licha, zwiększysz możliwości utrzymania kodu przy użyciu większej liczby linii? To tak, jakby powiedzieć, że jeśli książka zawiera misterne pomysły, powinna być naprawdę dużą książką, a nie próbować komunikować się zwięźle. -1.
Wildcard,
8

Jedną kwestią, którą podzielę, jest to, że kod jest wbudowany w „moduły”, a kiedy mówię, że mam na myśli to, że możesz zmienić jedną rzecz w module i łatwo pracować z całością. Eliminuje efekty między niepowiązanymi rzeczami. Również:

  • Kod można łatwo wykorzystać ponownie
  • Twój kod jest elastyczny (wiąże się to z wbudowaniem modułów)
  • SUCHO - Nie powtarzaj się

Bardzo polecam lekturę, The Pragmatic Programmer.

jket
źródło
8

Niektóre testy / wskaźniki:

  • Wyłącz IDE. Czy nadal potrafisz odczytać własny kod? Kiedy pojawia się błąd, czy dość łatwo jest go ręcznie prześledzić i dowiedzieć się, w której klasie potrzebujesz punktu przerwania, aby dowiedzieć się, na czym polega problem? Lub kiedy korzystasz z IDE, po prostu nie zawracasz sobie głowy krokiem od samego początku?

  • Debugowanie często staje się grą wack-a-mole, w której naprawienie jednego błędu tworzy 2+ więcej.

  • Od pociągnięcia za spust do czegoś użytecznego, co faktycznie się dzieje, ile wywołań metod? Ile metod przekazuje dokładnie takie same lub większość tych samych dokładnych parametrów do innego wywołania metody?

  • Ile plików musisz otworzyć, aby po prostu dodać prostą nową metodę do klasy?

  • Pomyśl o przyjętych wzorcach i praktykach. Czy zrobiłeś to, ponieważ miały doskonały sens, czy też dlatego, że ktoś przekonał cię, że „to jedyny sposób, aby to zrobić?” lub dlatego, że chciałeś to w swoim życiorysie lub dlatego, że powiedział to jakiś deweloper rockstar.

Erik Reppen
źródło
3
Czytanie kodu bez IDE wydaje się głupie, szczególnie jako miara czytelności. Ten rodzaj metryki skutkuje „rozwiązaniami” węgierskiego stylu notacji, które naprawdę podważają ostatecznie czytelność.
rubenvb
8

Skąd można wiedzieć, czy utworzony przez niego kod jest łatwy do utrzymania i odczytu?

Możesz zlokalizować łatwy w utrzymaniu i czytelny kod, szukając następujących właściwości:

  1. Obiekty, metody i / lub funkcje zawsze robią jedną rzecz.
  2. Metody i / lub funkcje są zwięzłe (jak w „krótkim, ale wyczerpującym”).
  3. Obiekty, metody i / lub funkcje wykonują w zasadzie to, co według nich powinno się robić na podstawie ich nazw.
  4. Kod przeznaczony do ponownego użycia jest w rzeczywistości wielokrotnego użytku.
  5. Na koniec, jeśli możesz od razu przetestować kod jednostkowo, prawdopodobnie napisałeś kod modułowy o pojedynczej odpowiedzialności.

Skąd mielibyśmy wiedzieć, gdybyśmy napisali dość niechlujny i niemożliwy do utrzymania kod? Czy są jakieś konstrukcje lub wytyczne, które należy wiedzieć, czy opracowaliśmy niechlujne oprogramowanie?

  1. Jeśli czytasz jakąś metodę i nie jest jasne, co to była za intencja, jest to w najlepszym razie nieeleganckie, aw najgorszym razie niemożliwe do utrzymania.
  2. Jeśli to nie wydaje się proste, to prawdopodobnie nie jest proste i jest to znak niemożliwego do utrzymania kodu lub kodu, który wkrótce stanie się niemożliwy do utrzymania.
  3. Jeśli brak jest symetrii (spójności) w całej bazie kodu, prawdopodobnie patrzysz na niemożliwy do utrzymania kod.
wilmoore
źródło
Nie zgadzam się, że twój przykład refaktoryzacji jest jaśniejszy. Zgadzam się, że oryginalny kod wymaga pracy, ale czysto i pod względem komunikacyjnym uważam, że oryginał jest znacznie lepszy. Jestem bardzo podejrzany o wszelkie refaktoryzacje, które twierdzą, że poprawiają przejrzystość podczas wprowadzania wyrażenia regularnego.
Roy
1
@ Roy, tak, w porządku. Prawdopodobnie nigdy nie powinienem dodawać tej próbki kodu. To prawda, że ​​było to prawie 3 lata temu, ale nawet wtedy prawdopodobnie nie powinienem był używać PHP (kulę się, patrząc na to teraz) i nie powinienem był używać wyrażenia regularnego, ponieważ jest to jedna z tych rzeczy, które niektórzy ludzie mogą na nie spojrzeć i od razu je zdobyć, ale dla innych, bez względu na to, jak zwięzłe, wyrażenia regularne są natychmiast wyłączane. Mam zamiar edytować odpowiedź i upuścić próbkę kodu. Dziękuję za komentarz.
Wil Moore III
Jak obiekt może zrobić jedną rzecz?
Koray Tugay
@KorayTugay Pomyśl o tym w ten sposób. Jeśli obiekt opisuje więcej niż jedną spójną koncepcję, masz zapach.
Wil Moore III
6

Jednym słowem: Doświadczenie .

Aby rozpocząć, musisz wykonać gruntowne prace, więc nie mogę zalecić, aby programiści poświęcili czas na czytanie książek, takich jak Refaktoryzacja , która zapewni niektóre z bardziej niezbędnych narzędzi w arsenale programistów, które poprawią twoją zdolność do utrzymywania kodu oraz Clean Code, który został napisany przez jedne z najbardziej rozpoznawalnych talentów w naszej dziedzinie i który opisuje prawie wszystko, co musisz zrozumieć, aby Twój kod był czysty i czytelny.

Żadna ilość lektury nie zastąpi jednak ciężko zarobionego doświadczenia. Naprawdę musisz pracować z kodem przez chwilę, aby w pełni docenić różnicę, jaką może mieć dbałość o jakość kodu. Doświadczając przyjemności pracy z czystym, dobrze przemyślanym kodem, a także bólu związanego ze spaghetti kodowym, uczysz się lepiej rozumieć, czego autorzy tych książek naprawdę chcieli cię nauczyć, ale robisz to w szerszym kontekście prawdziwego kodu produkcyjnego na żywo, gdzie jakość tego, co robisz, naprawdę ma znaczenie i wpływa na twoją zdolność do łatwej pracy z kodem na codzień.

Pomaga także mieć dobrego mentora lub równorzędnego specjalistę z doświadczeniem, który potwierdza, że ​​wkładasz wysiłek w pisanie kodu na wysokim poziomie. To tylko jeden z powodów, dla których recenzje kodów mogą być tak przydatne. Korzystanie z narzędzi do sprawdzania i formatowania kodu może być również bardzo przydatną pomocą w utrzymaniu porządku. Nic jednak nie może się równać z doświadczeniem zdobytym przez lata pisania oprogramowania, tak, że automatycznie piszesz kod, który jest czysty, czytelny i ustrukturyzowany po prostu dla ułatwienia konserwacji, a wszystko dlatego, że przyzwyczaiłeś się stosować do tego najlepsze praktyki długo.

S.Robins
źródło
3

Nie będąc purytańskim: preferuj funkcjonalny styl. Obecnie większość języków (.NET, Ruby, Python, JavaScript itp.) Obsługuje je i promuje (np. LINQ, underscorejs).

Jest niezwykle łatwy do odczytania.

var recentTopCustomers = OrderList
    .Where(o => o.Date >= DateTime.Now.AddDays(-5))
    .Where(o => o.Amount > 1000)
    .OrderBy(o => -o.Amount)
    .Take(10)
    .Select(o => o.Customer);

Zmusza każdy węzeł do pojedynczego, skoncentrowanego zamiaru, który zapewnia jasność celu. A ponieważ każde dyskretne zadanie jest izolowane, wyskakiwanie, podłączanie i przestawianie węzłów (operacji) na różne cele jest banalne. Zapewnia to łatwość konserwacji.

Mario T. Lanza
źródło
2

Czytelny i łatwy do utrzymania kod: Kod, który na pierwszy rzut oka programista rozumie wystarczająco dobrze, aby móc:

  • użyj go ponownie za pośrednictwem interfejsu lub
  • debuguj, lub
  • zmienić swoje zachowanie. (dodaj / usuń funkcję) lub
  • zoptymalizuj to
  • Sprawdź to

Sprowadza się to do „przejrzystości”. tzn. ile pytań programiści muszą zadać konkretnemu segmentowi kodu, zanim będą pewni, że „rozumieją, co robi wystarczająco dobrze”, aby zrealizować bieżące zadanie bez powodowania nieoczekiwanych efektów ubocznych.

Książka „Code Complete, autor: Steve McConnell” porusza ten temat bardzo szczegółowo.

Przegląda różne mierniki, których można użyć, aby ustalić, czy kod jest dobrej jakości.

Zobacz przykład tutaj: http://books.google.co.uk/books?id=3JfE7TGUwvgC&lpg=PT376&pg=PT389#v=onepage&q&f=false

rev. JW01
źródło
wydaje się, że nie dodaje to nic istotnego w stosunku do punktów przedstawionych i wyjaśnionych we wcześniejszych odpowiedziach
gnat
Myślę, że jedną z najważniejszych rzeczy, które dodaje, jest odniesienie do Code Complete, o którym nie wspomina żadna poprzednia odpowiedź. Ta książka jest jedną z najbardziej znaczących i wpływowych książek, która koncentruje się na pisaniu czytelnego i łatwego do utrzymania kodu. Każdy, kto przeczytał tę książkę, nie musiałby pytać: „Skąd wiedziałbyś, że napisałeś czytelny i łatwy do utrzymania kod?”.
JW01,
... stąd, moim zdaniem, uważam, że najlepszą rzeczą, jaką każdy może uzyskać, jeśli jest naprawdę zainteresowany pisaniem łatwego do utrzymania kodu, jest przeczytanie tej książki. Dlatego przy wielu minutach dokładnego przemyślenia (które są często o wiele więcej przemyślane niż moderatorzy SO), myślę, że jest to nie tylko odpowiednia odpowiedź na pytanie PO, ale najlepsza .
JW01,
2

Minimalizuj skutki uboczne (najlepiej nie mają żadnych)

Funkcja, która powoduje 3 zmiany stanów poza swoim zakresem, jest znacznie trudniejsza do uzasadnienia i utrzymania niż ta, która po prostu wprowadza coś i wyprowadza coś innego. Nie możesz po prostu wiedzieć, co robi funkcja, musisz pamiętać, co ona zrobiła i jak to wpływa na wszystkie inne istotne funkcje.

Dla OOP minimalizacja skutków ubocznych oznacza także klasy z mniejszą liczbą członków, a zwłaszcza mniejszą liczbą członków, którzy mogą modyfikować stan klasy, ponieważ funkcje składowe mogą modyfikować stany poza własnymi i wywoływać skutki uboczne (mogą np. Manipulować wewnętrznymi elementami klasy). Oznacza to również klasy z mniejszą liczbą własnych elementów danych, dzięki czemu metody te mają mniejszy wpływ i mniej skutków ubocznych, które mogą powodować.

Jako prosty przykład wyobraź sobie próbę zaprojektowania fantazyjnej struktury danych, która może utrzymywać sortedstan, którego używa do określania, czy należy wyszukiwać binarnie czy liniowo. W takim przypadku przydatne może być podzielenie projektu na dwie klasy. Wywołanie sortednieposortowanej klasy może wówczas zwrócić strukturę danych innej klasy, która zawsze utrzymuje posortowaną zawartość. Teraz masz mniej skutków ubocznych (a więc mniej podatnych na błędy i łatwiejszy do zrozumienia kodu), a także kod o szerszym zastosowaniu (poprzedni projekt byłby marnotrawny zarówno w przetwarzaniu, jak i ludzkiej wydajności intelektualnej w przypadku małych tablic, które nigdy nie muszą być sortowane).

Unikaj zbędnych zewnętrznych zależności

Możesz być w stanie zaimplementować najbardziej zwięzły kod, jaki można sobie wyobrazić, przy maksymalnym ponownym użyciu kodu, używając 13 różnych bibliotek do wykonania stosunkowo prostego zadania. Przenosi to jednak na czytelników koszty intelektualne, zmuszając ich do zrozumienia przynajmniej części 13 różnych bibliotek. Ta wrodzona złożoność powinna być natychmiast doceniona przez każdego, kto próbował zbudować i zrozumieć bibliotekę strony trzeciej, która wymagała wciągnięcia i zbudowania kilkunastu innych bibliotek do funkcjonowania.

Jest to prawdopodobnie bardzo kontrowersyjny pogląd, ale wolałbym trochę skromnego powielania kodu od przeciwnej skrajności, pod warunkiem, że wynik końcowy zostanie dobrze przetestowany (nic gorszego niż niesprawdzony wadliwy kod wielokrotnie powielany). Jeśli do wyboru jest 3-liniowy duplikat kodu do obliczenia wektorowego produktu krzyżowego lub pobranie epickiej biblioteki matematycznej tylko po to, by zgolić 3 linie kodu, sugerowałbym tę pierwszą, chyba że cały zespół jest zaangażowany w tę bibliotekę matematyczną , w którym momencie nadal możesz rozważyć napisanie 3 wierszy kodu zamiast 1, jeśli jest to wystarczająco trywialne w zamian za korzyści oddzielenia.

Ponowne użycie kodu jest działaniem równoważącym. Ponowne użycie zbyt wiele i przenosisz złożoność intelektualną w jeden do wielu sposobów, ponieważ w tych 3 wierszach prostego kodu, który zapisałeś powyżej, kosztem jest to, że czytelnicy i opiekunowie muszą zrozumieć znacznie więcej informacji niż 3 linie kodu . Powoduje to również, że kod jest mniej stabilny, ponieważ jeśli zmieni się biblioteka matematyczna, to również może zmienić kod. Ponowne użycie zbyt mało, a także zwielokrotnienie narzutu intelektualnego, a Twój kod przestaje korzystać z centralnych ulepszeń, więc jest to działanie równoważące, ale warto wspomnieć o tym, że jest to działanie równoważące, ponieważ próba wyeliminowania każdej najmniejszej formy skromnego powielania może prowadzić do wyniku, który jest tak trudny do utrzymania, jeśli nie większy, niż przeciwna skrajność.

Przetestuj bzdury

To jest pewne, ale jeśli twój kod nie obsługuje wszystkich przypadków wejściowych i pomija niektóre przypadki skrajne, to jak możesz oczekiwać, że inni zachowają napisany przez ciebie kod, którego nawet nie dostałeś przed przesłaniem go do oczu i rąk? Wystarczająco trudno jest wprowadzić zmiany w kodzie, który działa idealnie, nie mówiąc już o kodzie, który nigdy nie był całkiem właściwy.

Ponadto kod, który przechodzi gruntowne testy, zwykle znajdzie mniej powodów do zmiany. Odnosi się to do stabilności, która jest jeszcze bardziej świętym Graalem do osiągnięcia niż do utrzymania, ponieważ stabilny kod, którego nigdy nie trzeba zmieniać, nie wiąże się z żadnymi kosztami utrzymania.

Dokumentacja interfejsu

Jeśli nie możesz poświęcić równego czasu na dokumentowanie obu, nadaj priorytet „tym, co robią” nad „tym, jak to robią”. Przejrzysty interfejs, który jest oczywisty w swoich zamiarach dotyczących tego, co zrobi (a przynajmniej, co powinien zrobić) we wszystkich możliwych przypadkach wejściowych, zapewni przejrzystość kontekstu dla jego własnej implementacji, która pomoże zrozumieć nie tylko, w jaki sposób korzystać z kodu, ale także jak to działa.

Tymczasem kod, który nie ma tych cech, w którym ludzie nawet nie wiedzą, co powinien zrobić, jest SOL bez względu na to, jak dobrze udokumentowane są szczegóły jego implementacji. 20-stronicowy podręcznik implementacji kodu źródłowego jest bezwartościowy dla osób, które nawet nie potrafią dokładnie ustalić, w jaki sposób powinien on być użyty w ogóle i co powinien zrobić we wszystkich możliwych scenariuszach.

Po stronie implementacji priorytetowo udokumentuj to, co robisz inaczej niż wszyscy inni. Na przykład Intel ma ograniczoną hierarchię woluminów dla swoich jąder raytracingu. Ponieważ pracuję w tej dziedzinie, mogę szybko rozpoznać większość tego, co robi ich kod, bez konieczności przeszukiwania dokumentacji. Robią jednak coś wyjątkowego, co polega na przemierzaniu BVH i równoległym wykonywaniu skrzyżowań przy użyciu pakietów promieni . Właśnie tam chcę, aby priorytetowo traktowali swoją dokumentację, ponieważ te części kodu są egzotyczne i niezwykłe z większości historycznych implementacji BVH.

Czytelność

Ta część jest bardzo subiektywna. Nie dbam tak bardzo o czytelność, która jest bliska procesom myślowym człowieka. Najbardziej dobrze udokumentowany kod opisujący rzeczy na najwyższym poziomie nadal jest dla mnie trudny do naśladowania, jeśli autor używa dziwnych i skomplikowanych procesów myślowych do rozwiązania problemu. Tymczasem zwięzły kod używający 2 lub 3 znaków może często być dla mnie łatwiejszy do zrozumienia, jeśli logika jest bardzo prosta. Myślę, że możesz przejrzeć recenzję i zobaczyć, co wolą inni ludzie.

Najbardziej interesuje mnie łatwość utrzymania, a co ważniejsze, stabilność. Kod, który nie znajduje powodów do zmiany, to taki, który ma zerowe koszty utrzymania.

user204677
źródło
1

Powiedziałbym, że jednym ze sposobów byłoby wiedzieć, czy nowi członkowie zespołu mogą pobrać kod, zrozumieć go i zmodyfikować, aby naprawić usterki / spełnić nowe wymagania ze względną łatwością.

FrustratedWithFormsDesigner
źródło
1

Oto technika, którą lubię stosować:

Pokaż kod jednemu z programistów równorzędnych i poproś go o wyjaśnienie, co robi. Uważaj na te rzeczy.

1) Jeśli nie są w stanie łatwo wyjaśnić celu bloku kodu, należy go refaktoryzować.
2) Jeśli muszą przeskoczyć do innej sekcji kodu, aby zrozumieć bieżącą sekcję, przeprowadź ją ponownie.
4) Za każdym razem, gdy poczujesz potrzebę przemawiania w trakcie procesu, ta część kodu wymaga refaktoryzacji. (Kod nie mówi sam za siebie).

JohnFx
źródło
Zakładając, że programista równorzędny jest co najmniej jednakowo doświadczony i wczytuje się w język programowania i jego idiomy. Często takie techniki mogą prowadzić do tego, że ludzie piszą kod w podzbiorze wyrazistości języka w nieudanej próbie uczynienia int zrozumiałym nawet dla najbardziej młodszego członka zespołu. W rezultacie powstaje większa część kodu w stępionym podzbiorze języka. I bez względu na to, jak bardzo ogłupiłeś ten podzbiór językowy, 500KLOC kodu małego podzbioru języka zawsze będzie wymagało więcej pracy niż utrzymanie kodu 200KLOC, który używa bardziej wyrazistego podzbioru.
user1703394,
wydaje się to jedynie powtórzeniem tego, co zostało powiedziane w górnej odpowiedzi
komnata
-1

Najbardziej konserwowalnym kodem jest kod, którego nie ma. Zamiast więc dodawać do liczby LOC nowy kod, który „zmniejsza” liczbę LOC (nawet jeśli jest nieco trudniejszy do utrzymania, gdy oglądany jest w izolacji), może sprawić, że cała baza kodu będzie łatwiejsza w utrzymaniu, po prostu poprzez zmniejszenie jej rozmiaru. Zatem podstawowa reguła dla utrzymywalnego kodu:

  • zmaksymalizować OSUSZANIE.

Po drugie, nie ma nic gorszego w utrzymywalności niż ukryte zależności. Tak więc dla reguły numer 2:

  • Wyraź wyraźnie wszystkie swoje zależności.

Po trzecie, nie wszyscy programiści są równie wykwalifikowani w utrzymywaniu lub pisaniu przy użyciu specyficznych, bardziej zaawansowanych technik języka lub idiomów. Ogłuszenie całej bazy kodu da ci dużą bazę kodu, która ze względu na swój rozmiar jest trudna do utrzymania. Zezwalanie na funkcje i idiomy zaawansowanych technik w całym kodzie sprawią, że cały kod będzie obsługiwany tylko przez starszych programistów, co również jest złe. Kluczem do utrzymania jest warstwowanie oparte na poziomie umiejętności Na przykład:

Biblioteki między projektami: seniorzy, pełny kod sztuczek kod / idiom / techniki Biblioteki specyficzne dla projektu i backend systemu: średni deweloperzy, unikaj najbardziej zaawansowanych i trudnych do wyjaśnienia rzeczy. Seniorzy przejdą przez ten kod w poszukiwaniu możliwości ulepszenia SUCHEGO.

Front-end: młodsi deweloperzy, używaj ścisłego przewodnika po stylu i zestawu technik konstruktorów językowych i idiomów, których należy unikać. Medior devs przejdzie przez ten kod w poszukiwaniu SUCHYCH możliwości i ukrytej logiki biznesowej.

Tak więc dla reguły numer 3:

  • Warstwuj kod według poziomu umiejętności programisty i odpowiednio pisz kod, który można utrzymać.

ja

użytkownik1703394
źródło
1
wydaje się, że nie oferuje to nic istotnego w porównaniu z punktami przedstawionymi i wyjaśnionymi w poprzednich 25 odpowiedziach
komnata
@gnat, miałem nadzieję dodać „niuans” do wielu (potencjalnie szkodliwych) uproszczeń w innych odpowiedziach. Zwłaszcza w punkcie 3.
user1703394 15.01.15
1
@ user1703394 to pytanie i jego odpowiedzi są wiki społeczności. Jeśli uważasz, że istniejącą odpowiedź można poprawić, możesz ją edytować nawet bez uprawnienia „edytuj posty innych użytkowników”.
-2

Nigdy nie jest zbyt łatwo pisać czytelny i łatwy w utrzymaniu kod, ale nie jest trudno napisać łatwy i łatwy do utrzymania kod.

OOAD to czteroliterowe słowo, ale trudno je zrozumieć za jednym razem - podążaj za obiektową analizą i projektowaniem

  1. Zawsze zaczynaj od dobrego zebrania wymagań i dokładnego opisu problemu

    • zacznij od kilku przypadków użycia, tj. Interakcja dialogu system-użytkownik
  2. Musisz utrzymywać luźne sprzężenie obiektów i upewnić się, że kod się nie powtórzy - postępuj zgodnie z DRY [Nie powtarzaj się]

    • za każdym razem, gdy zobaczysz duplikat, poszukaj miejsca do enkapsulacji
  3. Twój kod jest otwarty do rozszerzenia i zamknięty do modyfikacji - OCP [Zasada otwartego zamknięcia]
  4. Kiedy zmieniasz swój kod, zawsze pamiętaj - Nie twórz problemów w celu rozwiązania problemów, informatorzy po prostu nie modyfikują twojej istniejącej funkcjonalności
  5. Testuj swój kod jednostkowy
    • zawsze testuj kod, gdy coś pójdzie nie tak
  6. Podczas pracy nad funkcjonalnością zawsze pamiętaj o przestrzeganiu podstawowych zasad OOP (obiektowych zasad) i technik, aby upewnić się, że twoja aplikacja jest dobrze zaprojektowana od samego początku
    • Obiekty powinny robić to, co wskazuje ich nazwa
    • Każdy obiekt powinien reprezentować jedną koncepcję
  7. Zawsze pamiętaj o problemie systemu oraz o tym, w jakim oprogramowaniu działa kontekst / domena
  8. Zrób też papierkową robotę - tak, to działa dla mnie
    • niektóre wydruki związane z interfejsem użytkownika i diagramy UML zawsze działają
    • możesz nawet zrobić zrzuty ekranu z burzy mózgów z białej tablicy
  9. Układy architektury
  10. W miarę możliwości zastosuj zasady projektowania
  11. Dokumentacja
    • zawsze dokumentuj swój kod
    • ustaw wcięcie w IDE i również to udokumentuj
Narender Parmar
źródło
1
To teoria, która nie odpowiada na pytanie: W jaki sposób kwantyfikujemy lub mierzymy jakość kodu, abyśmy wiedzieli, że jest on czytelny, zrozumiały i możliwy do utrzymania? pytanie
Jan Doggen,
Zgoda !! ale jeśli przestrzegamy wyżej wymienionych zasad, łatwo jest zmierzyć jakość kodu, jest czytelny, zrozumiały i oczywiście łatwy w utrzymaniu. Popraw mnie, jeśli się mylę.
Narender Parmar
Nie wiem, dlaczego moja odpowiedź została odrzucona, nawet ja już
omawiam