Uno de los principales objetivos de una aplicación de software es crecer, no solo en tamaño sino también en complejidad. Esta complejidad varia de muchas formas. Algunas de ellas son el resultado de un código de baja calidad, pero otros son una parte indispensable de la funcionalidad y el valor de la aplicación. Este tipo de complejidad del software tiene valor comercial por algunas razones:
- La complejidad de un problema puede ser resulto por los procesos de software. El software nunca será menos complejo que el problema que realmente resuelve.
- La adaptabilidad a una variedad cada vez mayor de casos de uso agregando complejidad, a través de características personalizadas en función de segmentos específicos de la industria, empresas o usuarios.
- Un buen software esta construido con altos estándares de accesibilidad, observabilidad, resilencia y diseño. Todas estas y cada una de las características antes mencionadas requieren código adicional y, por lo tanto, una mayor complejidad.
La complejidad que agrega valor o aumenta la ventaja competitiva es «buena complejidad”. Esta es una de las razones por la cual desarrollamos software. Por otra parte la complejidad que hace que el código sea difícil de entender, mantener y construir es “mala complejidad”. La mala complejidad es eventual, apareciendo cuando los programadores o gerentes comenten errores durante la implementación.
Una forma útil de definir la calidad del código es la relación entre la buena y la mala complejidad.
En primer lugar una buena calidad de código mantiene bajos los costos de desarrollo y mantenimiento a largo plazo.
En cualquier proyecto que dure mas de unas semanas, la velocidad de desarrollo dependerá parcialmente de la calidad del código. Este es un factor significativo en el costo total de la propiedad; es decir, los resultados finales de la empresa están directamente en riesgo. Ya que una encuesta en el año de 2018 realizada por la empresa Stripe encontró que el costo mundial de lidiar con el mal código era de hasta 85 mil millones de dólares al año. Debido que los efectos de una mala calidad de código persisten hasta que se elimina, a modo que se debe lidiar con el temprano y con frecuencia.
En segundo lugar, la calidad del código es un factor que proporciona satisfacción laboral entre los programadores. Debido a que los programadores tienden a cometer más errores en los proyectos con los que están menos familiarizados.
En tercer lugar, la calidad del código impulsa a crear productos de calidad, Es menos probable que el código de alta calidad tenga errores. La calidad de código también se ha correlacionado con el éxito comercial y la reducción de vulnerabilidades de seguridad. Por otra parte la calidad de código no es el único factor en el rendimiento de un producto en el mercado, y probablemente tampoco sea el factor más importante. Pero incluso las organizaciones más exitosas tendrán dificultades para comercializar un producto que esté lleno de errores o contenga vulnerabilidades.
Cómo las empresas pueden aumentar la calidad del código.
Tener una buena calidad de código requiere inversión. Esta no se puede aumentar sin el compromisos de recursos como dinero, tiempo de desarrollo y a su vez tampoco se puede aumentar mediante el uso de amenazas, castigos u horas extras.
Los siguientes son algunos hábitos y competencias organizacionales que promueven un código de mayor calidad.
Ritmo Sostenible de trabajo
El desarrollo de software es complejo y requiere atención a los detalles de tal forma que la capacidad de un desarrolladores dependiera de su estado mental. Cosas como una vida sana, descanso suficiente, bajos niveles de estrés son ingredientes importantes.
Una de las principales formas de garantizar que los desarrolladores tengan suficiente recursos mentales para realizar su trabajo es evitar las horas extras. La calidad del código de un desarrollador cae al final de cierto tiempo. Y es sabido que cuando los desarrolladores trabajan mientras esta cansados, estresados o enfermos, luego deben de rehacer el trabajo previamente hecho. Por tal motivo nada puede compensar la falta de descanso.
Las empresas que fomentan el agotamiento a través de horas extras contantes no son son abusivas, sino que son contraproducentes. Cualquier ganancia inicial en la productividad se vera rápidamente apagada por la mala calidad. Por otro lado, las empresas que aceleran a sus equipos de desarrollo en una jornada laboral corta, sostenible y flexible, permitiendo tiempo libre y licencia por enfermedad, pueden espera un rendimiento consistente y de alta calidad a largo plazo.
Una causa común de trabajar horas extras en las empresas que de otro modo serían competentes es la presión sobre los plazos. Los plazos comúnmente se basan en motivaciones financieras o preocupaciones de programación en lugar de las realidades del desarrollo de software. Los desarrolladores no pueden acelerar un proyecto pensando mas o escribiendo más rápido. Cuando se acerca la fecha de entrega, generalmente toman el atajo de la reducción de calidad. Este tipo de problema se puede evitar planificando cuidadosamente y diseñando estrategias en torno a los plazos.
La primera parte de esto es la estimación. La estimación del software es una habilidad compleja que requiere capacitación especifica. La mayoría de desarrolladores y gerentes no cuentan con esa capacitación. Y a falta de habilidades de estimación, los equipos corren el riesgo de recurrir a fórmulas demasiado simples y nada reales. En el mejore de los casos aquí es donde el proyecto se hace temprano y los gerentes de proyecto se quedan improvisando formas de llenar el tiempo de desarrollo sobrante. Y por otra parte en el peor de los casos es que el proyecto se entrega tarde o apenas y funcione. Por lo tanto, si una empresa acrece del tiempo o voluntad de desarrollar habilidades de estimación de software, será mejor hacer plazos extensos a fin de no decepcionar a los clientes.
La sentida parte de la gestión de plazos es la priorización. Esta no solo se trata de que cosas se construyen primero; se trata de que cosas se construyen en absoluto. Cada hoja de ruta de desarrollo puede incluir características que están sobrevaloradas (difíciles de construir y no especialmente valiosas para los usuarios) o infravaloradas (fáciles de construir y muy valiosas para el usuarios). Un gerente efectivo centrara los esfuerzos de su equipo en el ultimo extremo del espectro, especialmente a mediada que se acerquen los plazos.
Si los plazos son gestionados de forma adecuada, pueden ser un motivador efectivo hacia los objetivos de entrega de software del equipo, al tiempo que dejan tiempo suficiente para que las cosas se construyan bien. La calidad del software, tanto como cualquier otra cosa, requiere tiempo dedicado.
Refactorización como parte del ciclo de desarrollo de software
La deuda técnica técnica, surge independientemente de lo que podamos hacer para prevenirla. Si bien algunas prácticas de desarrollo pueden reducirlo notablemente, no hay manera de eliminarlo sin el beneficio de la retrospectiva. Mantenerlo al mínimo significa tomarse tiempo regularmente para encontrarlo, discutirlo y arreglarlo.
Muchas empresas que desarrollan software utilizan la “regla del 20%” como guía: el 80% del tiempo de desarrollo se dedica a la creación de características o correcciones de errores y el 20% se gasta en refactorizacion (proceso de restructuración para mejorar la legibilidad y reducir la complejidad sin realizar ningún cambio en su comportamiento externo). Dicho principio funciona mejor cuando se aplica libremente, ya que los equipos no pueden predecir exactamente cuánto tiempo tomara una tarea determinada. Y puede haber ciclos ocasionales en los que la deuda técnica se haya convertido en un obstáculo tal que requiere toda la atención de un equipo, o ciclos en los que hay lanzamientos de características urgentes a los que atender y la deuda técnica tenga que pasar a un segundo plano.
Con el fin de obtener mejores resultados, las tareas técnicas de la deuda deben ser ciudadanos de primera clase del proceso de planificación. Es decir, deben existir junto con características, errores y tareas de prueba en el software de planificación del equipo. La regla del 20% se puede adoptar de manera tan simple como «dos de cada diez tareas se reserva para la refactorización». Esto no requiere necesariamente que las tareas técnicas de deuda se planifiquen y alcancen con el mismo nivel de detalle que las tareas de características.
Liderazgo técnico y revisión
Comúnmente la calidad de código es de segunda naturaleza para muchos desarrolladores. Reconocen el código de baja calidad, entienden sus efectos y saben cómo solucionarlo. Para otros desarrolladores, el concepto es completamente extraño. Si un proyecto está totalmente asignado por este último, no tarda mucho en terminar sumido en problemas técnicos y de desarrollo lentos. Siendo el estudio y la practica las principales diferencias entre estos dos grupos de desarrolladores.
Es por ello que calidad del código y las habilidades de refactorización se pueden aprender en cualquier etapa de la carrera de un desarrollador y son menos complejas que muchos de los otros conceptos que tratan. La calidad del trabajo de un desarrollador puede aumentar radicalmente en el transcurso de unos meses si tiene acceso a los recursos adecuados y está dispuesto a mejorar.
Además, una organización de software puede prosperar incluso cuando sus programadores son desigualmente hábiles. Si se elige a programadores practicados para liderar la arquitectura, el diseño y la planificación de proyectos de software, su comprensión de la calidad del código será parte del ADN del ciclo de desarrollo. Este tipo de liderazgo técnico es esencial para un software de alta calidad.
Las brechas de habilidades también se pueden cerrar con varias formas de revisión:
- Las revisiones de diseño El desarrollador asignado a la tarea escribe un documento que describe su enfoque: los archivos, clases y métodos que planea actualizar; los patrones y técnicas que utilizarán; y cualquier incertidumbre que puedan tener sobre el diseño o la lógica empresarial. Luego, otro desarrollador da retroalimentación sobre ese documento, lo que puede incluir corregir conceptos erróneos y sugerir patrones o métodos útiles que ya existen en la base de código.
- Programación de pares es la práctica de asignar dos desarrolladores para completar una tarea juntos en tiempo real. Un desarrollador controla el teclado y el ratón, mientras que el otro programador da instrucciones. Esto permite una revisión instantánea, la retroalimentación y la transferencia de conocimientos durante el desarrollo.
- Las revisiones de código Un desarrollador pone sus cambios de código a disposición del resto del equipo. Luego, otro programador los lee y da retroalimentación, a menudo sugiriendo cambios que deben hacerse antes de que se envíe el código. Muchos problemas de calidad del código solo pueden ser reconocidos por un humano. Esta es la última oportunidad para atraparlos antes de que se conviertan en parte del producto.
Si los miembros del equipo suelen corroborar el trabajo de los demás y no hay oposición importantes o fallas de comunicación entre ellos, la calidad de su trabajo colectivo aumentará hacia el nivel de los programadores más practicados.
La calidad del código como ventaja competitiva
Una y otra vez se ha demostrado que es un factor en el éxito o fracaso del proyecto, el tiempo de comercialización y la longevidad del producto. Las empresas que priorizan bases de código saludables están priorizando a sus clientes, sus programadores y su propia viabilidad financiera.
También la calidad del código es uno de los grandes regalos que los programadores podemos darnos a nosotros mismos y a nuestros colegas. Si pasamos unos momentos adicionales nombrando una variable, reescribiendo una lógica profundamente anidada o haciendo que una función sea más predecible, esos momentos se devolverán en su totalidad muchas veces a medida que interactuemos con ese código durante la vida del proyecto.
