1000 ord ?
Her er et plot over Varnish-projektets udvikling igennem tid:
X-aksen er varnish-commits, y-aksen er linier kode.
Op til og med den violette "incl+lib" er det jeg vil kalde "selve varnish", mens det der ligger ovenover er udenomsværker.
Den mørkegrønne "jemalloc" er dobbelt så stor som den burde være, fordi vi har to kopier, det skal jeg lige have kigget på ved lejlighed.
Den orange "contrib" klods i starten, skyldes at vi oprindeligt troede vi skulle bruge et event-bibliotek fra 3.part, men det droppede vi igen, det holdt ikke en meter.
Læg også mærke til den sandgule "varnishtest" kile, det er vores unit/regressiontests.
Alt i alt er jeg meget godt tilfreds med billedet, men der er nogle detaljer jeg skal have checket, som f.eks jemalloc tingen.
Jeg kan godt lide at lave den slags analyser en gang imellem, tælle tingene sammen på en anden koordinatakse end jeg plejer, oftest kan man lære noget om sin kode man ikke vidste.
Jeg har læst en del papers om "metrics" i løbet af vinteren, men det meste af det er noget voodoo-viften med hænderne og mærkelige "empiriske" formler hvor man ganger og dividerer indtil man får et resultat der passer med ens påstand.
Software og dets kvalitet er og bliver elastik i metermål, men det betyder ikke at man ikke skal måle det ind i mellem.
phk
Om Poul-Henning KampSelvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (12)
Ja, er det ikke sådan det plejer at gå? Først efter 1500 commits bliver "doc"-delen synlig, og udgør stadig kun en mikroskopisk del af det samlede ;-)
Fin graf som man burde gøre efter for mange andre projekter.
-
0 -
0
Er der nogen forklaring på at testkode først dukker op efter 2500 commits? Er det en eller anden erkendelse der er opnået? Eller er det bare sådan du fortrækker at gøre det?
-
0
-
0
Hvis du kigger ovre til venstre kan du se en ganske tynd gul stribe fra vores oprindelige test-framework der var baseret på et generelt test-system.
Det virkede ikke ordentligt, fordi man skulle bruge uforholdsmæssigt megen tid på at forklare værtøjet at i denne test skal vi køre en varnish...
...med det forudsigelige resultat at tests blev bygget i alle mulige ad-hoc værktøjer udenfor svn træet.
På et tidspunkt fik jeg nok, og skrev et nyt varnish-centreret testværktøj der gjorde det meget nemmere at skrive en testcase og siden da er alle gamle og nye testcases skrevet i dette værktøj, i svn træet.
Poul-Henning
-
0
-
0
Ikke rigtigt...
Først kørte jeg en svn co -r$r for alle r og kørte en wc på alle filer der ikke var i et .svn subdir.
Derefter kørte jeg et awk script til at kategorisere og endelig gnuplot til at lave figuren med.
Intet af det er i nogen form for generaliseret eller brugbar form...
Poul-Henning
-
0
-
0
Hvis du har mulighed for at kaste nogle links til metric papers ville jeg blive meget glad.
-
0
-
0
Hvis du har mulighed for at kaste nogle links til metric papers ville jeg blive meget glad.
"Me too!"
Desuden vil jeg meget gerne høre din holdning til produktivitetsmåling af programmører udfra givne metrikker, Poul-Henning: Giver det overhovedet mening?
Din slutkommentar antyder at i små doser og med et gran salt oveni, kunne det måske være sigende.
-
0
-
0
Desuden vil jeg meget gerne høre din holdning til produktivitetsmåling af programmører udfra givne metrikker, Poul-Henning: Giver det overhovedet mening?
Nej det gør ej, ihvertfald ikke hvis kvalitet har nogen rolle.
Poul-Henning
-
0
-
0
Den orange "contrib" klods i starten, skyldes at vi oprindeligt troede vi skulle bruge et event-bibliotek fra 3.part, men det droppede vi igen, det holdt ikke en meter.
Skyldes det biblioteket eller det at lave det vha. events?
-
0
-
0
Tjek evt. denne: http://www.inf.usi.ch/phd/wettel/codecity.html
Den viser, hvilke klasser som har vokset sig for store i enten antal linjer/metoder eller antal member variable. Der er vist også et lignenede værktøj til Eclipse (for dem som bruger den slags).
-
0
-
0
Jeg har arbejdet steder hvor man bruge sådan noget her:
http://en.wikipedia.org/wiki/Cyclomatic_complexity
Det giver et vist fingerpeg om hvad det er man har gang i, men har også sine fejl. Feks kan man sagtens lavet en super kompleks statetable fyldt med funktions pointere og det giver et tal på 0, mens en switch case giver meget. Vores kvalitets mand brugte tallet med fornuft og trak data engang imellem, nogle steder har man politiker for hvor højt man må score, og er det for højt så kan man ike checke ind. Det giver gro bund for meget kreative programmørere og meget lidt læseligt kode.
-
0
-
0
Tilføj kommentar
