Podsumowanie
Jak pisze JacquesB, nie wszyscy zgadzają się z „Czystym kodem” Roberta C. Martina.
Projekty open source, które według ciebie „naruszają” zasady, których się spodziewałeś, mogą po prostu mieć inne zasady.
Moja perspektywa
Zdarza mi się nadzorować kilka baz kodu, które są bardzo zgodne z zasadami Roberta C. Martina. Jednak tak naprawdę nie twierdzę, że mają rację , mogę tylko powiedzieć, że działają dobrze dla nas - i że „my” jest w rzeczywistości kombinacją przynajmniej
- zakres i architektura naszych produktów,
- rynek docelowy / oczekiwania klientów,
- jak długo produkty są utrzymywane,
- stosowana przez nas metodologia rozwoju,
- struktura organizacyjna naszej firmy i
- zwyczaje, opinie i doświadczenia naszych programistów.
Zasadniczo sprowadza się to do: każdy zespół (czy to firma, dział czy projekt open source) jest wyjątkowy. Będą mieli różne priorytety i różne punkty widzenia, i oczywiście dokonają różnych kompromisów. Te kompromisy i wynikający z nich styl kodu są w dużej mierze kwestią gustu i nie można udowodnić, że są „złe” lub „właściwe”. Zespoły mogą tylko powiedzieć „robimy to, ponieważ to działa dla nas” lub „powinniśmy to zmienić, ponieważ to nie działa dla nas”.
To powiedziawszy, uważam, że aby móc z powodzeniem utrzymywać duże bazy kodu przez lata, każdy zespół powinien uzgodnić zestaw konwencji kodu, które ich zdaniem są odpowiednie dla powyższych aspektów. Może to oznaczać stosowanie praktyk Roberta C. Martina przez innego autora lub wymyślanie własnych; może to oznaczać ich formalne zapisanie lub udokumentowanie „przez przykład”. Ale powinny istnieć.
Przykład
Rozważ praktykę „dzielenia kodu z długiej metody na kilka metod prywatnych”.
Robert C. Martin mówi, że ten styl pozwala na ograniczenie zawartości każdej metody na jednym poziomie abstrakcji - w uproszczonym przykładzie, sposób publiczny będzie składać się prawdopodobnie tylko do rozmów prywatnych metod, takich jak verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)i wreszcie sendJsonToClient(...), a metody te musiałyby szczegóły wdrożenia.
- Niektórym się to podoba, ponieważ czytelnicy mogą uzyskać szybki przegląd kroków wysokiego poziomu i wybrać, o których szczegółach chcą przeczytać.
- Niektórym się to nie podoba, ponieważ jeśli chcesz poznać wszystkie szczegóły, musisz przeskakiwać w klasie, aby śledzić przebieg wykonywania (o tym prawdopodobnie mówi JacquesB, gdy pisze o zwiększaniu złożoności).
Lekcja jest taka: wszystkie mają rację, ponieważ mają prawo do wyrażenia opinii.