🚀 go-pugleaf

Przemek Pokrywka napisał(a):
> 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ą?
> 
> Przemysław Pokrywka

co??? ale o co chodzi?

sg napisał(a):
> co??? ale o co chodzi?
copy & paste programming

Przemek Pokrywka napisał(a):
> sg napisał(a):
>> co??? ale o co chodzi?
> copy & paste programming

no i co? ile razy pozwalam sobie kopiować kod w programie???

Użytkownik "sg" <alpha@skynet.org.pl_WITHOUT> napisał w wiadomości 
news:e7he68$nph$1@inews.gazeta.pl...
<cite>
> sg napisał(a):
>> co??? ale o co chodzi?
> copy & paste programming

no i co? ile razy pozwalam sobie kopiować kod w programie???

</cite>

Istnieje pewna zależność:

copy / paste = duplikowanie kodu = duplikowanie błędów = konieczność 
nanoszenie tych samych poprawek w wielu miejscach = problemy z utrzymaniem 
kodu

Z jednej strony nie ma sensu unikanie duplikowania poszczególnych 
instrukcji, z drugiej strony nie powinno się duplikować dużych komponentów. 
Przemek pytał zapewne gdzie jest Wasz złoty środek.

Pozdrawiam
Grzegorz 

Witam

Przemek Pokrywka wrote:

> 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ą?

Ustaliłbym luźną granice na 2 do 3, ale istotnie skomentowane dlaczego tak, a
nie inaczej i ile tego kodu jest skopiowane, bo jak dużo, to lepiej w cale nie
kopiować. Czasem odwołanie się gdzies daleko do kawałka kodu jest trudne. Więc
kopiowanie może mieć sens.

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

"Grzegorz Danowski" <gdn__na@serwerze__poczta.onet.pl> writes:

> Użytkownik "sg" <alpha@skynet.org.pl_WITHOUT> napisał w wiadomości
> news:e7he68$nph$1@inews.gazeta.pl...
> <cite>
>> sg napisał(a):
>>> co??? ale o co chodzi?
>> copy & paste programming
>
> no i co? ile razy pozwalam sobie kopiować kod w programie???
>
> </cite>
>
> Istnieje pewna zależność:
>
> copy / paste = duplikowanie kodu = duplikowanie błędów = konieczność
> nanoszenie tych samych poprawek w wielu miejscach = problemy 
> z utrzymaniem kodu
>
> Z jednej strony nie ma sensu unikanie duplikowania poszczególnych
> instrukcji, z drugiej strony nie powinno się duplikować dużych
> komponentów. Przemek pytał zapewne gdzie jest Wasz złoty środek.

Złoty środek leży zwykle tam, gdzie jego miejsce.

On Fri, 23 Jun 2006 19:50:10 +0200, Przemek Pokrywka
<adres@zastrzezony.com> wrote:

>Witam,
>
>Czy zdarzają się Państwu sytuacje, w których pozbycie się duplikacji 
>kodu jest niemożliwe?

Nie

>Ile duplikacji kodu w projekcie Państwo tolerują?

Zero

A.L.

A.L. napisał:
>>Czy zdarzają się Państwu sytuacje, w których pozbycie się duplikacji 
>>kodu jest niemożliwe?
> 
> Nie
> 
>>Ile duplikacji kodu w projekcie Państwo tolerują?
> 
> Zero

Szczere wyrazy mojego uznania! A dla uzupełnienia:
- w jaki sposób wykrywacie Państwo duplikację kodu (narzędzie)?
- jaki próg czułości ma ustawione to narzędzie? Chodzi mi o liczbę 
znaczących identycznych tokenów, które muszą się powtórzyć, żeby 
narzędzie oznaczyło to jako duplikację - względnie o inną podobną miarę, 
jeśli użyty jest inny algorytm wykrywania duplikacji.

Przemysław Pokrywka

On Sun, 25 Jun 2006 10:42:37 +0200, Przemek Pokrywka
<adres@zastrzezony.com> wrote:

>A.L. napisał:
>>>Czy zdarzają się Państwu sytuacje, w których pozbycie się duplikacji 
>>>kodu jest niemożliwe?
>> 
>> Nie
>> 
>>>Ile duplikacji kodu w projekcie Państwo tolerują?
>> 
>> Zero
>
>Szczere wyrazy mojego uznania! A dla uzupełnienia:
>- w jaki sposób wykrywacie Państwo duplikację kodu (narzędzie)?
>- jaki próg czułości ma ustawione to narzędzie? Chodzi mi o liczbę 
>znaczących identycznych tokenów, które muszą się powtórzyć, żeby 
>narzędzie oznaczyło to jako duplikację - względnie o inną podobną miarę, 
>jeśli użyty jest inny algorytm wykrywania duplikacji.
>

My nie jestesmy tacy sophisticated. My pracujemy w zacofanej Ameryce
i zadnych takich tooli nie wykorzystujemy. Toole kosztuje pieniadze
i zajmuja za duzo czasu. My to wykrywamy przy pomocy "code review".
Czyli "na oko".

A.L.

P.S. Wedle statystyk, USA traci rocznie okolo biliona
(amerykanskiego) dolarow na stratach zwiazanych z tym ze pracownicy
starannie dobieraja formaty w memorandach pisanych pod Wordem i
robieniu ladnych ramek w Excelu. Podejrzewam ze traci ze dwa razy
tyle (albo by tracila) na uzywaniu "tooli" wykrywajacych "tokeny"

A.L. napisał(a):
>>- w jaki sposób wykrywacie Państwo duplikację kodu (narzędzie)?
>>- jaki próg czułości ma ustawione to narzędzie? Chodzi mi o liczbę 
>>znaczących identycznych tokenów, które muszą się powtórzyć, żeby 
>>narzędzie oznaczyło to jako duplikację - względnie o inną podobną miarę, 
>>jeśli użyty jest inny algorytm wykrywania duplikacji.
> 
> My nie jestesmy tacy sophisticated. My pracujemy w zacofanej Ameryce
> i zadnych takich tooli nie wykorzystujemy. Toole kosztuje pieniadze
> i zajmuja za duzo czasu. My to wykrywamy przy pomocy "code review".
> Czyli "na oko".

Uuuu Panie A.L. "na oko", to, jak się mówi "chłop w szpitalu umarł" - "z 
brudem za paznokciem" jak dodają niektórzy. Integracja toola do 
wykrywania duplikacji kodu w Mavenie to dopisanie linijki w project.xml 
i nie kosztuje to ani centa (maven i jego odpowiednie pluginy są za 
darmo). Potem całą pracę wykonuje build server (zazwyczaj po każdym 
check-in), co na ogół kosztuje ułamek procenta rachunku za energię 
elektryczną. Development i management mają za to na ładnej stronce 
webowej czytelne raporty o tym, co jest zduplikowane, w ilu kopiach i 
gdzie. To chyba pewniejsza i _mniej_ czasochłonna metoda, niż (skądinąd 
o wartości nie do podważenia) code reviews.

 > P.S. Wedle statystyk, USA traci rocznie okolo biliona
 > (amerykanskiego) dolarow na stratach zwiazanych z tym ze pracownicy
 > starannie dobieraja formaty w memorandach pisanych pod Wordem i
 > robieniu ladnych ramek w Excelu. Podejrzewam ze traci ze dwa razy
 > tyle (albo by tracila) na uzywaniu "tooli" wykrywajacych "tokeny"

Właśnie - proszę zwrócić uwagę, że w tej sytuacji to _pracownicy_ (a nie 
narzędzia typu Maven) dobierają te formaty. Realizacja danej czynności 
przez program komputerowy obniża te koszty praktycznie do zera.
Inna sprawa to koszta nadzoru nad takimi programami, ale i tak jestem 
zdania, że w konkretnym zastosowaniu wykrywania duplikacji kodu opłaca 
się je ponieść (skoro nie tolerują Państwo duplikacji kodu, to wie Pan 
raczej dlaczego).

Przemysław Pokrywka

On Sun, 25 Jun 2006 18:39:55 +0200, Przemek Pokrywka
<adres@zastrzezony.com> wrote:
 
>
>Uuuu Panie A.L. "na oko", to, jak się mówi "chłop w szpitalu umarł" - "z 
>brudem za paznokciem" jak dodają niektórzy. Integracja toola do 
>wykrywania duplikacji kodu w Mavenie to dopisanie linijki w project.xml 
>i nie kosztuje to ani centa (maven i jego odpowiednie pluginy są za 
>darmo). Potem całą pracę wykonuje build server (zazwyczaj po każdym 
>check-in), co na ogół kosztuje ułamek procenta rachunku za energię 
>elektryczną. Development i management mają za to na ładnej stronce 
>webowej czytelne raporty o tym, co jest zduplikowane, w ilu kopiach i 
>gdzie. To chyba pewniejsza i _mniej_ czasochłonna metoda, niż (skądinąd 
>o wartości nie do podważenia) code reviews.
>

Wie Pan, my chyba inne programy piszemy, w inny sposob i w innym
srodowisku...

>
>Właśnie - proszę zwrócić uwagę, że w tej sytuacji to _pracownicy_ (a nie 
>narzędzia typu Maven) dobierają te formaty. Realizacja danej czynności 
>przez program komputerowy obniża te koszty praktycznie do zera.
>Inna sprawa to koszta nadzoru nad takimi programami, 

Jaka "inna sprawa"?... Jak dla mnei to raczej fundamentalna. No, ael
Ameryka nie ejst tak bogata jak Polska i liczy kazdy grosz...
eche... cent, chcialem powiedziec.

>ale i tak jestem 
>zdania, że w konkretnym zastosowaniu wykrywania duplikacji kodu opłaca 
>się je ponieść (skoro nie tolerują Państwo duplikacji kodu, to wie Pan 
>raczej dlaczego).

No wlasnie,. Kolejny raz przodujaca technologicznie Polska dala w
dupe zacofanej Ameryce.

A.L.

P.S> Przypomina mi sie moj patent na urzadzenie do zbierania jagod:
akumulator i silny elektromagnes. Tylko przedtem trzeba w kazda
jagode wbic cienka stalowa szpilke.

Przemek Pokrywka napisał(a):
> 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ą?

Ja staram się mieć co najwyżej jeden duplikat.

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

On Mon, 26 Jun 2006 11:10:23 +0200, "Grzesiek G."
<gruza@spamerom_nie.priv4.onet.pl> wrote:

>Przemek Pokrywka napisał(a):
>> 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ą?
>
>Ja staram się mieć co najwyżej jeden duplikat.

A dlaczego nie dwa?...

A.L.

A.L. napisał(a):
> P.S> Przypomina mi sie moj patent na urzadzenie do zbierania jagod:
> akumulator i silny elektromagnes. Tylko przedtem trzeba w kazda
> jagode wbic cienka stalowa szpilke.

Pański przypis bardzo dobrze obrazuje niebezpieczeństwo nadmiernego 
skupienia się na narzędziach, do tego stopnia, że stają się one celem 
samym w sobie :-)

Wydaje mi się jednak, że amerykańscy współautorzy omawianych narzędzi 
zgodzą się z moim twierdzeniem, że cały nadzór nad narzędziem typu 
detektor duplikacji sprowadza się do jego jednorazowego set-upu oraz do 
ewentualnego wykluczania niektórych fragmentów kodu spod jego kontroli 
od czasu do czasu. Jest to moim skromnym zdaniem nakład pracy 
niepomiernie mniejszy, i dający lepsze efekty, niż przeprowadzanie w tym 
celu code reviews.
Jasna sprawa, że do wykrywania duplikacji nigdy nie urządza się 
specjalnych code reviews - wykrywanie duplikacji jest raczej ich efektem 
ubocznym. Jednak m.in. właśnie dlatego narzędzia typu Simian lub CPD 
mają swoją niszę, bo dzięki nim można zidentyfikować miejsca, które 
normalnie zostałyby przeoczone, a usunięcie z nich duplikacji może 
przynieść wymierne zyski.

Jestem sobie jednak w stanie wyobrazić, że temat ten może wyglądać 
diametralnie inaczej, gdy używa się innych narzędzi, metod i środowisk.

Pozwolę sobie tu przy tym na małą reklamę Mavena, jako że jest to 
narzędzie, które zapewnia długoterminowy zwrot z inwestycji. Miałem 
szczęście trafić do zespołu, który go używa i doświadczam na codzień 
zalet jego stosowania.

Przemysław Pokrywka

A.L. wrote:
> On Mon, 26 Jun 2006 11:10:23 +0200, "Grzesiek G."
> <gruza@spamerom_nie.priv4.onet.pl> wrote:
> 
>> Przemek Pokrywka napisał(a):
>>> 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ą?
>> Ja staram się mieć co najwyżej jeden duplikat.
> 
> A dlaczego nie dwa?...
> 
> A.L.
ten jeden chowa do sejfu wrazie gdyby oryginal ulegl uszkodzeniu;)

Pozdrawiam,
ciukes.

Dnia Sun, 25 Jun 2006 15:46:30 -0500, A.L. skrobie:
> On Sun, 25 Jun 2006 18:39:55 +0200, Przemek Pokrywka
> <adres@zastrzezony.com> wrote:
>  
> >
> >Uuuu Panie A.L. "na oko", to, jak się mówi "chłop w szpitalu umarł" - "z 
> >brudem za paznokciem" jak dodają niektórzy. Integracja toola do 
> >wykrywania duplikacji kodu w Mavenie to dopisanie linijki w project.xml 
> >i nie kosztuje to ani centa (maven i jego odpowiednie pluginy są za 
> >darmo). Potem całą pracę wykonuje build server (zazwyczaj po każdym 
> >check-in), co na ogół kosztuje ułamek procenta rachunku za energię 
> >elektryczną. Development i management mają za to na ładnej stronce 
> >webowej czytelne raporty o tym, co jest zduplikowane, w ilu kopiach i 
> >gdzie. To chyba pewniejsza i _mniej_ czasochłonna metoda, niż (skądinąd 
> >o wartości nie do podważenia) code reviews.
> >

> Wie Pan, my chyba inne programy piszemy, w inny sposob i w innym
> srodowisku...

Pan to najwyraźniej w ogóle piszesz "inne programy".

Automatyzację za pomocą narzędzi wykonuje się wszędzie. A jeśli mówisz pan o
robieniu czegokolwiek "na oko" i jednocześnie twiedzisz pan, że masz pan 100%
skuteczność, to pan się delikatnie mówiąc lekko rozmijasz z rzeczywistością.

Zgodzę się skądinąd, że większość narzędzi do weryfikacji kodu, wszelkie
makkejby i klocworki są w dużej mierze o kant dupy rozbić (a kosztują
wściekle). I owszem, nie ma takiego narzędzia, które zastąpiłoby trzeźwo
myślącego inżyniera, kierownika technicznego, który przejrzy kod i potrafi
trafnie zawyrokować, że to jest napisane dobrze, a to jest napisane źle i
trzeba przepisać. Gdyby istniało, dziś programy pisałoby się za pomocą kilku
kliknięć przez przysłowiową sekretarkę, a programistów wysłanoby na zieloną
trawkę, bo przecież niezależnie od tego ile by kosztowały te najwypasieńsze i
najdroższe narzędzia, programista i tak kosztuje o wiele więcej.

> >Właśnie - proszę zwrócić uwagę, że w tej sytuacji to _pracownicy_ (a nie 
> >narzędzia typu Maven) dobierają te formaty. Realizacja danej czynności 
> >przez program komputerowy obniża te koszty praktycznie do zera.
> >Inna sprawa to koszta nadzoru nad takimi programami, 

> Jaka "inna sprawa"?... Jak dla mnei to raczej fundamentalna.

Nie rozśmieszaj pan.

Uczestniczyłem w tworzeniu różnych narzędzi wspomagających pracę, więc z
autopsji wiem, ile kosztuje ich maintenance. Proszę sobie wyobrazić,
przykładowo, że przez okres jednego miesiąca programista tworzy narzędzie
przez 30% swojego czasu, a po jego wypuszczeniu poświęca 5% czasu miesięcznie
na jego maintenance.

A teraz proszę sobie policzyć następujące rzeczy:
1. Dzięki temu narzędziu, 100 programistów (na 500 w całej firmie) oszczędza
5% swojego czasu. To znaczy, może poświęcić 5% więcej czasu na aktywności
związane z bieżącą pracą. I to przez okres co najmniej 6 miesięcy od momentu
ukończenia tworzenia narzędzia.
2. Dzięki temu narzędziu skrócił się czas oczekiwania na ukończenie pewnych
aktywności, od których zależy praca pozostałych ludzi.
3. I wreszcie, narzędzie pozwoliło zmniejszyć ilość błędów powstających
podczas tych czynności z 30% do 2%.

Policz sobie pan teraz, ile co kosztuje. W pieniądzach.

> No, ael
> Ameryka nie ejst tak bogata jak Polska i liczy kazdy grosz...
> eche... cent, chcialem powiedziec.

Jasne. Nie kupujmy nowej pralki, bo ona przecież kosztuje straszne pieniądze,
a liczy się każdy grosz. Przecież można prać ręcznie.

Gdyby każdy myślał tak jak pan, Ameryka by nigdy nie powstała.

> >ale i tak jestem 
> >zdania, że w konkretnym zastosowaniu wykrywania duplikacji kodu opłaca 
> >się je ponieść (skoro nie tolerują Państwo duplikacji kodu, to wie Pan 
> >raczej dlaczego).

> No wlasnie,. Kolejny raz przodujaca technologicznie Polska dala w
> dupe zacofanej Ameryce.

Zacofany to pan jesteś, a nie (na szczęście) Ameryka. Jeśli masz pan
wątpliwości, to przypomnę parę drobnostek:

1. Ponad 50% największych i zajmujących największe obszary światowego rynku
oprogramowania firm softwarowych w Polsce to są firmy-córki utworzone przez
firmy ze Stanów Zjednoczonych.

2. Sposoby zarządzania tą firmą, metodyki procesów i inne pierdoły zostały
wymyślone i opracowane w Stanach i wyłącznie stamtąd zostały zaszczepione w
Polsce.

3. Używanie różnych narzędzi do wspomagania pracy (i to dowolnej branży) to
kwestia decyzji firmy macierzystej, a jej polski oddział dostosowuje się do
tego na zasadzie decyzji, która przyszła z góry. W przypadku przynajmniej
różnych kosztownych narzędzi (jak ClearCase, czy Klocwork) decyzje przychodzą
wyłącznie od góry i firma w Polsce nie ma w ogóle nic w tej kwestii do
powiedzenia.

Nie wykluczam, że jeśli chodzi o sprawy zarówno narzędzi, jak i metodyk
(zwłaszcza Agile), to można na upartego określić to tak, że amerykański
oddział testuje te sprawy na polskich oddziałach jak na myszach.

Można by oczywiście zadać pytanie, dlaczego testują to na Polsce, a nie na
znacznie tańszych Chinach. Odpowiedź prosta: w Polsce te testy najczęściej
przechodzą z sukcesem, w Chinach nie.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

A.L. napisał(a):
> On Mon, 26 Jun 2006 11:10:23 +0200, "Grzesiek G."
> <gruza@spamerom_nie.priv4.onet.pl> wrote:
> 
> 
>>Przemek Pokrywka napisał(a):
>>
>>>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ą?
>>
>>Ja staram się mieć co najwyżej jeden duplikat.

Teraz jak czytam swoją wypowiedź, to widzę, że wyszła bez sensu. Bo 
chodziło mi o to, że staram się nie mieć. Ale jak jest jeden, to nie 
zabieram się od razu do refaktoryzacji, chyba, że przypadek jest ewidentny.

 >
 >
 > A dlaczego nie dwa?...

A jeden, a nie dwa, wynika z doświadczenia. Jak kiedyś starałem się nie 
mieć wogóle, to miałem tendecję do wyodrębniania kodu "na siłę". Potem 
okazywało się, że jednak ten wyodrębniony kod powinien wyglądać inaczej 
w dwóch miejscach. Albo, że wyodrębnianie stawało się celem samym w 
sobie. Stąd ten jeden duplikat.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

ciukes napisał(a):
> A.L. wrote:
> 
>> On Mon, 26 Jun 2006 11:10:23 +0200, "Grzesiek G."
>> <gruza@spamerom_nie.priv4.onet.pl> wrote:
>>
>>> Przemek Pokrywka napisał(a):
>>>
>>>> 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ą?
>>>
>>> Ja staram się mieć co najwyżej jeden duplikat.
>>
>>
>> A dlaczego nie dwa?...
>>
>> A.L.
> 
> ten jeden chowa do sejfu wrazie gdyby oryginal ulegl uszkodzeniu;)

Pod tym względem (kopie zapasowe) dopuszczam znacznie więcej duplikatów. 
Czyżbym dał nieprzemyślaną odpowiedź :-).

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Dnia Fri, 23 Jun 2006 19:50:10 +0200, Przemek Pokrywka skrobie:
> Witam,

> Czy zdarzają się Państwu sytuacje, w których pozbycie się duplikacji 
> kodu jest niemożliwe?

Ja się osobiście nie spotkałem z sytuacją, żeby usunięcie duplikatów było
niemożliwe. Ale spotkałem się z sytuacją, gdy jest nieopłacalne.

> Ile duplikacji kodu w projekcie Państwo tolerują?

W przypadku, gdy pytanie jest o to, ile duplikatów pozostawiłbym w miarę
wszelkich możliwości w kodzie, moja odpowiedź brzmi: zero.

Pytanie to jest jednak niekonkretne z dwóch powodów:

1. Co to jest duplikat? No bo weźmy sobie taki przykład (akurat z mojej
praktyki):
Mamy strukturę "charakterystyczną", czyli opisującą charakterystyczne dane
jakiejś wielkiej tabeli (tabela ma bardzo ścisłe podziały, rozmiary,
indeksacje, sposób translacji danych pomiędzy poziomami itd.). Chodzi o to,
żeby dane charakterystyczne z tej tabeli wystarczyły do generycznego opisania
sposobu aktualizacji zawartości tabeli, a także przenoszenia wartości pomiędzy
poziomami i generacji raportu.

I teraz: nie ukrywam, że nawet sam wpadłem na ten pomysł, żeby wszystkie
"facility" dotyczące konkretnej tabeli (początkowo było ich 5) wrzucić do
osobnego pliku i tam również zawierała się funkcja inicjalizująca obiekt
charakterystyczny tej tabeli. Ponieważ każdy taki obiekt był typu tej samej
struktury, więc funkcja inicjalizująca obiekt charakterystyczny w każdym pliku
wyglądała niemal identycznie, co najwyżej tylko niektóre dane się różniły.

I co teraz? Czy w takim razie jedna z tych funkcji inicjalizujących jest
duplikatem pozostałych?

Inny przykład: mamy funkcję, która jest handlerem komendy. Tak się przypadkiem
złożyło, że dwie komendy przyjmują identyczny zestaw argumentów, tyle że robią
inne rzeczy. Czynność podejmowana przez te komendy jest bardzo prosta, w
uproszczeniu powiedzmy, że chodzi o wywołanie jednej funkcji (tyle że innej).
Argumenty przed podaniem muszą być odpowiednio dostosowane (przekonwertowane
itd.), więc wszystko to, co robią oba te handlery to jest zebranie i
przekonwertowanie argumentów oraz wywołanie odpowiedniej funkcji. Czyli te dwa
handlery komend, poza tym, że wywołują inną funkcję, nie różnią się niczym.
Zatem: są duplikatami, czy nie są?

Jeszcze inny przykład: mamy 10 funkcji wykonujących dokładnie to samo,
mianowicie pobierających komunikaty z kolejki, przetwarzających je
odpowiednio, konwertujących różne pierdoły... no i potem mamy switch/case,
który to dispatchuje na handlery. Z tym tylko, że ten switch/case stanowi
średnio 80% każdej funkcji. Czy te funkcje są duplikatami, czy nie?

W tej kwestii przychylałbym się do stwierdzenia p. Lewandowskiego, że jednak
duplikaty lepiej ocenia się "na oko". Ale powtórzę, nie wiem po raz który:
narzędzia nie służą do tego, żeby rządzić tym, co mają zrobić programiści.
Narzędzia mają za zadanie pokazać, unaocznić, przypomnieć, podpowiedzieć;
NIGDY zdecydować za człowieka. Narzędzia nie powinny także być częścią
polityki firmy.

2. Jeśli już stwierdziliśmy jakieś duplikaty kodu, to czy wskazany kod
rzeczywiście powinien zostać zastąpiony wersją generyczną? Inaczej, czy
opracowywanie generyzmu dla wskazanego kodu jest robotą na tyle zyskowną, że
warto się tym kodem w ogóle zajmować? Jest taka zasada: "nie należy grzebać w
starym gównie, bo zacznie śmierdzieć".



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Witam

Grzesiek G. wrote:

> Albo, że wyodrębnianie stawało się celem samym w
> sobie. 

Właśnie dlatego dopuszczam dwa lub czasem trzy, jeśli separacja powoduje
znaczny spadek wydajności, szczególnie 3 może być przy małych wrednych
kawałkach kodu pracujących na wielu parametrach w bardzo odległych fragmętach
kodu gdzie o separację ciężko.

> Stąd ten jeden duplikat. 

Stąd oryginał, duplikat i czasami 3 duplikat.

Pozdrawiam.

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
`\/\/   

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> Dnia Fri, 23 Jun 2006 19:50:10 +0200, Przemek Pokrywka skrobie:
>> Witam,
>
>> Czy zdarzają się Państwu sytuacje, w których pozbycie się
>> duplikacji kodu jest niemożliwe?
>
> Ja się osobiście nie spotkałem z sytuacją, żeby usunięcie 
> duplikatów było niemożliwe. Ale spotkałem się z sytuacją, 
> gdy jest nieopłacalne.

Podobnie jak (czasami) usuwanie błędów.  

TSD to właśnie zetknąłem się z tym problemem od strony użytkownika
oprogramowania: zakupiony za $15 program do zliczania czasu ma kilka
paskudnych błędów, których producent prawdopodobnie nie ma zamiaru
usunąć ze względu na nieopłacalność poprawiania.

-- 
http://www.piotr.dembiński.prv.pl

'Giving people a dynamically-typed language does not mean that they write
dynamically-typed programs.'  John Aycock, 'Aggressive Type Inference'

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.