Czy praktyki „czystego kodu” są naprawdę tak czyste i przydatne? [Zamknięte]

Obecnie odbywam staż w dużej korporacji, która przechodzi wiele zmian w strukturze dostarczania oprogramowania (przejście na Agile).

W ciągu ostatnich kilku miesięcy zauważyłem to religijne przywiązanie do Clean Codepraktyk, a książka jest jak biblia dla programistów.

Jedną z najważniejszych cech czystego kodu jest samoujaśniający się kod, który opiera się na zrozumiałym nazewnictwie i rygorystycznym ponownym faktorowaniu. Następnie no commentingobowiązuje reguła.

Rozumiem, że ten czysty kod jest inwestycją długoterminową, która ułatwi utrzymanie i ulepszanie kodu, ale ... czy to naprawdę jest warte tyle zamieszania?

Czy ktoś podzieliłby się swoim doświadczeniem na temat Clean Code i jakąkolwiek opinią, czy jestem po prostu zbyt konserwatywny, czy to tylko tymczasowy trend.

programming-practices agile clean-code

— Arturs Vancans
źródło

Wiele dobrych pytań generuje pewien stopień opinii w oparciu o doświadczenie ekspertów, ale odpowiedzi na to pytanie będą zwykle prawie w całości oparte na opiniach, a nie na faktach, referencjach lub konkretnej wiedzy specjalistycznej.

— komar

Nie mam bardzo wysokiej opinii o tej książce (pomimo jej autora). Ogólnie rzecz biorąc, opłaca się nie być zbyt dogmatycznym. Większość rekomendacji programowych wynika z tego, że zostały sprawdzone w praktyce, ale nie są absolutną prawdą, więc nie przejmuj się zbytnio. Czytaj dalej i idź z tym, co według ciebie jest bardziej poprawne, ale nie wymyślaj ponownie koła. Szanse są ktoś mądrzejszy od nas już wymyślił lepsze rozwiązania niż nasze własne.

— DPM,

Metoda o nazwie 70 znaków prawdopodobnie robi więcej niż jedną rzecz. Naruszenie SRP mam rację ?!

— Tombatron

Oto kolejna myśl, za 5 lub 10 lat, kiedy jesteś programistą w firmie, która nie dba o czysty kod, naprawdę docenisz to dogmatyczne ćwiczenie.

— Tombatron

Pracując (krótko) pod „bez komentarzy”, bardzo wolę, aby była to silna wskazówka niż zasada. Są chwile, kiedy potrzebne są komentarze - zwykle w niejasnej logice biznesowej. Wywołana metoda CalculateFoonicityMetric()mówi dokładnie, co robi, a dobrze napisany kod pokaże, jak ... ale żadna z nich nie wyjaśnia dlaczego . Kod może być oczywisty w czym (pomnóż to, podziel przez drugą rzecz, wyprostuj, dodaj ten bit ...), ale nie jest jasne, dlaczego (współczynnik = a * b / c; kwadrat, aby uwzględnić ujemne foo, dostosuj do driftu ...). Doceniam szybki komentarz wyjaśniający dlaczego.

— anaximander

Odpowiedzi:

Rozumiem, że ten czysty kod jest inwestycją długoterminową, która ułatwi utrzymanie i ulepszanie kodu, ale ... czy to naprawdę jest warte tyle zamieszania?

Absolutnie.

Ponowne faktoring jest bardzo ważne, ale wydaje się, że spędzanie 75% czasu na przenoszeniu metod i poświęcanie dużej ilości czasu na określenie jego właściwego tytułu nie jest tak produktywne.

Jasne, ale weź pod uwagę, że duża firma prawdopodobnie ma lata lub dekady złego kodu do wyczyszczenia. Zajmie to dużo czasu i wysiłku.

Najważniejszą rzeczą do zrozumienia jest to, że oboje macie rację. „czysty kod” jest bardzo ważny, a Clean Code to powszechnie szanowany sposób na dotarcie tam. Ponieważ firma właśnie rozpoczęła swoją działalność na ścieżce, będą bardziej zainteresowani książką niż grupą z większym doświadczeniem. Gdy zrobią to krótko, zaczną się uczyć, co działa, a co nie. Kiedy zrozumieją to lepiej, (miejmy nadzieję) zastosują bardziej pragmatyczne i naturalne podejście, które utrzymuje czysty kod, ale nie prowadzi do nazw funkcji 70 char.

— Telastyn
źródło

Pierwotnie pisałem komentarz. Spróbuję dać mniej odpowiedzi niż perspektywy do rozważenia. Jednak absolutnie popieram praktyki „czystego kodu”, takie jak zrozumiałe nazewnictwo i refaktoryzacja.

Zawsze nie lubiłem reguł braku komentarzy , ponieważ są przypadki, w których komentarze są konieczne, aby zapobiec łamaniu kodu w przyszłości. Zwykle powinny być ograniczone do tego, co jest robione i dlaczego. Używaj ich oszczędnie, gdy kod robi coś nieoczekiwanego lub algorytm wymaga wymiany.

Weź pod uwagę produktywność podczas czytania lub utrzymywania kodu. Podczas życia kodu może to być ważniejsze niż produktywność podczas pisania kodu. Czy te praktyki pomogą zwiększyć wydajność w tych zadaniach?

Z doświadczeniem praktyki te powinny się zakorzenić, a nie zabijać produktywności. Wybór właściwej nazwy może potrwać dłużej, ponieważ wyjaśniasz, co powinien zrobić kod. (To wyjaśnienie może przyspieszyć kodowanie i debugowanie). Czy to powoduje, że kod wykonuje tylko to, co jest wymagane lub zawiera mniej błędów? Jaki to ma wpływ na wydajność?

Czas poświęcony na wybranie właściwej nazwy metody prawdopodobnie natychmiast się zwróci, aby lepiej zrozumieć cel tej metody. Porównaj nazwy metod „iterateOverCustomers” z „locateActiveCustomers”. Który przekazuje zamiar funkcji? Który z nich będzie łatwiej refaktoryzować, jeśli to konieczne?

— BillThor
źródło

Chciałbym zauważyć, że reguła „bez komentarzy”, którą ludzie lubią przypisywać książce Clean Code, tak naprawdę nigdzie w niej nie ma. Wręcz przeciwnie, cały rozdział poświęcony jest komentarzom, z czego pierwsza połowa poświęcona jest opisowi wielu rodzajów „dobrych komentarzy”, a następnie sekcja „złych komentarzy”. Opinie autora na ten temat są w rzeczywistości dużo rozsądniejsze, niż wielu przypisuje mu uznanie.

— Eric King,

Komentowałem ogólnie zasady „bez komentarzy”. Pracowałem w językach, w których pojawiły się propozycje usunięcia komentarzy z definicji języka. Brak komentarzy dobrych lub złych. W tym czasie mieliśmy komentarz w bloku kodu, w którym w niektórych przypadkach pożądane było przewrócenie się. Pojawił się komentarz z ostrzeżeniem, że tak właśnie jest i nie dodawać nowych bloków kodu w tym momencie.

— BillThor,

Tak, to wydaje mi się dość ekstremalne.

— Eric King,