Quiero compartir mis pensamientos sobre una de las cualidades del software: mantenibilidad.
Los proyectos no siempre prestan atención a la mantenibilidad. Como resultado, con el cambio de equipo, comienzan las dificultades. Especialmente si el equipo cambia inesperadamente y con una gran composición.
En proyectos, desempeñé el papel de QA. Entre otras cualidades, era necesario cuidar el acompañamiento. Del lado de los programadores, en primer lugar, está implícito que el código debe ir acompañado de comentarios y una buena estructura. Mientras tanto, el acompañamiento es algo más. La buena capacidad de mantenimiento le permite beneficiar al fabricante del producto de software. No sin razón, en las grandes empresas puedes encontrar programas antiguos que están lejos de ser la interfaz más amigable, pero tienen una buena capacidad de mantenimiento. Debido a esto, no tienen prisa por reemplazar el desarrollo de empresas competidoras.
Puede dar una analogía con la colocación de electricidad en un edificio:
- Un buen electricista le proporcionará sus circuitos antes de instalar el cableado. No será necesario, incluso después de muchos años, recurrir a él para comprender qué conduce a dónde y cómo funciona. No habrá problemas durante la operación.
- Si el electricista no hace el diagrama de cableado, la próxima vez solo lo contactarán, porque a excepción de él, nadie sabe cómo está organizado todo, entonces debe pensar si vale la pena hacer negocios con él.
Como probador, puedo ofrecerle que preste atención a los siguientes aspectos para aumentar la capacidad de mantenimiento.
Documentación de funcionalidad.
Se necesita documentación no solo para “usuarios en algún lugar”, sino también para que a las 12 del mediodía cualquier persona que no esté familiarizada con el producto pueda usarlo sin pedir ayuda a otros. Por ejemplo:
- un programador contratado ayer podría depurar una función,
- el soporte técnico podría responder la pregunta del usuario
- el probador podría verificar si algo en una característica desconocida se rompió.
Documentación de infraestructura
Es muy probable que se utilicen muchas herramientas para crear el producto. Entre ellos:
- sistema de montaje. Quizás consta de varias máquinas, cada una de las cuales tiene muchas configuraciones;
- otros servicios de infraestructura, como servidores de archivos, sistema de almacenamiento de código (especialmente si hay dependencias de la biblioteca en otros sistemas), etc.
- bancos de pruebas. Su configuración y descripción deben estar en los planes de prueba.
Todo esto está ligado al proyecto. Y sería bueno tener una descripción detallada de la estructura, de modo que pueda restaurarla fácilmente si falla el disco duro con las máquinas de la estructura. O para que pueda realizar cambios sin esfuerzo en la infraestructura sin perder tiempo estudiando cada pequeña cosa.
Documentación de problemas y riesgos.
En el proceso de creación y operación del producto, seguramente surgirán problemas. Se pueden clasificar y describir como una base de solución.
Algunos defectos pueden tener una solución alternativa. Si el defecto es grave, entonces debería ser posible encontrar una solución en la base de datos de problemas. Por ejemplo, si alguna configuración se puede establecer solo en un navegador específico.
Si el desarrollo revela información de que pueden surgir problemas en el futuro, entonces dicha información debe describirse como riesgos. Por ejemplo, si se usa un módulo en un sistema con 100 usuarios, probablemente se romperá con 500 usuarios.
Comentarios y descripciones de códigos
Puede haber un documento con una descripción técnica de todos los módulos, incluida la inclusión de todos los esquemas arquitectónicos.
Información sobre las herramientas utilizadas.
Por ejemplo, qué herramientas y cómo usar para depurar y probar.
A veces, un programador puede necesitar herramientas de prueba para depurar la funcionalidad. O el probador puede necesitar información sobre las herramientas del desarrollador para recopilar información cuando se encuentra un defecto.
Incluirlo merece la pena prestar atención a la prevalencia de las herramientas. Incluso si alguna herramienta es adecuada para la tarea en cuestión, pero es antigua y no es compatible, puede ser difícil.
Tarea completada
Como dice el principio de Pareto: toma el 80% del tiempo completar el 20% del trabajo.
Y si algo no se completa, entonces debe haber una razón. Lo más probable es que fuera caro.