2.2 Programación de software
20 febrero 2018
[ Estás en Unidades Didácticas / Unidad 2. Técnicas y recursos ágiles / 2.2 Programación de software ]
El código limpio [1] es la mejor técnica de programación que existe. Si un código se explica por sí mismo y no es redundante ni pesado de leer sólo le falta ser eficiente para ser el mejor código para nuestro proyecto. Si no es eficiente, el hecho de que sea limpio permitirá mejorarlo utilizando un esfuerzo soportable por el equipo de desarrollo. Existen muchas técnicas que nos ayudarán a mantener un código limpio.
Cada empresa ágil ha de definir su propia guía de estilo o basarse en una guía ya existente. Todos los desarrolladores se han de comprometer a usarla, preferiblemente desde que comienzan a crear el código y no dejando trabajo de refactorización para más adelante.
Refactorización
La Refactorización (caché) es una técnica de estilo con la que el código resulta más legible para el programador.
Fuentes
Programación por pares
Con la Programación por pares (caché) existe una retroalimentación constante entre dos programadores mientras trabajan con la misma tarea. Cada acción realizada por uno de ellos puede ser cuestionada, validada, consensuada… de forma inmediata. Como todas las técnicas que supongan un cambio en los hábitos del programador puede parecer que no aporta nada al código final obtenido durante los primeros días o semanas de uso de esta técnica pero en general es una técnica que produce código más limpio y eficiente que la simple suma del código generado individualmente. Esta técnica puede generar un gran aumento de productividad cuando todos los programadores del equipo son capaces de simultanear el desarrollo de una tarea con cualquiera de sus compañeros.
Fuentes
Integración continua (CI)
La integración continua pretende que siempre que sea posible se incorpore el desarrollo en curso al producto para poder hacer pruebas lo antes posible y detectar pequeñas inconsistencias antes de que éstas puedan crecer. Cada día pueden integrarse muchas funcionalidades al producto, cada una en el momento en que se ha terminado de desarrollar y no esperando a tener mucho código para incorporarlo.
Fuentes
Pruebas
Con las pruebas unitarias (caché) el programador puede poner a prueba cada requisito del proyecto antes de introducir su código en producción. Cada lenguaje de programación tiene sus herramientas para poner a prueba el código que queremos generar desde el momento en que comenzamos a desarrollarlo, probar el código constantemente no supone generalmente una pérdida de tiempo ni de confianza, todo lo contrario, ayuda a detectar los inevitables errores que aparecerán en el código antes de que sea demasiado tarde y afianza los conocimientos del programador conforme interioriza los procesos realizados por las máquinas en las pruebas realizadas.
Las pruebas de software (caché) se pueden plantear desde muchas perspectivas en funcíon del software que estamos desarrollando y de sus características en cada momento del proceso.
Los casos de prueba (caché) constituyen un proceso más complejo.
Fuentes
Uso de estándares
El uso de estándares (caché) suele dar mayor prevalencia en el tiempo y posibilidades de reutilización al software desarrollado, además de facilitar la conexión de diferentes módulos de código reduciendo errores. Los estándares se utilizan por muchos programadores lo que garantiza que si son de calidad serán aceptados y que cualquier error que se detecte puede ser resuelto para toda la comunidad.
ISO 15504
Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.
En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la evaluación de los procesos del ciclo de vida del software. Este trabajo recibió el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination), y en junio de 1995, con la publicación de su primer borrador, desde ISO fueron invitadas diferentes organizaciones para aplicarlo y valorar sus resultados.
En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo pasó a la fase de informe técnico con la denominación ISO/IEC TR 15504. La instrucción técnica consta de 9 apartados, recogidos en volúmenes independientes que se han ido publicando como redacción definitiva del estándar internacional ISO/IEC 15504 durante el periodo 2003 – 2005.
La página oficial ISO 15504 en España muestra el listado de las empresas que cuentan con este certificado, además de recomendarnos la lectura del libro Modelo de madurez de ingeniería del software, cuya introducción recuerda aspectos ya tratados en esta asignatura:
Desde hace varios años se viene insistiendo en la “crisis” de la ingeniería del software y en los desastres que los fallos de los productos software pueden llegar a causar en las organizaciones [Piattini et al., 2014]. En la evolución experimentada por la calidad de los sistemas informáticos se ha pasado de un tratamiento centrado fundamentalmente en la inspección y detección de errores en los productos software, a una aproximación más sistémica que considera otros componentes organizacionales que afectan a la calidad del software, y especialmente a los procesos de software…
Fuentes
Guía de estilo
El código ha de ser revisado en algún momento posterior a su creación, por el mismo desarrollador o por otro, por lo que debería seguir unas normas de estilo que faciliten su comprensión por cualquier miembro del equipo de desarrollo, como el uso de `CamelCase` para nombres de clases que se propone en PEP8, la guía de estilo para código Python.
Fuentes
Notas: