Sí.
Producir código que no es legible, no es mantenible, no está bien documentado, etc. es simplemente poco profesional. Ya sea que la organización o el equipo tenga un estándar de codificación, revisiones de código, etc., los desarrolladores de software deben asumir la responsabilidad de producir un producto de trabajo que sea un activo para la organización, en lugar de un gasto/responsabilidad para la organización. Desarrollar código no mantenible es incurrir en una deuda técnica que aumentará los costes de mantenimiento más adelante (o incluso durante el desarrollo), o requerirá una reescritura completa o de parte o de todo el código, si los mantenedores no pueden mantenerlo de una manera rentable.
Lamentablemente, esto no siempre sucede en la práctica, especialmente en organizaciones o equipos inmaduros. Pero eso no significa que no deba ocurrir. En realidad, no es tan difícil de conseguir, si se tienen algunas directrices sólidas para empezar, y se consigue la participación de todo el equipo y de la dirección.
Echa un vistazo a estas publicaciones del blog para obtener más información:
- ¿Cómo podemos escribir software que no sea etiquetado como «código heredado» demasiado pronto? – Truth in Software (bytellect.com)
- ¿Es realmente importante desarrollar código mantenible? – Truth in Software (bytellect.com)
- ¿Por qué mi equipo necesitaría normas o directrices de codificación? – Truth in Software (bytellect.com)
- Escribir código que los humanos puedan entender – Truth in Software (bytellect.com)
- ¿Por qué debería añadir comentarios a mi código? – Truth in Software (bytellect.com)
- 7 pasos para mantener tus emociones bajo control durante la revisión del código – Truth in Software (bytellect.com)
.