Idealistisk arkitektur och svinig kod

I dagens Computer Sweden skriver Mikael Lindvall, forskare på Fraunhofer Center for Experimental Software Engineering en krönika med titeln “Så håller du koden i schack”. Han beskriver ett projekt han deltagit i där “många olika programmerare hade ändrat i koden” vilket till slut gjorde den “oläslig” och där de bestämde sig göra något åt det och säkerställa att de inte hamnade i samma situation igen.

Vi definierade en arkitektur som förklarade vilka huvudkomponenterna var och hur de skulle kommunicera med varandra. [...] När en ny programmerare kommer till projektet är vi noga med att förklara arkitekturen och varför den ser ut som den gör. [...] Implementeringen måste följa arkitekturen och de designregler vi definierat.

Jag reagerar först och främst på att de behöver förklara “varför [arkitekturen] ser ut som den gör”. Givetvis måste nykomlingar i projektet introduceras, men jag tänker på att en idealiserad arkitektur skulle i stor utsträckning kommunicera sig själv. Den skulle vara intuitiv. Den skulle röra sig med koncept som förmedlar mycket enbart med sina namn (se Cohens lag). Det skulle vara koncept med hög informationsladdning.

Sedan tycker jag egentligen att det hela är lite bakvänt. Det som Mikael Lindvall beskriver är ett scenario där arkitekturen formuleras och där man sedan följer den. Naturliga språk kan beskrivas med grammatik, men grammatiken skapades just för att beskriva språket, inte för att definiera det. Åven om det finns språkpoliser som kräver att man ska vara grammatiskt korrekt så följer grammatiken språket på det sätt att den måste omformuleras när en ursprungligen grammatikvidrig användning blir dominerande. Åndå har naturliga språk en elegans och självklarhet som gör att ett barn kan lära sig ett språk endast genom att utsättas för det. Med tiden lär det sig språkets regler och kan uttrycka nya saker på ett sätt som andra förstår, i stället för att bara upprepa vad dess föräldrar sagt.

Så en idealistisk arkitektur borde uppstå mer eller mindre av sig själv. Lika lite som man först skapar en grammatik och därefter får lära sig att uttrycka sig i tal och skrift enligt denna grammatik¹ borde “uttryckande” i programkod vara underkastat arkitekturen. I alla uttrycksformer uppstår “arkitekturen” parallellt med att något uttrycks² och det är intressant att fundera på vad som saknas inom systemutveckling för att detta naturligt ska kunna ske.

Sedan tycker jag det finns en motsägelse i Mikael Lindvalls krönika. I inledningen skriver han att “detaljerna är så oerhört viktiga”, dvs. att anledningen till att en källkod upplevs som oläsbar är att den har så mycket detaljer (så tolkar jag honom). “Någon har infört en rutin och gradvis utökat den för att få den att fungera i alla möjliga situationer”, skriver han och fortsätter:

Hade programmeraren vetat allt han behövde tidigare hade han kanske kunnat programmera på ett mer strukturerat sätt. Problemet är att han inte kände till alla specialfall i förväg utan lärde sig efterhand.

Men bara för att man har en arkitektur innebär det inte att man alltid vet allt man behöver veta förrän man påbörjar implementeringsarbetet. Först då tvingas man ställa frågor man inte tänkt på i början. Sedan så handlar ju inte arkitekturen om detaljerna. Möjligen får man fack att stoppa detaljerna i, men man kommer inte ifrån problemet att utforma en arkitektur innan man har svar på alla frågor, särskilt de man inte ännu tänkt på.

Till sist så reagerar jag på den vanliga tanken att kunskap är “inbyggd i koden”. Källkod kan aldrig utgöra kunskap, utan bara beskriva kunskap olika bra. Svinig kod beskriver naturligtvis inte kunskap på ett bra sätt och i det sammanhanget spelar det ingen större roll hur väl den fungerar, eftersom det Mikael Lindvall skriver om gäller förändring av källkod. Att “kasta ut” kod betyder inte att man inte kan ha den som referens. År det svinig kod är det förstås ingen lättläst referens, men risken att ändringar får sidoeffekter är större i svinig kod och i det sammanhanget kanske det är värt att överväga att gå ned i funktionalitet genom att “kasta ut” koden, men behålla den som referens.

¹ Självklart finns det artificiella språk, såsom t.ex. Esperanto och Interlingua, men dessa språk är inte skapade oberoende av de språk som uppstått naturligt, utan drar snarare nytta av naturliga språk.

² Åven här finns det “artificiella” uttrycksformer, där formen först etableras och man därefter skapar verk inom dess ramar. Det är möjligt att man kan se t.ex. Piet Mondrian%s och (person)Theo van Doesburg%s måleri inom konströrelsen de Stijl som en artificiell uttrycksform.