đČ â mikrobloggeriet olorm â olorm-15 · olorm-16 · olorm-17
De siste dagene har jeg tenkt litt pÄ hvordan jeg bruker zooming i programmering.
â
Jeg liker Ă„ skrive tester fĂžr jeg skriver implementasjon. Av og til merker jeg en slags ubalanse hvor feks testene jeg skriver ikke henger sĂ„ godt sammen med implementeringen. Eller at implementeringen er vanskelig. Da har jeg lĂŠrt meg til Ă„ se etter et âmindreâ problem Ă„ lĂžse ved Ă„ enten zoome inn eller zoome ut.
Jeg kan prÞve meg pÄ et tenkt eksempel:
Se for deg at du vil lage en funksjon som tar inn en liste med tall, og returnere en ny liste som er som input-listenâmen alle tallene er lagt sammen med tallet til venstre for seg selv ganget med tallet til hĂžyre for seg selv. Se for deg at du skriver litt eksempeltester, og det gĂ„r greit til Ă„ begynne med, men etter hvert som eksemplene blir mer kompliserte blir implementasjonen vanskeligere. Helt til du innser at inni implementasjonen din ligger det en litt rĂŠva reduce-implementasjon. (Her later vi som programmeringssprĂ„ket ditt ikke har noen reduce fra fĂžr.) Nice! Da kan du zoome ut.
Lag en ny fil/modul/klasse hvor du skriver tester for og implementerer reduce-en din uten stÞyen fra de obskure detaljene i den originale oppgaven din. NÄr du er fornÞyd (nok), kan du zoome inn igjen og fortsette pÄ den originale oppgaven.
Flippen er at du kanskje sĂ„ at âlegge sammen med et tall og gange med et annet tallâ er Ă©n ting du gjĂžr mange ganger i problemet ditt. SĂ„ hva er enklere enn Ă„ gjĂžre Ă©n greie med mange ting? Det er Ă„ gjĂžre Ă©n greie med Ă©n ting! SĂ„ da kan vi zoome inn og lage en ny funksjon feks, som legger sammen et tall med et annet tall ganger det med et tredje tall. Zoom ut til originalproblemet ditt nĂ„r du er ferdig.