Systemutveckling handlar om att modellera och automatisera någon process i verkligheten. Det kan vara att ge användaren möjlighet att öppna en fjärrstyrd ventil från sitt kontor genom att trycka på en digital knapp på sin skärm eller en integration mellan två affärssystem som gör att när en order skapas i det ena så dyker den också upp i det andra (helst omgående).
Modellerna är abstraktioner, en bunt primitiva datatyper (eller samlingar av andra abstraktioner) som man namngett och kollektivt kommit överens om att detta är vad vi menar när vi pratar om ”x”. Där ”x” kan vara en inköpsorder, ett melee vapen i något spel eller en tand i det där programmet tandläkaren klickar i när hen dokumenterar vart dina hål är.
I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
Det jag inte förstår är varför programmerare inte brukar vara mer intresserade av sin domän och dess abstraktioner. Vi kan också säga ”bransch” och nu menar jag inte att du jobbar i mjukvarubranschen, utan den bransch där problemen du löser finns.
Med tydliga domänobjekt undviks språkförbistring, speciellt om kommunikation sker mellan människor med olika modersmål. Systemet kommer upplevas mer logiskt och förändringar är enklare att resonera kring.
Människans hjärna är bäst på att känna igen symboler, färger och saker och inte kalla, råa siffror. Skapa en värld och berättelse kring ditt system man kan känna igen.
Visst, skall vi koppla ihop de där affärssystemen kanske det allra mest intressanta för en tekniker är att välja vilken mapp filen skall mellanlanda i, eller sätta upp något häftigt meddelande middleware så datan inte ens behöver skrivas till disk på sin resa mellan systemen.
Men när datan sedan skall hämtas, omformas och berikas frågar du dig själv inte då lite filosofiskt; vad är egentligen en order? Finns alltid det här fältet? Vad ens är det här fältet? Vad betyder det här fältet i kontexten av källsystemet? Vad kallas samma sak i målsystemet? Använder ens det systemet samma typ av abstraktion? Vad händer i verkligheten om fältet ibland inte kommer med för att min try-catch sväljer alla problem när det blir lite jobbigt? Kan någon vuxen berätta för mig exakt vad jag skall göra?
Thus the programmer must be able to explain, for each part of the program text and for each of its overall structural characteristics, what aspect or activity of the world is matched by it. Conversely, for any aspect or activity of the world the programmer is able to state its manner of mapping into the program text.
Peter Naur – Programming as Theory Building
Det är inte bara enstaka fälts vara eller inte vara som är intressant. För beroende vad nuvarande värdet på ett fält är kan göra att värdet på ett relaterat fält blir ologiskt. Och det är inte alltid självklart hur de ens är relaterade. Kan levererad mängd vara mer än beställd?
Här skall du som proffs gå till användaren och fråga vad är det här fältet till för och vad händer ifall det saknas. Vill du ha ett larm om det händer? Kan du hjälpa mig kolla i systemet när jag skickar ett test ifall det blir rätt? Har alla människor alltid 32st tänder?
Personen kommer säkert uppskatta att du värdesätter hens kunskap och vara mer villig att använda den nya mjukvaran du kodar.
Mera läsning
Domain-Driven Design: Tackling Complexity in the Heart of Software