Er du en skodkoder? ….er jeg?

Er jeg den eneste som bliver lidt smådeprimeret når jeg læser ActionScript tutorials og lignende?
Koden i disse eksempler er (næsten) altid pakket fint ind i nydelige klasser, 100% event-drevede og jeg skal gi’ dig skal jeg.
Hånden på hjertet, så har jeg lavet ….hmmm….2 klasser i ActionScript, i alt, og den ene var bare for at teste hvordan man gjorde, men gør det mig til en skodkoder?

Lad mig svare med det samme, at nej, det synes jeg ikke at det gør.

Selvom ekstremt meget af det kode man ser rundt omkring er klasser, så er det ikke altid den eneste gyldige måde at kode noget på, og ofte vil jeg endda mene at det er en decideret forkert måde, i hvert fald når jeg rent pragmatisk kigger på de ting som jeg typisk laver.

Indlægget her er i høj grad inspireret af noget andet jeg læste fornyligt, nemlig en længere artikel fra Jesse Warden hvor han snakker om behovedet for et nyt Flash framework.

Det er et meeeeget langt indlæg, og jeg vil ikke gå ind i detaljer om det han skriver om, det jeg bed mærke i var primært hans liste over hvordan han er nød til at prioritere et projekt:

  1. Deadline
  2. Creative (Oplevelsen, designerens vision)
  3. Bandwidth (Båndbredde)
  4. Maintainability (Hvor nemt det er at vedligeholde)

Og jeg synes at den liste rammer sømmet lige på hovedet, for hvad skal man med “god” kode, hvis sitet ender med at være grimt/dårligt/ubrugeligt, og for øvrigt bliver lanceret alt, alt for sent.

Jeg kunne i hvert fald aldrig forestille mig at skrive følgende til en kunde:
Nu har jeg lavet det så det virker, men jeg er ikke helt tilfreds med syntaksen og strukturen i min kode, så er det okay med dig at projektet bliver en uge forsinket?
Til gengæld bliver det så også super nemt for en anden udvikler at opdatere sitet om 2 år.

Dermed ikke sagt at klasser og god kode er dårlige, for det er de absolut ikke, men der er et tid og sted til alt.

Det der typisk kendetegner mine projekter er:

  • Jeg er den eneste udvikler på dem
  • De har en begrænset levetid
  • De har et begrænset omgang, er ikke ekstremt komplekse
  • Projektets/opgaven er unik

Jeg er den eneste udvikler på dem
En af de store fordele ved klasser er, at man arbejder med dem i seperate .as-filer, hvilket betyder at flere udviklere kan arbejde på forskellige dele af projektet samtidig.
Derudover er klasser relativt selvforklarende i deres struktur (hvis de er lavet bare nogenlunde ordentligt), sådan så det er nemt for andre programmører at gennemskue hvad de gør, selv hvis koden ikke er kommenteret.

Men, er der, som i mit tilfælde, kun én udvikler på projektet, så har man ikke brug for de to fordele.

De har en begrænset levetid
Hvis næste version af opgaven/sitet ikke er en videreudvikling på det foregående, men at man simpelthen tager det gamle og smider ud og starter forfra, så er det ikke vigtigt at koden er selvforklarende om 1 år eller mere, når man selv har glemt det.

De har et begrænset omgang, er ikke ekstremt komplekse
Med det mener jeg ikke nødvendigvis at den kode der er skrevet er nem, den kan sagtens være svær og indviklet, jeg mener alene omfanget af opgaven.

Tag for eksempel dette site for Maya Albana eller kig på det rullenende banner for Jubii Shopping der kører i bunden på Jubii Musik, og som jeg tidligere har skrevet lidt om.

I begge tilfælde er der tale om mindre opgaver, hvorfor strukturen i koden er mindre vigtigt, da der er tilsvarende mindre kode at have overblik over.

Projektets struktur er unik
Hvis du for eksempel har brug for noget der fungerer som et spil kort (ligesom denne her for eksempel), så taler sandsynligheden for at det kan genbruges et andet sted hvor du også skal bruge et spil kort.
Skal du derimod lave noget der er specifikt for netop denne opgave, så kan det stort set aldrig betale sig at lave det som en klasse.
Faktisk, så ville jeg nok vente med at lave kortspillet om til en klassen anden gang jeg fik brug for det ;-)

Når alt det her så er sagt….
….så forsøger jeg selv at skrive rimeligt fornuftig kode:

  • Giver variabler en type
  • Navngiver variabler og andre objekter logisk
  • Holder så meget kode som muligt i frame 1, så det nemt kan overskues
  • Deler næsten alt ind i funktioner

Grunden til dette indlæg skal udelukkende findes i, at jeg gerne ville sige “Du er ikke den eneste” til alle dem af jer andre derude (hvis ikke jeg er den eneste?), som også griber tingene lidt mindre ideelt og lidt mere pragmatisk an :-)



Del:These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • digg

8 kommentarer

  1. CubanPete siger: (24. august 2006 kl. 14:03 )

    Tak tak tak tak tak og så et sidste tak.
    jeg bider mærke i tre væsentlige ting, som beskriver min situation rigtig godt.

    1.
    Jeg får nedtur over al den pæne kode, der ligges ud som sourcefiles på forskellige fora. Mit arbejde er lidt ligesom i et køkken, maden skal laves og derefter spises, og hvis der så er tid tilbage, så rydder jeg op. Ikke den ideelle løsning, men sådan er det. Det er klart, at hvis jeg rydder op sideløbende, vil arbejdet være mere overskueligt, men sådan går det ikke altid.

    2.
    Nedenstående processbeskrivelse er lige i øjet.

    Deadline
    Creative (Oplevelsen, designerens vision)
    Bandwidth (Båndbredde)
    Maintainability (Hvor nemt det er at vedligeholde)

    3.
    Det er ligeledes få gange, at jeg selv har lavet en klasse og brugt den, men på den anden side, så bruger jeg løs, at Flash predefinerede tween, transition osv. klasser. Så måske er det bare tid til at komme i gang. Der er i hvert fald flere af udviklerne fra mit arbejde der bruger dem hyppigt, så mon ikke der er en fidus i dem.

  2. Mads Buch Stage siger: (24. august 2006 kl. 17:54 )

    Pjew….så var jeg rent faktisk ikke den eneste “skodkoder” derude, dejligt at se! :-)

    For øvrigt et super cool website du har dig, altid godt at se video brugt på kreative måder.

    Mads

  3. mat siger: (26. august 2006 kl. 18:55 )

    Jeg tror ikke helt jeg forstår argumentet? Tager det længere tid at skrive en klasse end det gør, ikke at gøre det?

    Jeg kunne sagtens finde på at kode dit eksempel med “Jubii Musik” med flere klasser (umiddelbart en produktklasse og en “manager”, der “styrer” produkterne (og jeg kunne godt komme på flere :) ).
    Det giver dig ihvertfald den fordel at hvis der skal ændres på produkterne, så skal du ikke glo på koden der relaterer sig til manageren. Og hvis du skal lege med præsentationen af alle produkterne går du til den klasse der er ansvarlig for det (og er fri for at glo på koden der intet har med den funktionalitet at gøre). Med andre ord er din funktionalitet opdelt og du ved altid hvor du skal kigge hen.

    Om jeg er en “skodkoder” lader jeg andre om at afgøre, men jeg bruger klasser, og ville helst ikke undvære dem :)

    mvh mat

  4. mat siger: (26. august 2006 kl. 18:57 )

    (iøvrigt en fin blog :) )

  5. Mads Buch Stage siger: (28. august 2006 kl. 10:13 )

    For mig tager det længere tid at skrive en klasse end “bare” at kode det, men indlægget er sådan set ikke så meget for og imod klasser.

    Det er bare tænk som en håndsrækning til dem, der lige som mig, nogen gange godt kan blive lidt smådeprimerede af at se den ekstremt korrekte kode som der altid bruges i tutorials m.m.

    Som oftest er det vigtigste at det virker og at det er klar til tiden :-)

    Når det så er sagt, så deler jeg selv min kode op i logiske funktioner m.m., så det skal ikke ses som at jeg er fortaler for en “grødkode” hvor det hele røres sammen til en stor klæbrig og uadskillelig masse.

  6. Flashger siger: (31. august 2006 kl. 12:54 )

    [b]Programmering, en aldrig-endende historie[/b]

    Rigtig godt indlæg Mads.
    Jeg er selv typen der laver ALT i klasser, og som du rigtigt siger, så er dit indlæg ikke for eller imod klasser (og så alligevel lidt). Men om kodens sammensætning. Jeg får lige så stor nedtur over at se andres klasser, som er “lav koblet”, implementeret med et svedigt designmønster og re-used for hvem-ved-hvilken gang. Det vigtigste i bevistheden om sit arbejde er at kunne reflektere over det, og se på de fremtidige do and don’t man kan udlede deraf. - det uanset om man arbejder med ren procedure kode, eller object orienteret.
    Med hensyn til om man skal bruge klasser, så kridter du jo lidt banen op, ved at nævne eksempler hvor man “ihver fald IKKE skal”. Jeg mener helt sikkert at det at skrive en klasse er en investering i et værktøj som kan genbruges. Det største problem, set med mine øjne, er at folk let kommer til at skrive deres keyframe kode ind i en klasse, og så er det helt sikkert svært at se genanvendelse eller hurtighed ved at lave klasser.
    Som Kaver nævner så bruger man flittigt “andres” klasser som f.eks. Robert Penners mx.transitions.* klasser. - og hvorfor: fordi de er som en klasse skal være: En god klasse skal gøre én ting, og det skal den gøre godt. Det er som legoklodser, man bliver hurigtig træt af den klods der allerede har form som et færdigt lego hus, den har ingen fleksibilitet. Men én klods, kan man bruge i mage huse, store som små.

    Well, det var vist alligevel mere om klasser om hvad jeg egentlig ville sige.
    Props for en god blog.

  7. Mads Buch Stage siger: (31. august 2006 kl. 13:29 )

    Tak for kommentaren, er helt og aldeles enig i det med at betragte klasser som legoklodser, så er det at man nogen gange må spørge sig selv, om den problemstilling man sidder med kan reduceres til en genanvendelig legoklods, eller et stykke playmobil som jo ikke passer sammen med noget som helst andet *g*

  8. Flashger siger: (31. august 2006 kl. 13:38 )

    hehe. du har helt ret! :-)
    - har mit library FYLDT med Playmobil klasser ;-)

Skriv en kommentar