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.
źródło
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.Odpowiedzi:
Absolutnie.
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.
ź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?
źródło