manutenção de software é a prática de correção de bugs e acrescentando recursos para plataformas de software existentes para atender às necessidades organizacionais. A melhor estimativa sobre a programação como uma carreira, de acordo com o IEEE , é que mais de 70 por cento de todas as horas de programação de computador utilizados em todo o mundo são dedicados à manutenção de software . Fazendo software que é fácil de manter leva algum pensamento estratégico e due diligence em práticas de codificação e documentação. Instruções
1

Comece com um documento de design. Especifique o que o software deve realizar. Descrever a metodologia e processo lógico debaixo dela. Para modificações e manutenção de software existente, descrever o que o software existente não fez, e que o negócio ou outra necessidade levou a implementação da mudança. Este documento é o seu guia para o que é, e não é , no âmbito do projeto de engenharia de software .
2

Escreva seu código modular . Se você puder, crie um novo módulo de código que apresenta dados de uma forma que o software existente pode utilizar. Se não for possível , certifique-se de documentar como e por que você mudou o software existente para assumir o novo formato de dados.
3

Restringir o uso da variável para o módulo de código que você está trabalhando em quando a adição de novas variáveis. Quando o uso de variáveis ​​existentes , pensar duas vezes antes de implementar qualquer código ou procedimentos que gravam dados a eles - esta é a causa número um de causar bugs e falhas de software no caminho
4

Comentário e documentar seu código. . Toda vez que você definir uma variável , documentar o que vai para a variável e onde ele será usado. Toda vez que você gravar dados em uma variável, documentar o que é escrito para ele , os formatos aceitáveis ​​para que os dados , eo que você espera para o resultado. O objetivo deste nível de linha comentando e documentação é para torná-lo possível para alguém (como você , seis meses depois ) para ler o código e descobrir o que o módulo faz sem ter que gastar tempo comparável ao escrevê-lo para remendá-lo juntos .
5

Teste os "usos burros" também. Cada engenheiro de software tem antolhos . Eles sabem o que o código é suposto fazer , não vai tentar algo porque parece sensato , mas não faz parte do programa. É sempre uma boa idéia - mesmo que seja demorado - . Colocar o seu software na frente de usuários não-técnicos que havia outra forma, seriam confrontados com ele e observar como eles interagem com o código