Utveckling & koddesign

Tweets från hösten 2013.

Det är väldigt vanligt för projektledare och produktägare att fråga om koden är väldokumenterad. Fråga hellre om god testtäckning. (12/10.) Och vad är god testtäckning? Att man skrivit kod som testar koden och att man testar tillräckligt många verkliga scenarier. (12/10*.)

Arv i verkligheten handlar om tillgångar. Legacykod handlar om skulder. Teknisk skuld. (13/10.)

I funktionell programmering finns en princip om att skicka all kontext som parametrar. Det gör det kostsamt med beroenden. Vilket är bra. (29/10.) I objektorienterad programmering kan man göra beroenden dyra genom att jobba testdrivet. Ju mindre kontext att sätta upp desto smidigare. (29/10.)

En metod är av sämre kvalitet ju fler rader den är och ju fler objekt den kommunicerar med, vare sig via parametrar eller instansvariabler. (31/10.) Ett objekts kvalitet avgörs direkt av dess metoders kvalitet. (31/10.) Det gäller mätbar kvalitet. Namngivning, tydlighet i konceptuell identitet och kollaborationer mellan objekt är viktigt, men svårt att mäta. (31/10.)

I ”skinny controller, fat model” syftar modell på samtliga objekt i modellen. Och modell betyder inte något lagrat i en databas. (24/11.) Inget enskilt objekt i modellen ska alltså vara fett. (24/11.) Nu verkar ”modell” oftast användas som synonymt med enskilda objekt som mappar mot databastabeller. Se Martin Fowlers definition.

Att vara utvecklare förutsätter ett intresse för koddesign. Såvida inte man bara jobbar med projekt som släpps och aldrig vidareutvecklas. (24/11.) Att vara utvecklare förutsätter också ett intresse för process. Såvida man inte jobbar solo med projekt som är sådana engångsföreteelser. (24/11.) Möjligen skulle man kunna vara utvecklare utan intresse för koddesign & process om man finner sig i att följa andras design- och processval. (24/11.) Koddesign och process är ekonomi, för att parafrasera Olle Eksell. Det är blodigt allvar. (24/11.)

”The price of reliability is the pursuit of the utmost simplicity”, C.A.R. Hoare. (26/11.)

Broken windows-teorin kanske inte håller i den fysiska världen men när det gäller kod… (30/11*.)

Du betalar när du lägger till en instansvariabel. Än mer för en getter. En setter är asdyr. För att inte tala om nya beroenden till objekt. (30/11*; här menade jag kostnad för framtida ändringar, inte prestanda, en i jämförelse kontrollerbar kostnad.)

Går man från webb- till iOS-appar inser man vilken oerhörd betydelse små täta släpp har. (30/11.) En iOS-app blir fort komplex och kräver disciplin att hålla i schack. Längre släppcykler gör manuella tester svårare. Det ökar behov av TDD. (30/11.) Man ska nog bryta isär skoningslöst i iOS-utveckling. Ingen klass eller metod får bli för stor. Gäller särskilt views och view controllers. (30/11.) Framförallt bör man undvika att driva utveckling från UIKit. Testdriv plain old objects och limma in dem i UIKit. (30/11.)

Något jag också reagerat på är hur webb naturligt segmenteras: i backend appkod, kanske API, databas, cachar m m; i frontend HTML, CSS, JS. (30/11.)

När du lägger till kod nånstans, fråga om det egentligen hör hemma nån annanstans; i en annan metod eller annat objekt. Varje del ett syfte! (1/12.) När du beskriver ett objekts eller en metods syfte med en mening, var på din vakt om du måste använda ”och”. (1/12.)

När du namnger objekt och metoder, var så smal och specifik du kan. Utgå från syftet och välj ett namn som inte inkluderar något utöver det. (1/12*.) Allt för allmänna namn på objekt korrumperar. Se upp med suffix som ”manager”, ”helper”, ”handler” och ”controller”. (1/12.)

Frågan är om man inte stjälper när man lär ut OO med exempel som Animal, Predator, Lion eller även Shape, Rectangle, Square. (1/12*.)

När du skickar ett objekt som parameter, fråga dig om mottagaren alls bör veta om dess existens. För kod är segregering bra. (3/12.)

För datum med asterisk efter sig finns kommentarstrådar på Twitter.