A menudo, en el proceso de implementación de proyectos, los equipos se enfrentan a la pregunta: ¿qué se debe prestar más atención: el lanzamiento de nuevas características o la mejora de la calidad del código? Por lo general, los gerentes optan por características. A menudo, los desarrolladores no están contentos con este estado de cosas, creyendo que no tienen suficiente tiempo para trabajar en la arquitectura y la calidad del código.
La
ley de Betterridge dice: "Cualquier encabezado que termine con un signo de interrogación puede responderse con la palabra no". Quienes me conocen personalmente saben que no comparto este pensamiento. Pero en este artículo quiero ir más allá y demostrar que plantear la pregunta del título de este artículo simplemente no tiene sentido. Tal formulación de la pregunta sugiere que existe una compensación entre costo y calidad. Y debes mantener constantemente el equilibrio. En este artículo, demostraré que este compromiso no es aplicable al mundo del desarrollo de sistemas informáticos y, de hecho, crear software de alta calidad es, en última instancia, más barato.
A pesar de que el público objetivo principal del artículo son los desarrolladores, no requiere conocimientos especiales para comprenderlo. Me gustaría que este artículo beneficie a todos los que de alguna manera están conectados con el proceso de desarrollo, y especialmente a los gerentes que forman el vector de desarrollo de productos.
Estamos acostumbrados a elegir entre precio y calidad.
Como escribí anteriormente, al desarrollar software, constantemente tienes que elegir entre la calidad del producto y los costos de su desarrollo. Cuando compra un nuevo teléfono inteligente, tiene una opción. Pague más dinero y obtenga un procesador más rápido, más memoria y una pantalla mejorada, o pague menos, pero sacrifique algunas características. Hay excepciones a esta regla: a veces un producto de mayor calidad es más barato. Y a veces las personas ni siquiera pueden comparar objetivamente dos productos y elegir uno mejor. Por ejemplo, no notan la diferencia entre las pantallas que se realizan con tecnologías completamente diferentes. Sin embargo, la afirmación "La alta calidad cuesta más" suele ser cierta.
La calidad del software es mucho.
Hablando sobre la calidad del software, debe comenzar definiendo criterios de calidad. ¿Qué es el software de calidad? A partir de este momento, las cosas se complican un poco, porque cualquier sistema informático tiene muchos criterios para evaluar su calidad. Puede evaluar UI y UX: ¿qué tan rápido y simple puede un usuario resolver su problema? La fiabilidad puede evaluarse: ¿hay algún error en el programa que conduzca a un comportamiento incorrecto e inestable? Otro criterio es la arquitectura: ¿qué tan estructurado está el código fuente del programa, qué tan simple y rápido puede el programador encontrar el fragmento de código que necesita en este momento?
La lista anterior de criterios de calidad, por supuesto, no está completa. Pero estos criterios son suficientes para mostrar una cosa importante. Algunos criterios por los cuales generalmente se evalúa la calidad de un programa ni siquiera son visibles para los usuarios finales. Los clientes pueden dar retroalimentación y decir qué tan bien el software resuelve sus problemas comerciales. Los usuarios pueden quejarse de la interfaz inconveniente. O se quejarán de errores, especialmente si conducen a la pérdida de datos o a la falta de disponibilidad prolongada del sistema. Pero los usuarios no pueden apreciar la arquitectura y la calidad del código.
Por lo tanto, divido los criterios de calidad en dos categorías:
externos (por ejemplo, UI / UX o la presencia de errores) e
internos (arquitectura). Su diferencia más importante es que los usuarios pueden evaluar la calidad externa, pero no pueden entender cuán buena (o mala) es la arquitectura interna del sistema.
A primera vista, la calidad interna no es importante para los usuarios (sino solo al principio)
Si los usuarios no pueden evaluar la calidad interna del software, ¿es importante este criterio? Imaginemos una situación hipotética en la que dos equipos de desarrollo, independientemente uno del otro, decidieron crear una aplicación para rastrear y predecir retrasos en los vuelos. Dirijo un equipo, y Rebecca lidera el segundo. El conjunto de funciones básicas para las aplicaciones es aproximadamente el mismo, la interfaz para ambas aplicaciones también resultó ser bastante conveniente y pensada, no hay errores críticos en las aplicaciones. La única diferencia es que el código fuente de la aplicación de Rebecca está claramente estructurado y organizado, y el código creado por mi equipo es un conjunto desordenado de clases y métodos con nombres oscuros y una lógica aún más oscura de cómo se interconecta este código. Hay otra diferencia: vendo mi solicitud por $ 6, y Rebecca vende casi la misma aplicación por $ 10.
Dado que el código fuente de las aplicaciones es inaccesible para los usuarios, y la calidad del código no afecta la experiencia del usuario, ¿por qué los usuarios deben pagar $ 4 adicionales? En otras palabras, ¿por qué pagar de más por la calidad interna, que no es importante para los usuarios?
Si desarrolla esta idea aún más, puede llegar a la conclusión de que invertir en calidad externa es más rentable que en interna. Al elegir entre dos aplicaciones, el usuario puede elegir la que sea más costosa si tiene una interfaz mejor y más conveniente. Pero los usuarios no ven la estructura interna de las aplicaciones, sin mencionar el hecho de que el usuario puede comparar la arquitectura de las dos aplicaciones. Entonces, ¿por qué pagar más por algo que no trae beneficios prácticos? ¿Y por qué los desarrolladores deberían dedicar tiempo y recursos a mejorar la calidad interna de sus programas?
Los programas con alta calidad interna son más fáciles de expandir
¿Por qué es tan importante que los programadores tengan un código de calidad? Los programadores pasan la mayor parte de su tiempo leyéndolo y editándolo. Incluso cuando se desarrolla un nuevo sistema, el trabajo casi siempre se lleva a cabo en el contexto de un código ya escrito. Cuando un programador agrega una nueva característica, primero necesita descubrir cómo esta característica se adapta a la arquitectura de la aplicación existente. Luego, a menudo, debe realizar cambios en la arquitectura para poder implementar una nueva característica. A menudo necesita usar estructuras de datos que ya están en el sistema. Por lo tanto, debe comprender que estas estructuras de datos significan qué tipo de relaciones existen entre ellas y qué nuevas estructuras de datos deben agregarse para implementar características.
El código de alta calidad permite a los programadores navegarlo rápidamente. Llegar a una situación en la que el código se vuelve difícil de entender es realmente muy simple. Las condiciones lógicas pueden estar entrelazadas; las relaciones entre las estructuras de datos pueden ser complejas e implícitas. Los nombres que Tony dio a las variables y funciones hace 6 meses pueden haber sido claros para él, pero también incomprensibles para el nuevo desarrollador, así como los motivos que llevaron a Tony a abandonar la empresa. Los desarrolladores generalmente llaman a esto
"deuda técnica" (
deuda técnica ), o en otras palabras, la diferencia entre el estado actual del código y el estado ideal en el que puede estar.
Una de las principales ventajas proporcionadas por la alta calidad del código es que el programador puede comprender rápidamente cómo funciona el sistema y realizar los cambios necesarios. Cuando la aplicación se divide en módulos, el programador no necesita estudiar las 500,000 líneas de código fuente y puede encontrar rápidamente los cientos de líneas que necesita en este momento. Cuando los programadores dan nombres significativos a las variables, funciones y clases, puede comprender fácilmente lo que hace cada pieza de código individual sin tener que profundizar en el contexto. Si las estructuras de datos en el programa coinciden con la terminología del dominio de dominio de la empresa, entonces es fácil para el programador correlacionar la solicitud de nueva funcionalidad con el funcionamiento del sistema. La deuda técnica también aumenta el tiempo que lleva trabajar con el código. La probabilidad de cometer un error también aumenta. En caso de errores debidos a la mala calidad del código, se requerirá tiempo adicional para localizar el problema y solucionarlo. Y si el error no se nota de inmediato, esto provocará problemas en el código de producción y el hecho de que tendrá que dedicar aún más tiempo a solucionar estos problemas en el futuro.
Cada cambio en el código afecta el futuro del producto. A menudo hay una situación en la que hay una manera simple y rápida de implementar una nueva característica, pero a costa de romper la arquitectura actual (es decir, debido a un aumento en la deuda técnica). Si un programador elige esta ruta, lanza su función más rápido, pero ralentiza el trabajo de otros desarrolladores que tendrán que admitir este código más adelante. Si todos en el equipo hacen esto, incluso una aplicación bien diseñada con un buen código se convertirá rápidamente en deudas técnicas, e incluso unos pocos cambios tomarán varias semanas.
Los usuarios desean obtener nuevas funciones lo más rápido posible.
Nos estamos acercando a un punto importante, a saber: para responder a la pregunta, ¿por qué la calidad interna del software sigue siendo importante para los usuarios? La alta calidad interna promueve el lanzamiento más rápido de nuevas funciones, porque son más fáciles, más rápidas y más baratas de hacer. Nuestras aplicaciones con Rebecca ahora se ven casi iguales, pero después de unos meses, el código de alta calidad de Rebecca le permitirá lanzar una nueva función cada semana, y estaré atrapado en el lugar, tratando de hacer frente a la deuda técnica e intentando lanzar al menos una nueva función. No podré competir con Rebecca en velocidad de desarrollo, y su aplicación superará rápidamente a la mía en funcionalidad. Finalmente, los usuarios eliminarán mi aplicación y usarán la aplicación Rebecca, a pesar de que cuesta más.
Visualización de la influencia de la calidad interna.
La principal ventaja de la alta calidad interna del programa es la reducción en el costo de los cambios futuros. Pero escribir código de alta calidad requiere más esfuerzo, y esto aumenta los recursos necesarios a corto plazo.
El siguiente gráfico muestra esquemáticamente cómo puede imaginar la relación de funcionalidad y el tiempo que lleva desarrollarla. Por lo general, una curva se ve así:
Así es como se ve el proceso de desarrollo cuando el código no es de muy alta calidad. Al principio, el desarrollo es lo suficientemente rápido, pero luego se requiere más y más tiempo para expandir aún más la funcionalidad. En un momento determinado, para realizar incluso un pequeño cambio, el programador primero debe aprender un montón de código complejo y confuso. Después de realizar el cambio, se descubre que algo se ha roto, y esto lleva a un tiempo adicional dedicado a probar y corregir errores.
La alta calidad interna contribuye a la eficiencia del desarrollo en etapas posteriores. Algunos equipos incluso logran obtener el efecto contrario, cuando cada nueva característica se lanza más rápido que la anterior debido al hecho de que es posible reutilizar el código ya escrito. Pero esto sucede con poca frecuencia, porque requiere un equipo altamente profesional con una buena organización del trabajo. Pero a veces esto todavía sucede.
Sin embargo, hay un truco. En las etapas iniciales de desarrollo, ignorar la calidad del código es más efectivo que seguir altos estándares. ¿Pero cuándo termina este período?
Para responder a esta pregunta, primero debe aclarar que las imágenes representan
pseudografía . No hay una única forma verdadera de evaluar el desempeño del equipo. No es fácil entender cómo el código incorrecto afecta la calidad final del producto (y si existe esta correlación, qué tan pronunciada es). Por cierto, este problema es relevante no solo para la industria de TI. ¿Cómo, por ejemplo, evaluar la calidad del trabajo de un abogado o médico?
Pero volviendo a la pregunta, ¿en qué punto vale la pena comenzar a pensar en la calidad del código? Los desarrolladores experimentados creen que la mala calidad del código comienza a disminuir en unas pocas semanas después del inicio del proyecto. En una etapa temprana del proyecto, se puede ignorar la belleza de la arquitectura y el código.
Además, según mi propia experiencia, puedo decir que incluso los proyectos pequeños obtienen una ventaja competitiva seria si utilizan prácticas de desarrollo modernas y efectivas en su trabajo y piensan en la calidad del código.
Incluso los mejores equipos a veces escriben códigos incorrectos
Los nuevos en el proceso de desarrollo creen que un código incorrecto indica que el equipo no está funcionando bien. Pero, como muestra la práctica, incluso los equipos más experimentados a veces cometen errores y escriben códigos incorrectos.
Para demostrar esto claramente, quiero contarles sobre una conversación con uno de nuestros mejores líderes de equipo. En ese momento, acababa de terminar de trabajar en un proyecto que todos consideraban muy exitoso. El cliente estaba encantado con el nuevo sistema, tanto por las nuevas características como por los recursos que se gastaron en su desarrollo. El equipo también estaba satisfecho con el proyecto completado. El líder técnico del equipo también estaba muy satisfecho con el resultado, pero admitió que, de hecho, la arquitectura del sistema no tuvo tanto éxito. Le pregunté: "¿Pero cómo es que eres uno de nuestros mejores arquitectos?" Él respondió como cualquier arquitecto experimentado hubiera respondido: "Tomamos buenas decisiones, pero solo ahora entendemos cómo hacerlo bien".
Muchas personas comparan la creación de sistemas complejos con el diseño de rascacielos. Aparentemente, esta es la razón por la cual los desarrolladores experimentados se llaman "arquitectos". Pero en el proceso de creación de software, siempre existe cierta incertidumbre, poco característica de otras áreas de actividad, en la cual las incertidumbres son mucho menores. Los clientes típicos tienen una comprensión deficiente de lo que quieren del programa y comienzan a entender esto solo en el proceso de trabajar en él. Muy a menudo, en ese momento cuando se muestran las primeras versiones del programa. Los elementos a partir de los cuales se crean los programas (lenguajes de programación, bibliotecas, plataformas) cambian cada pocos años. Dibujando una analogía con la construcción de un rascacielos, ¿te imaginas una situación en la que el cliente le pide al arquitecto que agregue otros diez pisos y cambie el diseño de los más bajos, a pesar de que la mitad del edificio ya está construido? La situación se vuelve aún más complicada cuando resulta que las tecnologías utilizadas para la producción de concreto, sus propiedades físicas y características se actualizan cada 2 años.
Ante los constantes nuevos desafíos, el crecimiento de su número y complejidad, los equipos constantemente tienen que encontrar algo nuevo. Cada vez más, es necesario resolver problemas que nadie ha resuelto antes y, por lo tanto, no existe una solución conocida y comprobada para ellos. Por lo general, una clara comprensión del problema se produce solo en el momento de su solución, por lo que a menudo escucho la opinión de que entender cómo debería ser la arquitectura de un sistema complejo se produce al menos un año después del inicio del trabajo. E incluso el equipo de desarrollo más profesional del mundo no podrá hacer que el sistema sea perfecto.
Un equipo profesional y organizado se diferencia de uno menos organizado en que en el proceso de trabajar en el sistema crea menos deuda técnica y también elimina la existente. Esto ayuda al proyecto a desarrollarse rápidamente y lanzar nuevas características lo más rápido posible. Dicho equipo invierte en la creación de pruebas automatizadas, lo que ayuda a identificar los problemas más rápido y pasa menos tiempo buscando y reparando errores. Los miembros de dicho equipo trabajan constantemente para mantener un código de alta calidad y deshacerse rápidamente del código incorrecto hasta que comience a interferir con el avance. Los sistemas de CI también contribuyen a esto, especialmente en una situación en la que muchas personas trabajan simultáneamente en diferentes tareas. Como metáfora, puede traer a la cocina después de cocinar. Es imposible cocinar algo sin ensuciar la mesa, los platos y otros utensilios de cocina. Si no los limpia de inmediato, la suciedad se secará y será mucho más difícil lavarla. Y la próxima vez que quieras cocinar algo, será mucho más difícil hacerlo porque primero tienes que lavar la montaña de platos.
Investigación y evaluación de DevOps (DORA)
La compensación entre costo y calidad no es la única en el mundo del desarrollo de software que parece simple a primera vista, pero en la práctica todo resulta ser algo más complicado. También hay una discusión generalizada sobre lo que es mejor elegir: tasas de desarrollo y lanzamiento rápidas, o tasas más lentas y pruebas rigurosas. Se cree que el uso del segundo enfoque permite lograr una mayor estabilidad de los sistemas de producción. Sin embargo, el estudio
DORA demostró que esto no es así.
Después de recopilar estadísticas durante varios años, los investigadores identificaron qué prácticas contribuyen a un mayor rendimiento del equipo. Resultó que los equipos más efectivos actualizan el servidor de producción muchas veces al día, y el lanzamiento del código desde el momento en que está escrito para el lanzamiento no lleva más de una hora. Seguir este enfoque le permite liberar cambios en partes pequeñas, y se reduce la probabilidad de daños graves. Los equipos que realizan lanzamientos con menos frecuencia, según las estadísticas, enfrentan muchos problemas serios. Además, los equipos que están acostumbrados a un ritmo elevado pueden recuperarse más rápido después de un choque. Los estudios también han demostrado que en tales equipos los procesos suelen estar mejor alineados y funcionan de manera más organizada.
El soporte para sistemas con una buena arquitectura es más barato
Los puntos más importantes de lo que hablamos anteriormente:
- La falta de atención a la calidad del código conduce a la acumulación de deuda técnica
- La deuda técnica ralentiza el desarrollo del sistema
- Incluso los equipos profesionales a veces toman malas decisiones. Pero la aplicación de prácticas modernas y el "pago" periódico de la deuda técnica le permite mantenerla bajo control.
- Mantener un alto nivel de calidad de código minimiza la deuda técnica. Esto permite centrarse en las nuevas funciones y lanzarlas con menos esfuerzo, más rápido y más barato.
Desafortunadamente, generalmente es difícil para los desarrolladores explicar esto a la gerencia. A menudo escucho quejas de que el manual no permite mantener un código de alta calidad al limitar el tiempo asignado para trabajar en las tareas. Al responder preguntas de administración, por qué gastar recursos adicionales en la belleza del código, los desarrolladores generalmente responden que esto es un indicador de alta profesionalidad. Pero usar solo este argumento implica que se gastan recursos adicionales para mantener una alta calidad, que podría usarse para otras tareas. Y esto socava el argumento a favor del profesionalismo en sí. La verdad es que debido a la arquitectura de mala calidad y al código deficiente, la vida se vuelve más difícil para todos: es más difícil para los desarrolladores trabajar con ella y para los clientes cuesta más. Al analizar la calidad del código con la administración, insto a que se considere únicamente como un indicador económico. Si el programa interno se realiza con alta calidad, será más fácil y económico agregarle nuevas funciones. Esto significa que invertir en escribir código de calidad en última instancia reduce los costos generales de desarrollo.
Esta es la verdadera razón por la cual la pregunta del título del artículo simplemente no tiene sentido. Gastar recursos adicionales en arquitectura y buen código, desde un punto de vista económico, al final, es más rentable. , , , . , . ( ). , .
. :
, , . – . . , . .