Quero compartilhar meus pensamentos sobre uma das qualidades do software: manutenção.
Os projetos nem sempre prestam atenção à manutenção. Como resultado, com a mudança de equipe, as dificuldades começam. Especialmente se a equipe mudar inesperadamente e com uma grande composição.
Em projetos, desempenhei o papel de controle de qualidade. Entre outras qualidades, era necessário cuidar do acompanhamento. Do lado dos programadores, em primeiro lugar, está implícito que o código deve ser acompanhado por comentários e uma boa estrutura. Enquanto isso, acompanhamento é algo mais. A boa manutenção permite que você beneficie o fabricante do produto de software. Não é por acaso nas grandes empresas que você pode encontrar programas antigos que estão longe da interface mais amigável, mas que têm boa manutenção. Devido a isso, eles não têm pressa em substituir o desenvolvimento de empresas concorrentes.
Você pode fazer uma analogia com a disposição da eletricidade em um edifício:
- Um bom eletricista fornecerá seus circuitos antes de instalar a fiação. Mesmo depois de muitos anos, não será necessário recorrer a ele para entender o que leva aonde e como funciona. Não haverá problemas durante a operação.
- Se o eletricista não fizer o diagrama de fiação, na próxima vez em que o contatar apenas, porque exceto ele, ninguém sabe como tudo está organizado - então você deve pensar se vale a pena fazer negócios com ele.
Como testador, posso oferecer uma atenção aos seguintes aspectos para aumentar a capacidade de manutenção.
Documentação de funcionalidade.
A documentação é necessária não apenas para “usuários em algum lugar por aí”, mas também para que, às 12 horas, alguém que não esteja familiarizado com o produto possa usá-lo sem pedir ajuda a outros. Por exemplo:
- um programador contratado ontem pode depurar um recurso,
- o suporte técnico pode responder à pergunta do usuário
- o testador poderia verificar se algo em um recurso desconhecido quebrou.
Documentação de infraestrutura
Muitas ferramentas são provavelmente usadas para criar o produto. Entre eles:
- sistema de montagem. Talvez consista em várias máquinas, cada uma com muitas configurações;
- outros serviços de infraestrutura, como servidores de arquivos, sistema de armazenamento de código (especialmente se houver dependências de biblioteca em outros sistemas), etc;
- bancadas de teste. Suas configurações e descrição devem estar nos planos de teste.
Tudo isso está ligado ao projeto. E seria bom ter uma descrição detalhada da estrutura, para que você possa restaurá-la facilmente se o disco rígido com as máquinas da estrutura falhar. Ou então, você pode facilmente fazer alterações na infraestrutura sem gastar tempo estudando tudo.
Documentação de problemas e riscos
No processo de criação e operação do produto, certamente surgirão problemas. Eles podem ser classificados e descritos como uma base de solução.
Alguns defeitos podem ter uma solução alternativa. Se o defeito for grave, será possível encontrar uma maneira de contorná-lo no banco de dados de problemas. Por exemplo, se alguma configuração puder ser definida apenas em um navegador específico.
Se o desenvolvimento revelar informações de que problemas podem surgir no futuro, essas informações devem ser descritas como riscos. Por exemplo, se um módulo for usado em um sistema com 100 usuários, provavelmente será interrompido por 500 usuários.
Comentários e descrições de código
Pode haver um documento com uma descrição técnica de todos os módulos, incluindo todos os esquemas de arquitetura.
Informações sobre as ferramentas utilizadas
Por exemplo, quais ferramentas e como usar para depuração e teste.
Às vezes, um programador pode precisar de ferramentas de testador para depurar a funcionalidade. Ou o testador pode precisar de informações sobre as ferramentas do desenvolvedor para coletar informações quando um defeito for encontrado.
Inclusive vale a pena prestar atenção à prevalência de ferramentas. Mesmo se alguma ferramenta for adequada para a tarefa em questão, mas é antiga e não é suportada, pode ser difícil.
Conclusão da tarefa
Como diz o princípio de Pareto: são necessários 80% do tempo para completar 20% do trabalho.
E se algo não for concluído, deve ter havido uma razão. Provavelmente, era caro.