Software vedligeholdelse er den praksis med fastsættelse bugs og tilføje funktioner til eksisterende software- platforme til at opfylde skiftende organisatoriske behov. Det bedste skøn om programmering som en karriere , ifølge IEEE, er, at mere end 70 procent af alle edb-programmering timer anvendes i hele verden er afsat til vedligeholdelse af software . Gøre software , der er nemt at vedligeholde tager nogle strategiske tænkning og due diligence i kodning og dokumentation praksis. Instruktioner
1

Start med et design dokument. Specificere, hvad softwaren er meningen at udrette . Beskriv den underliggende metode og logisk proces under den. For ændringer og vedligehold på eksisterende software , beskrive, hvad den eksisterende software ikke gøre, og hvad erhvervslivet eller andre behov kørte gennemførelsen af ​​ændringen . Dette dokument er din rettesnor for , hvad der er og ikke er inden for rammerne af denne software engineering projekt.
2

Skriv din kode modulært . Hvis du kan , skal du oprette et nyt modul kode, der præsenterer data på måder, at den eksisterende software kan udnytte. Hvis du ikke kan , skal du sørge dokument , hvorfor og hvordan du har ændret den eksisterende software til at tage den nye dataformat.
3

Bevar din variable forbrug til modulet kode du arbejder i når der tilføjes nye variabler . Når du bruger de eksisterende variabler , mener to gange om at gennemføre enhver kode eller procedurer, der skriver data til dem - det er den største årsag til at forårsage fejl og software glitches nede ad vejen
4

Kommentar og dokumentere din kode . . Hver gang du definerer en variabel , dokument , hvad der går ind i den variable , og hvor det vil blive brugt. Hver gang du skriver data til en variabel , dokument , hvad der bliver skrevet ind i det, acceptable formater for disse data , og hvad du forventer for udfaldet . Formålet med dette niveau af inline kommentering og dokumentation er at gøre det muligt for en person (som du , seks måneder senere ) for at læse koden og finde ud af , hvad modulet gør , uden at skulle bruge tid sammenlignes med at skrive det at stykke det sammen .
5.

Test de " dumme anvendelser" også. Hver softwareudvikler har skyklapper på . De ved, hvad koden er meningen at gøre , de vil ikke prøve noget , fordi det ser fornuftigt , men er ikke en del af programmet. Det er altid en god idé - også selvom det er tidskrævende - at sætte dit software foran ikke-tekniske brugere, der ville ellers blive konfronteret med det, og observere, hvordan de interagerer med koden
< . br >