Begin met het probleem, niet met de code

Een lege editor heeft het talent om een klein project enorm te laten lijken. De gebruikelijke reactie is meteen code typen die in je opkomt.

Wacht eerst even. Een paar minuten plannen kan “bouw een programma” veranderen in een reeks beslissingen die je echt kunt nemen.

Beschrijf de behoefte

In hoofdstuk 12 bouw je een quizprogramma over een onderwerp dat je zelf kiest. Stel dat iemand het zo beschrijft:

Maak een app voor me met dictionaries, lussen en meerdere functies.

Dat klinkt specifiek, maar het beschrijft een implementatie. Het legt niet uit wat het programma moet bereiken.

Een nuttige probleembeschrijving begint bij de ervaring:

Ik wil een korte reeks vragen beantwoorden en zien hoeveel antwoorden ik goed had.

Nu kun je nuttige vragen stellen:

• Welke informatie hoort bij elke vraag?

• Wanneer telt een antwoord als overeenkomend?

• Wat moet er gebeuren wanneer de cursist niets invoert?

• Wat moet het eindresultaat tonen?

• Wat is de kleinste versie die al nuttig zou zijn?

De programmeermiddelen kunnen even wachten. Zorg eerst dat je begrijpt welk resultaat je probeert te maken.

Schrijf een korte opdrachtomschrijving

Een opdrachtomschrijving is een korte beschrijving van het programma en de grenzen ervan:

Bouw een programma dat een quiztitel en minstens drie records met een vraag en antwoord bewaart. Stel elke vraag, vergelijk antwoorden zonder rekening te houden met spaties aan de buitenkant en hoofdletters, en rapporteer hoeveel antwoorden goed waren. Stel dezelfde vraag opnieuw als een antwoord leeg is.

Deze omschrijving zegt wat het programma ontvangt, welke regel het toepast en wat het oplevert. Ze schrijft geen variabelenamen of exact aantal functies voor.

Scheid eisen van implementatie

Een eis beschrijft waarneembaar gedrag:

• Stel elke geplande vraag.

• Behandel antwoorden met andere hoofdletters of spaties aan de buitenkant als gelijk.

• Accepteer geen leeg antwoord.

• Rapporteer het aantal goede antwoorden.

Een implementatiekeuze beschrijft hoe de code dat gedrag bereikt:

• bewaar elke vraag in een dictionary;

• gebruik een for-lus om de vragen te doorlopen;

• geef de hoofdfunctie de naam run_quiz.

Implementatiekeuzes zijn belangrijk, maar moeten de eisen dienen. Beginnen met een favoriete taalfunctie kan ertoe leiden dat je het verkeerde probleem elegant oplost.

Verklein een project voordat je het uitbouwt

De eerste versie heeft geen accounts, timer, online ranglijst of bewegende confetti bij een perfecte score nodig. Dat kunnen latere verbeteringen worden.

Gebruik drie labels voor de omvang:

• moet: het kleinste gedrag dat het beschreven probleem oplost;

• kan: een nuttige verbetering nadat het noodzakelijke gedrag werkt;

• nu niet: een idee dat bewust buiten deze versie blijft.

“Nu niet” betekent niet “nooit”. Het beschermt het huidige project tegen een omvang die te groot is om af te maken of te testen. Nu de omvang beperken kan een middag besparen waarin je het verkeerde programma verfijnt.

Een herhaalbare startroutine

Voordat je code schrijft:

1. Beschrijf de behoefte van de gebruiker in één of twee zinnen.

2. Benoem het kleinste nuttige resultaat.

3. Maak een lijst van het waarneembare gedrag dat nodig is.

4. Zet aantrekkelijke extra’s bij “kan” of “nu niet”.

5. Kies pas daarna gegevensstructuren, functies, lussen en voorwaarden.

Dit hoofdstuk maakt die routine expliciet. Je hebt onderdelen ervan al gebruikt in eerdere projecten. Nu oefen je haar als een vaardigheid op zichzelf.