Sådan skriver du “god legacy-kode”
Her er nogle hurtige startpunkter til at skrive god legacy-kode. Kode er meget nemmere at skrive end at læse, og den bedste måde at løse problemer på er ikke at skabe dem.
Skriv mindre kode
Mindre kode = mindre potentiale for fejl = mindre at vedligeholde = mindre “dårlig legacy”.
At skrive mindre kode kan ses som den vigtigste måde at forbedre kode generelt på. DRY-princippet kan ses som en naturlig følge og det primære middel til at skrive mindre og opnå mere.
Undgå // TODO og // FIXME
Skrivning af // TODO eller // FIXME bør ses som et rødt flag og en kodelugt.
Om vi oversætter disse kommentarer til deres faktiske betydning, kan “TODO” oversættes til “skabe teknisk gæld”, og “FIXME” kan oversættes til “jeg skriver bevidst en fejl”.
Der kan være sjældne undtagelser, hvor det at udskyde en løsning opvejer fordelene ved at løse problemet nu, men generelt bør TODO og FIXME holdes på et minimum.
Foretrækker etablerede idiomer frem for banebrydende teknologier
Dette kan virke selvmodsigende… at bruge banebrydende teknologier gør koden mere “ny”, ikke sandt? Ja, men det skaber også mulighed for, at kode hurtigere bliver forældet.
Det giver også nye programmører sværere ved at finde ud af tingene. Hvis koden er skrevet ved hjælp af etablerede idiomer og frameworks, er den sandsynligvis lettere at læse og har større chance for at fungere længere ud i fremtiden.
Lad altid koden tilbage i en bedre stand, end du fandt den
Dette kan virke som om det strider mod det “ingen omskrivning”, der blev nævnt i begyndelsen, men løbende forbedringer og refaktorisering er noget andet end at lave en betydelig omskrivning.
Forsøg at få vanen til at forbedre tingene gradvist og gradvist. Nogle gange er der virkelig brug for en stor refaktorering eller omskrivning, men forretningsværdien af dette skal nøje afvejes mod andre prioriteter.
Fortsæt med at forbedre dig som programmør
Læs bøger, læs blogindlæg, læs andres kode, tænk grundigt over design og programmeringspraksis. Reflekter bevidst over din kode og tænk på måder at forbedre den på.
I stedet for at give den tidligere programmør skylden for at efterlade en dårlig arv, skal du sørge for, at du ikke bliver den programmør, der skaber en ny.