🚀 go-pugleaf

Użytkownik "Przemek Pokrywka" <adres@zastrzezony.com> napisał w wiadomości 
news:e7h9l6$1pq$1@news.onet.pl...
> Witam,
>
> Czy zdarzają się Państwu sytuacje, w których pozbycie się duplikacji kodu 
> jest niemożliwe?
> Ile duplikacji kodu w projekcie Państwo tolerują?

Powiem odrobinę z mojej praktyki na temat redundancji funkcjonalności
(nie jest to jeszcze "duplikacja kodu", no ale mamy dwie funkcje, które 
robią to samo
- choć mogą być inaczej zaimplementowane - i raczej nie powstają na zasadzie 
copy-paste).

Generalnie kod w dużym projekcie dzielę na dwa obszary: kod wynikający 
bezpośrednio
ze specyfikacji i projektu, czyli "kod przewidziany" oraz kod wynikający z
"bieżących potrzeb programisty", czyli kod tworzony przez programistę w 
związku z
jego indywidualnymi zmaganiami przy podejściu do jakiegoś większego problemu
(funkcje i klasy narzędziowe, pomocnicze, rozbicia funkcji wyspecyfikowanych 
na
mniejsze elementy itp). Praktyka jest taka: na poziomie specyfikacji i 
projektu
nie powinno być redundancji, stąd nie powinno być redundancji w funkcjach
z obszaru pierwszego. Dużą część odpowiedzialność za poprawność logiczną 
tego
obszaru biorą analitycy. Natomiast jeśli chodzi o obszar drugi - bywa wręcz 
odwrotnie.
Jest prosta zasada: nie korzystaj z cudzego kodu (bezpośrednio, czyli przez 
wywołanie),
jeśli nie został on zaplanowany. A dlaczego ? Dlatego, że w praktyce własne 
funkcje
różnych programistów są słabo opisane (udokumentowane) i generalnie ich 
autor bierze
odpowiedzialność za poprawne ich działanie w całości, a nie jako 
pojedynczych, wyrwanych
z kontekstu elementów. Autor ma też prawo te funkcje modyfikować i rozwijać 
mając na
uwadze SWOJE potrzeby a nie potrzeby innych programistów.
Dzięki takiemu postawieniu sprawy powstaje redundancja, ale minimalizujemy 
problem
rozmycia odpowiedzialności za działanie większych elementów, szczególnie w 
obliczy
wprowadzanych licznie zmian.
Oczywiście w tle funkcjonuje proces wynoszenia funkcji narzędziowych do
specyfikacji/projektu lub czegoś co funkcjonuje na pograniczu (dobrze 
opisane
typowe funkcje narzędziowe), jeśli redundancja zaczyna zbytnio kłuć w oczy 
lub z innych
powodów. Generalnie zawsze trzeba brać pod uwagę problem: kto ma brać 
odpowiedzialność
za porządek i stabilność elementów współdzielonych oraz analizować jakie 
zmiany w tych
elementach są bezpieczne.