Synes du at det er mer enn nok metodikker, strategier, mønstre og inndelinger å holde rede på som utvikler?
Her er tre planer å følge når du støter på et programmeringsproblem!
Når man har støtt på et problem som en programmerer, er det nemlig ingen mangel på mulige strategier, mønstre, taktikker, organiseringer eller andre måter man kan bruke for å løse problemet.
Problemet med dette, er at det kan være vanskelig nok å velge rett metode, om man da i det hele tatt kjenner til den “rette” metoden i det hele tatt.
Siden det ikke er noen problem i programmering som ikke kan løses med et nytt lag av abstraksjon (fritt etter D.J. Wheeler), så følger her tre generelle planer som kan brukes når man vil finne rette løsning på neste problem.
Se en utvikler forklare mikrotjenestene sine: - Jeg går aldri lei denne videoen
Plan A: Finn en enkel og åpenbar løsning på problemet
Ikke alle problem har en enkel og åpenbar løsning. Men, for de som har det, så er denne løsningen ofte ganske så god.
Måten man ser en sånn løsning på, er at man ser på problemet, ser på konteksten og ser, oftest etter utallige timer, umiddelbart at problemet enkelt kan løses med noen få steg på en måte som åpenbart er både korrekt og nær optimal.
Det kan også hjelpe å forsøke og feile på alle tre planene i tur og orden et eller annet utall ganger, før en slik enkel og åpenbar løsning velger å vise seg.
Enkle løsninger tenderer til å raskt kunne implementeres, de krever relativt lite kode og resulterer i kode som er grei å både lese og vedlikeholde.
Et eksempel her kan være, gitt at problemet er å sortere en relativt kort liste, å bruke sort()-funksjonen som er innebygget i den plattformen man jobber i.
"For every complex problem, there is a solution that is simple, neat, and wrong."
— The Internet.
- Lanserer man en løsning uten bugs, har man lansert for sent, mener Ingrid
Plan B: Finn en artig, interessant, gøyal, fiks eller nifty løsning på problemet
For problemløserne og skøyerne blant oss kan Plan B være en favoritt.
Her gjelder det å finne en løsning som muligens kan være korrekt, og som samtidig er litt moro eller artig på et eller annet vis. Denne typen løsninger er gjerne noen man selv, i øyeblikket, synes er veldig elegante og kan gi en god slump mestringsfølelse.
Når nyhetsverdien etter hvert svinner, dog, er det en fare for at man ender opp med kode som ikke er helt enkel for andre (eller en selv en ukes tid senere) å forstå. Men, det er i hvert fall moro så lenge det varer, og noen ganger så er alternativene enda verre.
I tillegg ender man gjerne opp med relativt lite kode i forhold til plan Z, derfor er plan B et godt alternativ når det ikke er noen plan A-løsning å finne.
Som et eksempel, gitt at vi skal sortere en stor liste som er distribuert over flere maskiner og programmereren alltid har hatt lyst til å lære litt om map-reduce, å bruke map-reduce.
«Men, det er i hvert fall moro så lenge det varer, og noen ganger så er alternativene enda verre.»
Advarer mot småfeil: - Ikke ta lett på code reviews!
Plan Z: Bit tenna sammen og bare løs det på den tungvinte måten
Plan Z er den siste planen i dette arsenalet, men også den mest pålitelige.
Her er planen rett og slett å løse problemet på den vanskeligste måten. Denne planen brukes når man ikke finner noen enkle løsninger og ikke engang noen nifty-e. Det som gjenstår da, er å gjøre det på den tungvinte måten.
Dette kan involvere å dele opp problemet, analysere og modellere for å forstå det bedre, skrive masse tester og begynne med det man klarer å løse først, og så ta resten etterpå. Også å hardkode store mengder regler og data havner i denne kategorien.
Et eksempel i denne kategorien er, hvis man skal sortere en liste basert på mange parametere og med kompliserte regler for rekkefølgen internt per parameter og mellom dem, så kan det være at man simpelthen må sette seg ned og kode alle disse reglene i et stort og vanskelig predikat med mange tester på flere nivå.
Løsninger som kommer fra denne planen kan være tungvinte, og vanskelige å forstå og vedlikeholde. Men av og til har man ikke annet valg.
Og av og til, etter å ha jobbet i plan Z en stund, så ser man at der er en Plan A- eller Plan B-løsning for hele eller deler av problemet, likevel.
