ProgrammeringsBaren! Småprat, om det du elsker!

[torbjørn marø]

Jeg er en relativt tolmodig mann og burde ikke svart dere, da jeg med en gang forstå opplegget til de andre to medlemmene av

selv markerings behov klubben

Nå syntes jeg du skrev et ganske bra svar på mitt innlegg, og tenkte at nå går det kanskje an å kommunisere på et bra nivå her, og skape felles forståelse. Og så kommer du med dette her?!? Makan!

Det holder ikke i min verden, og du vil ikke få jobb hos meg for å si det sånn.

Tenkte ikke at du ville føle deg støtt av dette. For ordens skyld trekker jeg tilbake ordlyden og reformulerer til "Det holder ikke i min verden, og en som har de holdningene du her argumenterer for vil ikke få jobb hos meg for å si det sånn. "

Endret 28. august 2011 av torbjørn marø

[Gjest Slettet+9871234]

For ordens skyld trekker jeg tilbake ordlyden og reformulerer til "Det holder ikke i min verden, og en som har de holdningene du her argumenterer for vil ikke få jobb hos meg for å si det sånn. "

Det holder ikke i min verden. Jeg avskriver ingen før de har vist hva de (ikke ) duger til

[GeirGrusom]

Kode bør absolutt skrives for å imponere!

Nei i første om gang for å fungere. Siden (om man har tid) kan den gjøres bedre: http://www.refactoring.com/

Det holder ikke i min verden, og du vil ikke få jobb hos meg for å si det sånn. Hvis du lager throw-away kode med lite funksjonalitet så for all del, men lager du noe som skal vare så må det gjøres orntlig. Og dette mener Martin Fowler også (ref link)! Den eneste måten å utvikle raskt på (når kompleksiteten øker) er å utvikle godt!!!

 

Jeg vil kommentere litt på dette. Selv om jeg synes ideelt at en skal skrive god kode, så er det dessverre slik at noen må betale for jobben jeg gjør. Og da til tider må jeg noen ganger lage noe som kun fungerer, og så heller "retusjere" senere hvis jeg får tid.

Det er egentlig en ganske uheldig prosess, fordi dårlig kode ofte er mye vanskeligere å vedlikeholde, og noen ganger helt umulig å forme om for å takle en ny oppgave. Så det kan ende i at flere timer faktisk kreves, men på timebetaling så hender det at en må være pragmatisk innstilt. Raskt ferdig så sitter du med en fornøyd kunde, bruker du lang tid (på noe kunden ikke kommer til å røre allikevel, som ermesteparten av programmeringsjobben allikevel) så kan det hende du mister kontrakten neste gang.

[torbjørn marø]

Jeg vil kommentere litt på dette. Selv om jeg synes ideelt at en skal skrive god kode, så er det dessverre slik at noen må betale for jobben jeg gjør. Og da til tider må jeg noen ganger lage noe som kun fungerer, og så heller "retusjere" senere hvis jeg får tid.

Det er egentlig en ganske uheldig prosess, fordi dårlig kode ofte er mye vanskeligere å vedlikeholde, og noen ganger helt umulig å forme om for å takle en ny oppgave. Så det kan ende i at flere timer faktisk kreves, men på timebetaling så hender det at en må være pragmatisk innstilt. Raskt ferdig så sitter du med en fornøyd kunde, bruker du lang tid (på noe kunden ikke kommer til å røre allikevel, som ermesteparten av programmeringsjobben allikevel) så kan det hende du mister kontrakten neste gang.

Det er DU som er fagmannen, og som vet hvordan koding bør gjøres, ikke kunden. Forsøk å finne en murermester som vil følge dine råd om hvordan trappen bør lages. "Du trenger ikke noe orntlig fundament her, og du kan bruke en billigere sement der." Desverre er ikke integriteten like høy i utviklerbransjen, og konkurransen er hard. Men nesten all kode trenger vedlikehold/videreutvikling, og noe i nærheten av 99% av innsatset og pengene brukes etter at første versjon er sluppet. Derfor bør vi nesten alltid ta hensyn til dette.

 

Man skal ikke (i min ideelle verden) fortelle kunden at egentlig tar jobben to dager, men gjør jeg det vedlikeholdbart så tar det fire. Man forteller at det tar fire dager, og er du ikke villig til å betale så får du gå et annet sted.

 

Skjønner selvfølgelig jeg at det ikke alltid er så enkelt :|

 

Selv jobber jeg kun med to ulike prosjekter. Vi sitter 4-5 utviklere på dem, og har jobbet med dem i årevis. Uten kvalitet i koden hadde vi gitt opp for lenge siden. Det virker som om du utvikler for ulike kunder, og langt mindre prosjekter, og da er det ikke like viktig for deg - enten fordi det ikke er like viktig i dine tilfeller, eller fordi du ikke ser viktigheten.

 

En tankevekker:

 

“I think one of the problems we have as an industry is that we got way too many people slinging code. And we should probably reduce the number of people slinging code to the group that cares about it.”

- Uncle Bob

Endret 29. august 2011 av torbjørn marø

[GeirGrusom]

Jeg vil kommentere litt på dette. Selv om jeg synes ideelt at en skal skrive god kode, så er det dessverre slik at noen må betale for jobben jeg gjør. Og da til tider må jeg noen ganger lage noe som kun fungerer, og så heller "retusjere" senere hvis jeg får tid.

Det er egentlig en ganske uheldig prosess, fordi dårlig kode ofte er mye vanskeligere å vedlikeholde, og noen ganger helt umulig å forme om for å takle en ny oppgave. Så det kan ende i at flere timer faktisk kreves, men på timebetaling så hender det at en må være pragmatisk innstilt. Raskt ferdig så sitter du med en fornøyd kunde, bruker du lang tid (på noe kunden ikke kommer til å røre allikevel, som ermesteparten av programmeringsjobben allikevel) så kan det hende du mister kontrakten neste gang.

Det er DU som er fagmannen, og som vet hvordan koding bør gjøres, ikke kunden. Forsøk å finne en murermester som vil følge dine råd om hvordan trappen bør lages. "Du trenger ikke noe orntlig fundament her, og du kan bruke en billigere sement der." Desverre er ikke integriteten like høy i utviklerbransjen, og konkurransen er hard. Men nesten all kode trenger vedlikehold/videreutvikling, og noe i nærheten av 99% av innsatset og pengene brukes etter at første versjon er sluppet. Derfor bør vi nesten alltid ta hensyn til dette.

 

Man skal ikke (i min ideelle verden) fortelle kunden at egentlig tar jobben to dager, men gjør jeg det vedlikeholdbart så tar det fire. Man forteller at det tar fire dager, og er du ikke villig til å betale så får du gå et annet sted.

 

Skjønner selvfølgelig jeg at det ikke alltid er så enkelt :|

 

Selv jobber jeg kun med to ulike prosjekter. Vi sitter 4-5 utviklere på dem, og har jobbet med dem i årevis. Uten kvalitet i koden hadde vi gitt opp for lenge siden. Det virker som om du utvikler for ulike kunder, og langt mindre prosjekter, og da er det ikke like viktig for deg - enten fordi det ikke er like viktig i dine tilfeller, eller fordi du ikke ser viktigheten.

 

Jeg tror kanskje du har en mye mer avslappet ramme enn vi har på prosjektet vi begynner på. De interne prosjektene foretrekker jeg, fordi da får en mye bedre tid til å gjøre koden god, men på prosjekter som har et kontraktbundet antall timer, må en fire litt på kravene.

[torbjørn marø]

Jeg tror kanskje du har en mye mer avslappet ramme enn vi har på prosjektet vi begynner på. De interne prosjektene foretrekker jeg, fordi da får en mye bedre tid til å gjøre koden god, men på prosjekter som har et kontraktbundet antall timer, må en fire litt på kravene.

Som jeg har sagt tidligere, den eneste måten å utvikle raskt er å utvikle godt! Det er ikke mine ord alene, men sies av profilerte folk med 40+ års erfaring. Det føles ikke sånn i starten, og det kreves også kunnskap og erfaring om hvordan man faktisk utvikler godt (det kommer ikke av seg selv), men gjør man det riktig får man garantert gevinst.

 

Siterer Uncle Bob igjen jeg:

 

There are several blogs on artima this week that appear to be arguing that you have to sometimes reduce quality to meet a deadline.

 

Balderdash!

 

In my humble opinion the value that separates amateurs from professionals is that velocity is a direct function of quality. The higher the quality, the faster you go. The only way to go fast is to go well.

 

Novices believe that quality and velocity are inverse. They think that hacking is fast. They haven't yet recognized what professional developers know all to well: that even a little bit of hacking is slower than no hacking at all.

 

Every time you yeild to the temptation to trade quality for speed, you slow down. Every time.

(kilde)

[Gjest Slettet+9871234]

Som jeg har sagt tidligere, den eneste måten å utvikle raskt er å utvikle godt! Det er ikke mine ord alene, men sies av profilerte folk med 40+ års erfaring. Det føles ikke sånn i starten, og det kreves også kunnskap og erfaring om hvordan man faktisk utvikler godt (det kommer ikke av seg selv), men gjør man det riktig får man garantert gevinst.

Nei og atter nei. Det virker som om du ikke forstår hva en "deadline" er. Jeg elsker "deadlines", og har mange ganger måttet lage noe som fungerer på kort sikt.

 

Eksempler:

1. Overvåking av det norske banksystemet.
   
2. Rentekontrollen for finansminister Rolf Presthus.
   
3. Det første programmet som ble brukt til å plassere Norges Banks valutareserver.
   

 

1. Overvåking av det norske banksystemet.

Jeg hadde ikke uker på jobben, så den måtte gjøres kjapt. Jeg skar til benet. En prototype av det systmet ble programmert i all hast for n=2 banker. Da det var gjort overtok andre som lett kunne generalisere til n=k banker. Mursteins tut og kjør programmering som fungerte.

 

2. Rentekontrollen for finansminister Rolf Presthus.

Hver dag jeg kom på jobben kom noen og sa at jeg måtte bli ferdig. Jeg lå i sengen og "programmerte" om natten. Jeg sa. Slutter dere ikke å mase, får dere ikke noen prototype. Prototypen ble utviklet på en uke. Mursteins tut og kjør programmering som fungerte.

 

3. Det første programmet som ble brukt til å plassere Norges Banks valutareserver.

Ikke så lett da høy nivå makro språk utviklet ved MIT ble kombinert med egne fortran rutiner samt ferdige rutiner fra Fortran bibliotektet til http://www.nag.co.uk/

 

Det måtte også programmers relativt fort. Nobel Pris vinner Harry Markowitz http://en.wikipedia.org/wiki/Harry_Markowitz CAPM http://en.wikipedia.org/wiki/Capital_asset_pricing_model modell (kvadratisk programmering med restriksjoner) ble brukt.

Mursteins tut og kjør programmering som fungerte.

 

Mine egne siter ble stort sett utviklet i tut og kjør versjon i 2004 og 2005. Mange utlendinger har takket meg for korte artikler og lenker på de sitene. De siste 5 - 6 årene har jeg stort sett ikke gjort annet enn å lese og lese for å få best mulig oversikt over ulike web teknologier. Jeg innser nå at jeg kanskje aldri får god nok oversikt og er svært skeptiske til andre som mener de har det. Programmerings språk, rammeverk og platform religioner er ikke fundamentalt ulike vanlig religiøse debatter og feider.

 

Ta en titt på koden til WordPress og Drupal

Er kjent med begge CMSene og koden imponere meg ikke på noen som helst måte.

 

At one time, it was possible for an average developer to know Drupal. Now, few people (perhaps 5-10) understand all of Drupal's core systems. One point really caught me. It's not just the code base that is complex. It's the plethora of subsystems, of methods of passing data, of specialized conventions, even of terminology. Drupal is a conceptual behemoth.

Kilde: http://technosophos.com/content/why-object-oriented-programming-bad-drupal

 

Drupal som jeg har omtalt ovenfor kan velvilligst i dag bare kalles et hybrid system. Se

 

Autocomplete, OOP and extending drupal.

 

Veien blir noen ganger til mens man går. Det viktigste er noen ganger å starte.

Jeg er helt sikker på at mine tre ovennevnte programmer ikke brukes i dag. Om det siste brukes, er det nok programmert i C eller C++ på en Pc.

 

<Siste utenomsnakk i denne tråden??>

Strikte deadlines går ofte ikke sammen med god kode, men de kan gå sammen med god nok kode. Jeg har sett Univeristetslektorer og professorer fra Universitetet i Bergen (UiB) med altfor store egoer. Universitetslektoren sa at Java måtte brukes (til orientering så mener jeg å ha koden et sted om en Java kverulant skulle trenge den - mitt liv er for kort til å programmere i assembly og lære meg Java ) på et prosjekt. De greidde ikke å løse problemet om hvordan man skulle kunne scrappe kode fra en site som gikk over ulike servere. Det hadde med absolutte og relative URL'er å gjøre. Personlig antar jeg PHP (cURL) er best til dette. Da jeg sa at ekspertene på OOP i verden fantes på Blindern i Oslo ble jeg av professoren dunket i hodet med at det nå var i Bergen. Andre innbiller seg at det er på NTNU i Trondheim. Jeg holder en knapp på UIO.

 

 

Så får vi slutte med utenomsnakket med hvem som skal ansette hvem. Slike og lignende utsagn har vel lite i denne trådens tema å gjøre. Forrige gang en slik diskusjon fikk utvikle seg fikk jeg en advarsel. Jeg pleier å forlate forum der jeg mener å få en urettmessig advarsel. Når ingen moderator griper inn måtte jeg skrive disse ordene.

</Siste utenomsnakk i denne tråden??>

Endret 29. august 2011 av Slettet+9871234

[Jonas]

Så får vi slutte med utenomsnakket med hvem som skal ansette hvem.

Vær klar over at det bare er du som deltar i dette utenomsnakket - alltid.

[Gjest Slettet+9871234]

Du er sannelig meg morsom.

 

Likte du som trønder ikke det siste utenomsnakket ? Nå venter jeg spent på bergenseren siden utenomsnakket fortsetter selvsagt med Jonas som deltager . Ser at han leser innlegget

 

Nå kan dere jo begge skrive til dere får krampe. Jeg tar meg en velfortjent ferie etter diskusjon med norske hobby kverulanter med egoer som ikke står i forhold til kunnskapene.

 

Programmering er en samling trivialiteter. Hvert enkelt skritt er trivielt.

Endret 29. august 2011 av Slettet+9871234

[torbjørn marø]

3 x Mursteins tut og kjør programmering som fungerte.

Argumentasjonen din adresserer ikke påstanden som jeg presenterer og viser at jeg støtter, nemlig at det går raskere å utvikle software vha. kvalitetskode enn ved "tut og kjør" som du kaller det.

 

Du viser til tre prosjekter du har gjort, og som er gjort raskt. Jeg har også gjort mange raske prosjekter - av varierende kvalitet. Men det du forteller sier ingenting om at det ikke kunne gått enda raskere om du hadde følgt gode programmeringsprinsipper og laget solid kode.

 

Eller kanskje du gjorde det - hva vet vel jeg?! Kanskje du er en dyktig utvikler, og skriver god kode "by default", uten å tenke deg om. Du innser det bare ikke selv? Du tror du gjør noe slurvete som ingen vil klare å vedlikeholde, og så gjør du egentlig det motsatte?!

 

Når du sier at andre utviklere lett kunne ta det du hadde laget å utvide det med ny funksjonalitet så er det nemlig det du antyder.

 

La oss la være å lytte til de store mestrene (bare for et lite øyeblikk), og la meg fortelle hva jeg selv opplever. Jeg har startet ganske mange prosjekter av ulik størrelse de siste 10-12 årene. Mange har jeg startet slurvete, men en del har jeg gjort bra. Når jeg startet slurvete kjører jeg meg fort fast. Det kan skje etter en uke, eller allerede etter en dag. Når jeg gjør det bra er det utrolig hvordan koden flyter ut av fingrene, og jeg kan holde en stor fart over lang tid. Selv om jeg må gjøre ganske omfattende endringer går det raskt fordi strukturene er mulige å endre uten at jeg er redd for å ødelegge noe. Automatiserte tester gjør meg trygg, og ren kode gjør at en endring her ikke ødelegger noe der.

 

For bare 4-5 år siden var jeg også av den oppfatning at kvalitet og f.eks. testdreven utvikling tok lengre tid. I dag har jeg selv erfart at jeg kan levere minst like mye funksjonalitet til samme deadline ved å følge gode prinsipper, og det jeg leverer har en høyere kvalitet. Av og til hender det likevel jeg "bare skal smelle sammen et lite tool for å gjøre en liten jobb", og nesten alltid angrer jeg at jeg ikke startet orntlig - fordi ting baller på seg, nye behov dukker opp, og det er utrolig hvor fort kode kan bli uoversiktelig!

[Gjest Slettet+9871234]

Bra svar.

 

Argumentasjonen din adresserer ikke påstanden som jeg presenterer og viser at jeg støtter, nemlig at det går raskere å utvikle software vha. kvalitetskode enn ved "tut og kjør" som du kaller det.

Ja for eksempel med dekoblet tut og kjør jQuery kjeder. Hva om man ikke kjenner jQuery? Kunnskap er relativ. Jeg mener endog a kunnskap har fraktal struktur.

 

Du viser til tre prosjekter du har gjort, og som er gjort raskt. Jeg har også gjort mange raske prosjekter - av varierende kvalitet. Men det du forteller sier ingenting om at det ikke kunne gått enda raskere om du hadde følgt gode programmeringsprinsipper og laget solid kode.

Det er semantikk. Beslutninger i programmering kan sammenlignes med assembly. Du har to muligheter ved hver enkelt skritt (beslutningen du gjør):

1. Den veien du valgte.
   
2. Alt det andre - komplementet om du vil.
   

Det meste kan gjøres bedre, men bruker du for mye tid på å finne den beste måten, kan du ende opp med ikke å gjøre noe.

 

Eller kanskje du gjorde det - hva vet vel jeg?! Kanskje du er en dyktig utvikler, og skriver god kode "by default", uten å tenke deg om. Du innser det bare ikke selv? Du tror du gjør noe slurvete som ingen vil klare å vedlikeholde, og så gjør du egentlig det motsatte?!

Det får andre vurdere.

 

Når du sier at andre utviklere lett kunne ta det du hadde laget å utvide det med ny funksjonalitet så er det nemlig det du antyder.

Det kunne ha blitt gjort bedre. Man finner ikke alltid minste felles multiplum men en faktor som funker godt nok.

 

La oss la være å lytte til de store mestrene (bare for et lite øyeblikk), og la meg fortelle hva jeg selv opplever. Jeg har startet ganske mange prosjekter av ulik størrelse de siste 10-12 årene. Mange har jeg startet slurvete, men en del har jeg gjort bra. Når jeg startet slurvete kjører jeg meg fort fast. Det kan skje etter en uke, eller allerede etter en dag. Når jeg gjør det bra er det utrolig hvordan koden flyter ut av fingrene, og jeg kan holde en stor fart over lang tid. Selv om jeg må gjøre ganske omfattende endringer går det raskt fordi strukturene er mulige å endre uten at jeg er redd for å ødelegge noe. Automatiserte tester gjør meg trygg, og ren kode gjør at en endring her ikke ødelegger noe der.

Ser jeg i dag på sitene mine er det rot fra ende til annen. Men uten at jeg begynte ville jeg ikke hatt mange siter i dag. (I tilligg bruker jeg altfor mye tid på siter / forum som dette. Det er utrolig så mye misinformasjon og propaganda der er på den politiske delen av dette forumet).

 

For bare 4-5 år siden var jeg også av den oppfatning at kvalitet og f.eks. testdreven utvikling tok lengre tid. I dag har jeg selv erfart at jeg kan levere minst like mye funksjonalitet til samme deadline ved å følge gode prinsipper, og det jeg leverer har en høyere kvalitet. Av og til hender det likevel jeg "bare skal smelle sammen et lite tool for å gjøre en liten jobb", og nesten alltid angrer jeg at jeg ikke startet orntlig - fordi ting baller på seg, nye behov dukker opp, og det er utrolig hvor fort kode kan bli uoversiktelig!

Dersom du fra begynnelsen er trenet i Ekstreme programmering (Xp) http://www.extremeprogramming.org/ kan du ha en komparativ fordel.

 

Jeg mener ikke dermed at du automatisk har det.

Endret 29. august 2011 av Slettet+9871234

[torbjørn marø]

Det meste kan gjøres bedre, men bruker du for mye tid på å finne den beste måten, kan du ende opp med ikke å gjøre noe.

Dette er den viktigste setningen i din siste post, og nå adresserer du min påstand. Du sier slik jeg forstår det at man må begrense hvor "perfekt" man skal kode, fordi man ellers bruker for lang tid.

 

Enig!

 

Men det at man ikke kan skrive perfekt kode betyr ikke at man kan skrive kode hvor dårlig man vil. Du sier også noe sånt som at koden din var god nok, men at den nok også kunne vært bedre.

 

Flott!

 

God nok kode er god nok per definisjon. Men kode som kun er skrevet for å fungere, og ikke skrevet for mennesker, er veldig sjelden god nok (det var denne påstanden diskusjonen vår begynte med).

 

Jeg er også en pragmatisk utvikler, selv om du kanskje ikke har det inntrykket. Ulike utviklere sitter som du påpeker med ulike erfaringer, og må utvikle produksjonskode med den kunnskapen de har - å forsøke noe annet vil misslykkes.

 

Det er derimot ikke gitt at den kunnskapen en utvikler besitter er god nok til å produsere god nok kode for en gitt situasjon. Da bør han etterstrebe å bli bedre, .. trene, bruke av fritiden på å lære seg teknikker for å kunne produsere den koden som er god nok. Det er den profisjonelle utviklerens ansvar. Han slår seg ikke til ro med at sålenge programmet fungerer så er jeg fornøyd. Fungerende kode er som du sier trivielt. Å kommunisere godt gjennom kode er derimot både en kunst og et håndtverk som krever trening.

 

... Så, nå kan du kalle meg en kunnskapsløs egoist igjen om du vil, helt ærlig synes jeg bare det er morsomt

Endret 29. august 2011 av torbjørn marø

[torbjørn marø]

Nå venter jeg spent på bergenseren siden utenomsnakket fortsetter

Forresten er jeg som deg en Haugesunder!

[Gjest Slettet+9871234]

Nå venter jeg spent på bergenseren siden utenomsnakket fortsetter

Forresten er jeg som deg en Haugesunder!

Vi får ta oss en utepils om jeg kommer der en gang i fremtiden. Vet jo ikke om du drikker pils, så ...

[GeirGrusom]

In my humble opinion the value that separates amateurs from professionals is that velocity is a direct function of quality

Selvsagt blir en bedre med trening, men det er også en antagelse om at profesjonelle alltid velger riktig løsning på et problem de aldri har vært borti, eller at de produserer feilfri kode. Begge deler er uansett feil. Derfor har vi unit-testing og dokumentasjon som er en viktig del av god kode, men også det som er lettest å fire på for å spare timer.

[torbjørn marø]

In my humble opinion the value that separates amateurs from professionals is that velocity is a direct function of quality

Selvsagt blir en bedre med trening, men det er også en antagelse om at profesjonelle alltid velger riktig løsning på et problem de aldri har vært borti, eller at de produserer feilfri kode. Begge deler er uansett feil. Derfor har vi unit-testing og dokumentasjon som er en viktig del av god kode, men også det som er lettest å fire på for å spare timer.

Om dokumentasjon skal jeg ikke si annet enn at det meste av den som lages er helt unødvendig (og dermed kan skippes), mens det meste av det som burde dokumenteres desverre aldri blir det.

 

Når det gjelder unit-tester, og da tester skrevet i forkant (TDD), så er det akkurat det Uncle Bob snakker om. Å droppe TDD for å gå raskere er stort sett bare tull - TDD er ikke tregere enn ikke TDD (i alle fall på alt annet enn trivielle prosjekter)!

 

Jeg synes en av kommentarene til Roberts utsagn sier det ganske bra:

 

I think there's a deeper reason, and that is that the marginal utility of tests written after the code has a completely different shape than the marginal utility of tests written as part of TDD.

 

If you code and then test, the first compile is going to show you a lot of defects. Then the first attempts to run it will show you more. After that, each test you write is less likely to show you more defects that need fixing - the law of diminishing returns sets in, or the 80-20 rule if you prefer that term.

 

TDD is exactly the opposite. As long as you only write code in response to a failing test, you'll continue moving along, and encounter relatively few defects. As soon as you start writing code that isn't required to fix a failing test, you start getting into trouble big time.

 

If all you know is code and fix, then TDD is very counterintuitive. That's why a lot of managers think they have a quality knob they can turn. They did with code and fix, they don't with TDD.

 

Jeg skjønner forøvrig ikke hvorfor du mener han gjør de antagelsene! Han snakker om hva vi verdsetter.

Endret 30. august 2011 av torbjørn marø

[Gjest Slettet+9871234]

Man trenger ikke test drevet utvikling for å lage websiter. Det tar tid å lage enhetstestene.

 

I think there's a deeper reason, and that is that the marginal utility of tests written after the code has a completely different shape than the marginal utility of tests written as part of TDD.

Noen går i fjellet uten kart og kompass. Noen går bare med kart og noen bruker begge deler. Noen følger også røde T-fra turistforeningens stier og løyper. Kommer du til en bekk og tar deg en slurk vann, er den første slurken manna, men grensenytten av neste slurk er sterkt avtagende. Til slutt er den negativ. Jeg har aldri hatt tid til å lære meg testdrevet utvikling ordentlig og akter heller ikke å gjøre det. På veldig store prosjekter ser jeg selvsagt en fordel og parprogrammering kan være bra i noen tilfeller, men ikke i alle. Får man det inn med morsmelken vet ikke jeg om det blir en tvangstrøye eller som den første slurken du drikker fra bekken.

 

If you code and then test, the first compile is going to show you a lot of defects. Then the first attempts to run it will show you more. After that, each test you write is less likely to show you more defects that need fixing - the law of diminishing returns sets in, or the 80-20 rule if you prefer that term.

"A lot of defects"? Man finner for de ved tut og kjør. Loven om avtagende utbytte avhenger av den produktfunksjonen du bruker. Enhetstesting er en ekstra innsatsfaktor i produksjonen og øker dermed kompleksiteten av prosjektet med en dimensjon minst. Hvorfor gjøre det vanskelig når man kan gjøre det enkelt? Pareto var vel den første som utformet 80 - 20 prinsippet.

 

Hvor lenge fortsetter denne debatten. I neste post får der litt kode å tygge på.

[GeirGrusom]

Han snakker om at unit-tester sparer tid for deg.... hvor mange unit-tester må feile før dette er et faktum? De aller fleste, men det gjør de ikke. De fleste unit-tester går fint igjennom.

 

Det virker som han prøver å påstå at det er bare to måter å programmere på: feil måte, og riktig måte.

Endret 30. august 2011 av GeirGrusom

[Gjest Slettet+9871234]

Koden nedenfor beskriver en JavaScript autoloader i Drupal.

 

jsloader.js

 

// $Id$

/**
* Verify that the autoloader is working.
* @file
*/

jQuery(document).ready(function() {
 console.log("JS Loader is ready.");
});

 

jquery.divwrap.js

 

/**
* A custom jQuery plugin that provides a wrapper div around an element.
*/

(function ($) {

 /**
  * Wrap the selected element or elements in <div></div> tags.
  *
  * @param attrs
  *  An object containing name/value pairs for attrs.
  */
 jQuery.fn.divWrap = function () {
   var attrs = (arguments.length > 0) ? arguments[0] : {};

   this.each(function (index, item) {
     var div = $(item).wrap('<div></div>').parent();

     if (attrs) {
       div.attr(attrs);
     }
   });
   return this;
 }
})(jQuery);

 

parse.php

 

#!/usr/bin/env php
<?php
function jsloader_parse_info_file($filename) {
 $info = array();
 if (!is_readable($filename)) {
   return $info;
 }
 $handle = fopen($filename, 'r');
 while ($line = fgets($handle)) {

   // Skip blanks
   $line = trim($line);
   if (strlen($line) == 0) {
     continue;
   }

   // Skip comments
   if ($line{0} == ';') {
     print "Skipping comment\n";
     continue;
   }

   $pos = strpos($line, '=');
   // Skip false and lines starting with =.
   if ($pos === FALSE || $pos === 0) {
     continue;
   }

   // Split by pos (faster than split()).
   $key = substr($line, 0, $pos);
   $val = trim(substr($line, $pos + 1));

   print "Key: $key; Val: $val";

   // Do value parsing:
   $first_char = substr($val,0,1); // Faster than {} syntax.
   if($first_char == '"' || $first_char == '\'') {
     $val = substr($val, 1);

     // Check to make sure line ends with quote.
     // If not, we keep consuming lines.
     $val_len = strlen($val);
     $val_last = substr($val, $val_len - 1);
     if ($val_last != $first_char ||
       ($val_last == $first_char && substr($val, $val_len - 2, $val_len -1) == '\\')
     ) {
       print "Looking for closing quote\n";
       // Consume lines until we hit closing quote.
       $closed = FALSE;
       while (!$closed) {
         $another_line = fgets($handle);
         if ($another_line = NULL) {
           // We hit the end of the file:
           fclose($handle);
           return $info;
         }
         $check_line = rtrim($another_line);
         $check_line_len = count($check_line);
         if (substr($check_line, $check_line_len -2, $check_line_len -1) == $first_char) {
           $another_line = substr($check_line, $check_line_len - 2);
           $closed = TRUE;
         }
         $val .=  $another_line;
       }
     }
     else {
       print "\nXXX\n";
       $val = substr($val, 0, $val_last - 1);
     }
   }

   // Do key parsing:
   $key_bracket = strpos($key, '[');
   if ($key_bracket !== FALSE) {
     if ($key_bracket === 0) {
       // Malformed line. Skip it.
       print "Skipped malformed line\n";
       continue;
     }
     $real_key = substr($key, 0, $key_bracket);
     if (!array_key_exists($real_key, $info)) {
       $info[$real_key] = array();
     }
     $tokens = split(']', substr($key, $key_bracket), 255);
     foreach ($tokens as $token) {
       $token = trim($token);
       if (empty($token)) {
         //skip?
       }
       elseif ($token == '[') {
         // No key
         $info[$real_key][] = $val;
         //$current_array[] = $val;
         //$current_array = $current_array[count($current_array) -1];
       } 
       else {
         // Get the key
         /*if (strpos($token, '[') !== FALSE) {
           print "Skipped malformed token\n";
           continue; // malformed
         }*/
         $array_key = substr($token, 1); // Drop [
         $info[$real_key][$array_key] = $val;
         //$current_array[$array_key] = $val;
         //$current_array = $current_array[$array_key];
       }
     }
   }
   else {
     $info[$key] = $val;
   }
 }
 return $info;
}

print_r(jsloader_parse_info_file('./jsloader.info'));
?>

 

Kilde - Samme som denne:

 

AJAX, jQuery, webtjenester, real tids kommentering, JSON etc.

 

Koden er ikke komplett, så de som vil ha den komplette koden med forklaring kan kjøpe PDF versjonen av denne

 

http://www.packtpub.com/drupal-6-javascript-and-jquery/book

 

boken. Den koster £8.50 mindre enn en utepils på Aker brygge.

 

Jeg tar ferie så ha en fortsatt bra programmerings chat.

 

@Torbjørn:

 

Som Haugesunder vet du at Bendix Jørgensen som deltok sammen med Folgerø i Sten Bromans program Kontrapunkt hadde absolutt gehør. Han kunne sitte i sengen og lese notene til en symphoni og høre musikken inni seg. Han trengte nok ikke enhets testing, da han hadde abolutt gehør. Lær deg å lese kode som Jørgensen leste noter, og du kan få jobb hos de fleste som trenger programmerere.

 

Min matte professor spurte om jeg satt på toget og leste matte hovedfag? Ja sa jeg (det går da ikke an svarte han), men det er en annen sak og jeg er ikke matematiker, men økonom.

 

Matematiske beviser som går over 400 sider er en samling trivialiteter.

 

Mattematikk og programmering er begge en samling trivialiteter. Hvert enkelt skritt er trivielt.

 

Men bare matematikere og programmerere greier å holde tråden. Det skiller klinten fra hveten.

 

Noe av det viktigste du lærer som programmerer er:

1. Skylapper: Å vite når du skal lukke og åpne øynene.
   
2. Flexibilitet: Kunne kaste alt det du holder på med til side permanent eller midlertidig å begynne på noe som er viktigere.
   

Endret 30. august 2011 av Slettet+9871234

[tomsi42]

Det virker som han prøver å påstå at det er bare to måter å programmere på: feil måte, og riktig måte.

Det er bare to måter å programmere på, feil måte og min måte

 

Diskusjonen har vært interessant da den viser kulturkollisjonen på to veldig forskjellige måter å jobbe på. En ting er hva man har lært først; en annen ting er at vi mennesker er veldig forskjellige, og dermed jobber på forskjellige måter. Tut og kjør er en måte, TDD og parprogrammering er en annen måte. Skal ikke si hva som er riktig da min tilnærming er en tredje varian, og som fungerer for meg.

 

Det som dog slår meg med mange av metodikkene (XP, TDD osv) er lansert av folk som har en agenda - de selger kurs og bøker som beskriver metodikken ...