Re: Perl::Critic vs. Subversion

Hej Søren + resten.

On 2010-06-09 20:02, Søren Lund wrote:
> * Jonas B. Nielsen<[email protected]>  [2010-06-09 16:12:35+0200]:
>    
>> I fell over the following tweet.
>>
>> 	http://twitter.com/perlcritic/status/15575614333
>>
>> I understand Elliot's points and I do agree to some extent,
>>      
> Jeg er absolut ikke enig med Elliot. Han skriver
>
> "You should always be able to check your code in, if only for
> backup purposes."
>
> NEJ: Subversion brugt til SCM er *ikke* et back-up-system. Kode,
> der checkes ind skal være færdig, virke (unit test) og overholde
> kodestandarder.
>    
Jeg er enig så langt at Elliot skriver om at bruge subversion som 
backup. Det lyder som en meget dårlig ide. Hvis man bruger git kan man 
iøvrigt tillade sig at tage "backup" meget oftere ved at committe og 
først skubbe sin kode når den er klar.

Når det er sagt, synes jeg ikke at det er oplagt at bruge Perl::Critic 
som pre-commit-hook i subversion/CVS eller lignende. Spørgsmålet drejer 
sig om kultur - er statisk kode-tjek noget man bruger til at håndhæve 
kodestandarder eller bruger man det til at opmuntre til at overholde dem?

Jeg har set moduler der kunne køre igennem Perl::Critic på brutal-niveau 
og med højest tænklige kwalitee, hvor realiteten stadigvæk var, at 
modulet var baseret på et dårligt design og fyldt med alvorlige fejl. I 
den situation spørger man sig selv om udvikleren er tjent med at bruge 
sin tid på at rette ting, som Perl::Critic klager over.

Problemet er, at man kan blive forandlediget til at sætte formalia over 
kvalitet. At hvis blot alle statiske checks (og måske diverse tests) er 
ok, er koden også iorden. Tests kan kun afsløre eksistensen af fejl 
(frem for ikke-eksistensen af fejl) og statiske checks kan kun afsløre 
kendte anti-patterns, men ikke nye.

Det skal ikke forståes sådan at jeg er imod tests og statisk check af 
kode, men disse værktøjer kræver udviklere som forstår at bruge dem 
aktivt til at forbedre kvaliteten af deres kode. Hvis pre-commit-hooks 
er i vejen for de udviklere, der faktisk producerer god kvalitet, synes 
jeg at det er mere oplagt at addresere problemet på en helt anden måde.
> "You’ve got a production emergency bug fix..."
>
> Og så har man travl, så travlt at man dummer sig. Ignorerer den
> der ene unit test, der pludselig fejler. Resultat
> fejlbehæftet kode i produktion. Det er netop til små bugfixes,
> at automatisered tests, og Perl::Critic er vigitige, for her er
> ikke tid til manuel test.
>
> Jeg ved godt jeg er firkantet, men det er oftes mig, der lægger
> koden i produktion. Så det er derfor også mig, der samler og
> rydder op, når der er skodkode checket ind...
>    
Nu har jeg brugt git i snart et halvt år, og synes egentlig at der er 
mange ting, der bliver lettere med dette værktøj. Frem for at mange 
udviklere arbejder på samme branch i et CVS eller Subversion- 
repository, kan man som deployment- eller integrationsansvarlig blot 
afvise rettelser fra andre, der ikke lever op til de krav man har 
stillet, uden at hindre andre i at fortsætte arbejdet.

Mvh. Michael.