Jeg har fra tid til anden fornøjelsen af at tale med advokater, revisorer om andre, som har deres egne faglige grunde til at grave ned i vores software. Jeg kan ikke lade være med at blive fascineret af, hvor forskelligt perspektiv, man kan udvikle, selvom man forsøger at tale om én og samme ting, nemlig et stykke software. Og de kan spørge om ting, jeg ALDRIG har tænkt på.
Photo by Capture Queen @ Flickr
Har du for eksempel overvejet, hvad der udgør de første 20 og de sidste 20 sider af din kodebase? Nej vel? Så hvis der nu er nogen, der beder dig om at sende disse, hvad gør du så? Er det rækkefølgen, de loades/køres i, når programmet startes, er det et spørgsmål om kronologisk orden efter hvornår de blev oprettet, eller skal vi bare vedtage, at AboutAction kommer før ZoomAction?
Hvad så, hvis du skulle svar på, hvor stor en del af teknologien bag version 5, der stammer fra version 4, version 3 og version 2? Skal man så kaste sig ud i noget Subversion-magi og forsøge at lave en diff mellem versionerne? Og hvis en linje er blevet ændret, tæller den så udelukkende med som noget, der er skabt i den nye version, eller skal man antage, at halvdelen af værdien stadig stammer fra tidligere? Eller er det mon bedre at basere udregningen på antallet af udviklere på produktet over tid, ud fra antagelsen om at 10 hoveder koder dobbelt så meget som 5? Og hvor meget af den eksisterende kode, kan man så regne med bliver slettet eller ændret til ukendelighed i hvert release?
Det er måske nemt at sige, at man ikke kan forvente, at folk med andre fagligheder skal kunne forstå, hvad software er for en størrelse, og affærdige deres spørgsmål som ”dumme”. Men jeg synes, at der er noget elementært interessant i at kigge lidt på det, man beskæftiger sig med, igennem et helt andet par briller; at prøve en anden professions tennissokker, om man vil.
Hvem bytter du sokker med fra tid til anden?
Hej,
Jeg lærer af alle vores brugere.
Både hende der kunne finde på at bruge den samme computer selvom hun under afhjælpning af et problem var blevet bedt om at "sætte sig over på en anden stol".
Men også af dem der nærmest kunne have skrevet min kode selv. (Men heldigvis ikke kan checke den ind :-). )
Det drejer sig om at vide hvor de er mentalt; ellers går man i skoven.
Jesper
Jeg tror at jeg ville tage en dialog med dem om hvorfor de stiller de spørgsmål. Så jeg kunne give dem svar på hvad de egentlig spørger om ;-)
Man kan tage andre sokker på, bare man taler med en anden udvikler, ofte ender man på samme side - men nogle gange kan der være "goddag mand", "økseskaft" over det i starten (Og tænk så på alt det man ikke snakker om)
Men Ja, som Jesper, er det nok brugerens sokker jeg låner mest.
Der kan også komme interessante ting ud af dialogen med en leverandør fx af hosting af en database - der kan være langt mellem hvordan man ser tingene.
Typisk problem når folk med almindelige sorte sokker prøver at forstå folk med hvide tennissokker...
Eller bare prøver at forstå hvad de laver - og gerne vil formidle det videre.
Men det er da altid bedre end når folk med røde sokker uden formål nedgør dem med hvide tennissokker...
Man boer forklare at antallet af aendrede kodelinjer ikke siger noget, men antallet af aendrede/nye features er en bedre maalestok i dette tilfaelde. Antallet af aendrede skruer siger heller ikke noget om hvor forandret en ny version af en bil er.
Ligesom med spoergsmaalet om de foerste 20 sider af koden, saa handler det om at finde ud af hvad spoergeren egentlig vil vide, hvor spoergsmaalet afspejler et mentalt billede af softwaren plus en for spoergeren passende loesning.
Jeg har da haft den glæde at udarbejde en metode til at opgøre hvor stor del af kodebasen, der er blevet skiftet ud over tid, så revisoren kunne bruge det til at beregne afskrivninger.
Det er en meget mærkelig og ikke særligt eksakt disciplin. Men ja - det som jeg kom frem til var at kigge i revisionskontrolsystemet og lave opgørelser over ændringer. Til dette formål er "git diff --stat" meget velegnet.
En sidenote: hvem i alverden bruger Subversion nu om dage? Jeg vil næsten påstå at hvis man bruger det system, har man bestemt større problemer, end revisorer og advokater der stiller uforståelige spørgsmål.
Det er en meget mærkelig og ikke særligt eksakt disciplin. Men ja - det som jeg kom frem til var at kigge i revisionskontrolsystemet og lave opgørelser over ændringer. Til dette formål er "git diff --stat" meget velegnet.
Og så har du slet ikke nævnt hvor vanvittig en måde det er at beregne afskrivninger på :-)
hvem i alverden bruger Subversion nu om dage? Jeg vil næsten påstå at hvis man bruger det system, har man bestemt større problemer, end revisorer og advokater der stiller uforståelige spørgsmål
]]]FLAMEWAR WARNING[[[ :-)
Jeg har en række ikke-nørd personer, som jeg bevidst vender forskellige problemstillinger med, simpelthen fordi de giver helt andre perspektiver på en opgave. Det - fornemmer jeg selv - forbedrer kvaliteten af det jeg laver.
/ Carsten
Det er, som du også er inde på, ofte revisorer og advokater der har en interesse i at forstå software - men ud fra de størrelser, som nu er omdrejningspunkter i deres respektive fag; økonomi og rettigheder. Selvom det kan virke "træls" på godt jysk, så er det naturligvis vigtigt både som udvikler og virksomhed at blive udfordret på, hvordan man opgør værdien af sin software - hvordan indregnes den i virksomhedens aktiver, hvordan udregnes værdien af årets udvikling sat i relation til at fastholde og vinde nye kunder, altså som modforanstaltning i forhold til den udvanding af softwarens værdi som man ville opleve over tid, hvis der ingen udvikling skete mere. Selvom enhver udvikler ville nægte at lade sig og sine produkter sammenligne med produktion og varelager, så er det jo altså nogle størrelser der er ret vigtige i forhold til at kunne opgøre hvilke dele af butikken der er rentable og hvilke der ikke er. Også for at få en intern dialog om og accept af, at de isoleret set ikke-rentable dele er forudsætningen for de rentable.
Derudover synes jeg det er interessant at tale med kvalitetsstyringsfolk - ISO-konsulenter og auditorer - gerne med rådgivningsbaggrund i produktionsvirksomheder, medicinalbranchen o.lign. - hvor der stilles skrappe krav til fysiske produkter. Det giver rigtigt god anledning til at få set sine processer og procedurer efter i sømmene, hvis man vil leve op til nogle dokumentations- og verifikationskrav, som måske ikke er umiddelbart indlysende i softwarebranchen.
Er i forbindelse med et udbud, blevet bedt om at beskrive antallet af linier kode jeg havde lavet i SSIS. For kendere af dette produkt vil der kun være latter at høre, da værktøjet er et såkaldt Peg og Click system.
Ok, man kan da skrive lidt SQL og nogle expressions, men det hele resultere i en XML fil der var på størrelse med højskolernes salmebog, nuvel det er blevet bedre i version SQL 2012 ;o)
Efter at have vurderet at antallet af linier kode skulle findes i 10 millioner niveauet, og vi alle havde svaret, fik vi besked fra Advokaten der forestod udbudet, at vi blot skulle se bort fra denne oplysning ;O)
Nu er subversion ret brugt, ret mange steder.
Jeg kender flere der bruger det uden problemer, så måske din opfattelse, og din kommentar er noget farvet af at Subversion måske ikke er værktøjet til lige præcis din opgave?
Din påstand om at man har større problemer end andre ting, bare fordi man bruger subversion, virker lidt gammelsur.
Som ingeniør/udvikler har jeg erfaret at de forskellige faggrupper stiller meget forskellige krav i forhold til præcision.
Vores fag er gennemsyret at perfektionisme, og man vil som udvikler helst kunne give et svar med 99,99% nøjagtighed. Men hvis man svarer på hvor mange linjers kode man har ændret i en ny version giver det absolut ingen mening for modtageren, hvis han/hun ingen indsigt har i teknologien eller produktet. Det er spild af tid at åbne en diff!
Modtager ville have langt bedre udbytte af et procent tal eller en tegning på pixie bogs niveau over hvad der er ændret. De ville klappe i hænderne og være lykkelige over en udvikler som forstod dem.
En sidenote: hvem i alverden bruger Subversion nu om dage? Jeg vil næsten påstå at hvis man bruger det system, har man bestemt større problemer, end revisorer og advokater der stiller uforståelige spørgsmål.
Hvorfor i alverden skulle man bruge Git, når Subversion gør alt hvad man vil ligeså godt som (nogen endda bedre end) Git?
Jeg bruger Git til et par private projekter, men kun fordi jeg vil vide, hvad det er, jeg hader så meget og jeg synes virkelig at Git sutter røv! Så irriterende at lave noget på et projekt derhjemme, og så på arbejdet finde ud af at man har glemt 'git push'. Og hvorfor kan 'git commit' ikke per default bare committe alle ændringer ligesom Subversion?
Hvad er det, Git kan, som Subversion ikke kan?
Jeg har altid netværksforbindelse, for ellers kan jeg stort set slet ikke arbejde, så offline commits er for mig fuldstændig ligegyldig, og jeg ser absolut ingen forbedringer i Gits branches i forhold til Subversion...fuldstændig lige nemme at bruge og merge.
Hvem bytter du sokker med fra tid til anden?
Man kan også selv have flere sokker - det er endnu ikke forbudt.
Der findes faktisk enkelte, der både har hvid og sort sok. Men de bruges antagelig parvis og med hastig 'sokkeskift', samt yderst sjældent anvendes en af hver :)
Om samme person også har blå/røde/med EU-stjerne liggende i skuffen til passende lejlighed er uvist.
De mørke kan nu godt bruges mere end 1 gang inden de skal vaskes! :-)
Så skal man forstå hvorfor spørgeren synes det er et logisk og naturligt spørgsmål. Omkring de 20 første sider ville jeg godt kunne komme med et logisk svar i forhold til min kodebase (topologisk sortering af applikationernes startup-rækkefølge). De sidste 20 er nok sværere for mine programmer er typisk ikke bygget til at stoppe igen.
Mht. hvor meget "nyt" der er i en version, så ville jeg gå mere kvalitativt til værks og så bare henvise til en changelog af ændrede og nye features. Jeg tror ikke det handler om et kvantitativt mål i så høj grad, hvis jeg skal gætte på spørgerens ønske. At dykke ned i Git/Subversion/Hg eller lignende for at komme med diffstats virker rimeligt meget som spild af arbejde.
Det drejer sig vist om registrering af ophavsret (hvilket ikke er obligatorisk, men giver ekstra fordele i USA):
http://www.copyright.gov/circs/circ61.pdf
Til formålet kan man vælge at offentliggøre
Entirely new computer programs
• First 25 and last 25 pages of source code with portions
containing trade secrets blocked out, or
• First 10 and last 10 pages of source code alone, with no
blocked out portions, or
• First 25 and last 25 pages of object code plus any 10 or
more consecutive pages of source code, with no blocked-
out portions, or
• For programs 50 pages or less in length, entire source
code with trade secret portions blocked out
Revised computer programs
If the revisions are present in the first 25 and last 25 pages,
any one of the four options above, as appropriate, or if the
revisions are not present in the first 25 and the last 25 pages:
• 20 pages of source code containing the revisions with no
blocked out portions, or
• any 50 pages of source code containing the revisions with
some portions blocked out
Hvordan man vedlægger "first 25 and last 25 pages of object code" på papir melder historien ikke noget om.
@jlouis: Man ville nok kunne slippe med at sortere ens moduler topologisk, og så tage begyndelsen af det første hhv. slutningen af det sidste.
