1000 ord ?

Her er et plot over Varnish-projektets udvikling igennem tid:

Illustration: Privatfoto

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

Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Poul-Henning Kamp Blogger

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
#5 Poul-Henning Kamp Blogger

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
#7 Martin Bøgelund

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
#9 Poul-Henning Kamp Blogger

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
#10 Anders Rune Jensen

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
#12 Michael Møller

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
Log ind eller Opret konto for at kommentere