Rewrites og reviews er gode ideer 19. jan 2010

Arbejdet med Paginata går strygende - faktisk så godt at jeg stritter lidt imod det udbredte "råd" mod rewrites.

Men egentlig så skriver jeg det jo ikke om fra bunden - jeg "refactorer" - altså ændrer koden i et fungerende system så den bliver mere overskuelig, mere elegant, og forhåbentlig nemmere at arbejde videre på. At jeg kører peterlind.dk på Paginata imens jeg udvikler er måske ikke ligefrem en rendyrket unittest, men det er ikke desto mindre et meget godt minimumseksempel på hvad systemet skal kunne. Jeg er dog ved at planlægge nogle unittests, især til når jeg skal arbejde mere med datatyper og formattering, men mere om det til den tid.

Hvis jeg skal klappe mig selv på ryggen, så synes jeg at jeg følger Brooks' råd "build one to throw away" - den første udgave af Paginata voksede op imens jeg lærte hvad jeg kunne, hvad PHP kunne, og hvad systemet skulle kunne, og blev selvsagt lidt et miskmask af skiftende arkitektur-ideer. Nu tager jeg det der holdt og bygger et nyt system der kan det samme.
Men for nu at blive ved Brooks, så kan jeg altså godt mærke "the second system effect" - jeg har hele tiden lyst til at lave alle mulige super-avancerede ting, og det kribler i fingrene for at gøre det hele endnu mere "arkitektureret" end nødvendigt. Det er jo en kendsgerning at systemet aldrig nogensinde skal gøre andet end at læse data fra en database og vise dem i html - og vice versa: modtage input fra html-formularer og gemme det i databasen. Derfor er der ikke nogen grund til at generalisere alt, og bruge MVC-patterns for hver eneste lille dataelement, og det er ikke nødvendigt at bygge store ORM-strukturer og lave et programmeringssprog i programmeringssproget. Af og til må jeg lige give mig et dask over fingrene og huske mig på at jeg kun skal lave ting hvis de vil spare mig for arbejde i fremtiden, ikke blot fordi det er "smart", "elegant" eller "fleksibelt".

HTML er ikke tekststrenge!

Der er mange ting i Paginata der er noget sjusk - blandt andet er var der en masse kode der byggede htmlkode op ved at konkatenere strenge, og andet kode der analyserede html'en ved hjælp af regulære udtryk. Og det er bare en dårlig ide. Brug aldrig regulære udtryk til at fortolke html! så er det sagt.

Det har jeg arbejdet på at få fjernet i den seneste release, men samtidig opdager jeg en masse andre ting der bør ændres tilsvarende, for eksempel har jeg været ret inkonsekvent med hensyn til navngivningen af metoder (eller funktioner som det var før i tiden) - det er tit svært for mig selv at regne ud hvad en metode gør, uden at jeg skal ind og kigge på selve koden. Og det synes jeg er et af de bedste argumenter for refactoring - hvis koden kan gøres lettere at forstå for (andre) mennesker, så gør det for dælen! Der er ikke andre der er afhængige af mit api, så jo før jeg ændrer tingene, jo bedre!

API og code-review

Det er svært at skrive et godt API selv - det metodenavn der giver rigtig god mening den ene dag, virker komplet tåbeligt den næste. Når man har skrevet tre næsten ens klasser, men med lidt forskellige metodenavne, så begynder man at ønske at man havde lavet det anderledes. Heldigvis kan jeg bare lave det anderledes, men det sker utrolig hurtigt at man skriver sig ind i en dårlig vane. Jeg har set masser af eksempler på vanvittig dårlige interne api'er i min tid - en eller anden i firmaet skrev engang noget kode, han var enten ordblind, dårlig til engelsk, eller tastede ganske enkelt forkert, og nu sidder alle og skal bruge det samme irriterende api - for jo flere der bruger det, jo sværere er det at omdøbe.

Så jeg laver masser af omdøbninger og ændringer her i starten - men jeg kunne godt bruge et review af mine navngivninger. Bevares, jeg spørger hele tiden bekendte på nettet (især Søren og Anders), men det er jo ikke et "rigtigt" review. Derfor må eventuelle testere bære over med mig, hvis der viser sig at være alt for mange dårlige navne, og alt for meget kode der hele tiden ændres.

Men det giver mig da de erfaringer at det langt fra er nok med én arkitekt til et system - der er nødt til at være en dialog, hvis det også skal forventes at kunne bruges og forstås af andre engang i fremtiden.

Tilføj kommentar

www.peterlind.dk

Nyeste blog-indlæg