_ Tips På denna sida finns tips för uppgifterna. __ Ordning och organistation - Använd en katalog för varje uppgift - Under hela konstruktionsprocessen: -- Välstrukturerad kod -- Bra namn på klasser, variabler, konstanter __ Evolutionär utveckling Många moderna programmeringsspråk består av: - En liten språkkärna - Ett mycket stort bibliotek av färdigkonstruerade klasser Den självklara fördelen är att man slipper konstruera en stor mängd saker som annars skulle ta mycket lång tid att göra men nackdelen är att det kan vara svårt att veta och hitta vad som finns samt att man inte får samma grundläggande förståelse. > "Matematik är ingenting man förstår, matematik är något som man vänjer sig vid" ½von Neumann½ < Till att börja med bör man skaffa sig en övergripande förståelse för det område man ska ge sig in på. Detta görs bäst med hjälp av böcker, tidningar och/eller de tutorials och artiklar som finns på Internet. När man har skaffat sig en denna övergripande förståelse så bör man så fort som möjligt testa några av de exempel man stött på. Det är ofta först när man praktiskt tillämpar ett område som man lär sig, eller vänjer sig vid, området och därmed får en förankring eller förståelse av beteendet hos objekten man laborerar med. Man bör inte skriva av koden "rakt av" utan man bör istället: - Konstruera en minimal körbar kärna (med sin egen stil på koden) Detta gör man för varje nytt område man ger sig in på. Man kan sedan: - Förändra denna minimala körbara kärna mot ett önskbart mål med £små förändringar£ av koden Detta är mycket viktigt! Man går mot ett önskat mål med: - Små förändringar av koden - Kompilering - Testkörning Man släpper aldrig kontakten med det fungerande programmet: > "We are like sailors who on the open sea must reconstruct their ship but are never able to start afresh from the bottom. Where a beam is taken away a new one must at once be put there, and for this the rest of the ship is used as support. In this way, by using the old beams and driftwood the ship can be shaped entirely anew, but only by gradual reconstruction." ½Otto Neurath½ < Detta är en mycket viktig tumregel. Försöker man förändra koden i stora steg så blir det fel och dessa fel är ofta svåra att lokalisera och rätta till. Ofta samverkar flera fel och detta gör det givetvis ännu svårare. Bygg inte stora program, bygg små program som samverkar: > "The corrective to this tendency comes straight from the old-school Unix hymnbook. It is the Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do—that is, when attempts to partition the problem have been made and failed. This maxim implies an astringent skepticism about large programs, and a strategy for avoiding them: look for the small-program solution first. If a single small program won't do the job, try building a toolkit of cooperating small programs within an existing framework to attack it. Only if both approaches fail are you free (in the Unix tradition) to build a large program (or a new framework) without feeling you have failed the design challenge." ½[Handbrake, http://handbrake.fr/]½ < Ofta är stora programsystem konstuerade av många mindre program där varje program består av program konstruerade enligt ovanstående enkla principer. Man använder sedan program på en nivå som enheter för konstruktion av program på nästa nivå, och även denna process följer de ovan angivna principerna. Slutligen en rolig kommentar: > "Fulhack" is the swedish word for "very elegant small piece of program." ½[BD, http://fulhack.dax.nu/bd/]½ <