¿El código limpio es un regalo o una maldición? Acto II. Compromiso / Sudo Null Noticias de TI
¿Qué es más importante: el rendimiento o la flexibilidad del código? ¿Vale la pena abandonar la filosofía del código limpio por el bien del rendimiento? Respondemos a estas y muchas otras preguntas junto con el equipo de desarrollo de PVS-Studio.
¿El código limpio es malo para la industria del software hoy en día? Una pregunta que surge de vez en cuando y que llama bastante la atención de la comunidad. Hoy intentaremos dar respuestas concretas a ésta y otras preguntas en este debate interminable.
Para que mi opinión no fuera la única en el artículo, pregunté a otros desarrolladores de PVS-Studio qué piensan sobre el código limpio. Por lo tanto, mis pensamientos estarán salpicados de citas de colegas, así como un poco de estadística.
Como sugiere el título, este artículo es una continuación. primera parteque me he centrado en la discusión entre Robert Martin y Casey Muratori porque es el material más extenso sobre el tema. Si estás interesado, puedes consultarlo. Sin embargo, no es necesario consultar la primera parte para leer este artículo.
¿Bien o mal?
Alejándome de los problemas de rendimiento, hago esta pregunta: ¿qué es código limpio? Creo que si tú y yo estuviéramos sentados en la misma habitación, escucharíamos el número de respuestas correspondiente al número de interlocutores. Lo que quiero decir es que cada uno entiende algo diferente por código limpio: para algunos, la denominación correcta y la descomposición adecuada son suficientes, pero para otros, no ven código limpio sin polimorfismo y un alto nivel de abstracción.
En realidad, es por eso que percibo el código limpio más como una filosofía, y nuestro desarrollador senior de C++ y líder técnico compartió los mismos pensamientos conmigo. Oleg Lysyi:
Veo el código limpio más como una filosofía. Naturalmente, es mejor considerar con precaución cualquier enfoque para resolver problemas.
Creo que podemos intentar responder la pregunta sobre el impacto positivo o negativo del código limpio a través de los propósitos de su existencia. El problema que dio origen a la filosofía del código limpio es la necesidad de escribir código de tal forma que su desarrollo y mantenimiento no se convierta en interminables sesiones de baile con panderetas. Esto ahorra esfuerzo y tiempo a los desarrolladores y les permite trabajar de manera más productiva en sus tareas.
Creo que todo desarrollador en su vida profesional se ha encontrado al menos una vez con un código que quería limpiar. Simplemente abastecerse de productos químicos domésticos y hacer una limpieza general allí para que nadie sufra por ello. Y seguir los principios del código limpio, en teoría, debería reducir el número de situaciones de este tipo.
Por eso creo que el código limpio es bueno. Pensar en cómo escribir código funcional y legible es el deber profesional de todo desarrollador. Y las discusiones sobre cómo el código limpio no es ideal también son buenas e importantes. Gracias a ellos, podemos comprender qué es necesario cambiar en nuestra percepción del código limpio para que el software que escribimos sea aún mejor y de mayor calidad.
Veamos qué opinan nuestros desarrolladores acerca del código limpio:
¡La mayoría adoptó una posición de neutralidad! Además, esta posición está completamente justificada y, además, creo que podré explicar por qué se obtuvieron tales estadísticas.
Redundancia de código limpio
Hablamos de lo genial que es el código limpio, pero hay muchos “peros” que abordaremos de ahora en adelante.
Hay bastantes reglas de código limpio y se refieren a una variedad de cosas: nombres de funciones y variables, comentarios, formato, enfoques de prueba, arquitectura, manejo de errores y mucho más. La pregunta es si vale la pena hacerlo. absolutamente todo reglas en cualquier contexto.
Para responder a esto, ofrezco un ejemplo claro. Al comienzo de su carrera, cada desarrollador escribe un programa que muestra las preciadas palabras “Hola mundo” en la consola. en este repositoriocuya existencia me hablaron mis colegas, presenta una solución bastante interesante a este problema. El hecho es que se trata de Hello World Enterprise Edition, razón por la cual la simple visualización de un mensaje conocido en la pantalla es bombardeada con abstracciones, fábricas, estrategias y otros atributos de programación orientada a objetos.
En realidad, mi pregunta es ¿qué tan apropiado es seguir todas las reglas arquitectónicas complejas de código limpio en alguna aplicación TODO en Python? Estas maniobras arquitectónicas no simplificarán el trabajo en la aplicación y el desarrollo del rastreador TODO llevará bastante tiempo y no está claro por qué.
Lo que quiero señalar es que no todas las tareas requieren seguir todas las reglas del código limpio. Una vez más citaré a nuestro líder técnico del equipo de C++, Oleg Lysy:
Cada proyecto tiene sus propios patrones y reglas. No será posible aplicarlos todos en cada caso concreto. Si algo parece redundante, lo más probable es que no sea necesario aquí y ahora. La tarea del arquitecto es seleccionar aquellos patrones, técnicas y enfoques para escribir código que funcionarán específicamente en su proyecto.
Veamos si nuestros desarrolladores consideran que el código limpio es redundante:
¡Y aquí, la mayoría de los desarrolladores estuvieron de acuerdo en que las reglas de código limpio pueden ser redundantes! Esto no significa que debamos abandonar el código limpio, simplemente significa que debemos ser más inteligentes a la hora de utilizarlo.
Pruebas de escritura
Escribir pruebas es una parte importante del proceso de desarrollo de software, con la ayuda de la cual se puede comprender qué tan correcto y de alta calidad se escribió el código. Pero, ¿cuándo deberías escribir pruebas?
Durante una discusión entre Robert Martin y Casey Muratori, se planteó esta cuestión y el tío Bob dijo que TDD (Test Driven Development) es un formato para escribir pruebas que le aporta el máximo beneficio. Casey dijo que prefiere probar partes específicas del código.
En realidad, yo personalmente tampoco sería tan categórico en este tema. Me parece que ambos enfoques son bastante buenos y merecen atención. En primer lugar, es importante comprender qué problema debe resolverse para poder elegir una estrategia para redactar pruebas.
Por ejemplo, si necesita refactorizar alguna sección problemática del código, entonces me parece que la mejor solución sería cubrir esta sección con pruebas y solo entonces proceder a cambiarla para no interrumpir el funcionamiento del resto del programa.
Pero, por otro lado, no tiene mucho sentido gastar preciosas horas de trabajo escribiendo pruebas que siempre tendrán éxito o que no se ejecutarán en absoluto. No diagnostican problemas, lo que significa que no son tan útiles.
Ahora veamos qué piensan mis colegas sobre si TDD es una estrategia de prueba más útil:
En este caso, la mayoría también prefiere elegir una estrategia de prueba en función del problema a resolver. Hubo un número igual de partidarios de un enfoque u otro.
Otro problema con respecto a las pruebas es su cobertura de código del 100%. Creo que todo el mundo ha escuchado este pensamiento más de una vez, pero aquí tampoco todo es tan sencillo.
Cubrir todo el código con pruebas es todo un desafío, porque para algunas partes del código esto puede no ser posible, por ejemplo, módulos que usan números pseudoaleatorios. Simplemente no podemos predecir el resultado de su implementación.
Además, nadie puede garantizar que el código cubierto por las pruebas esté 100% libre de errores. Es importante comprender que es posible que se necesiten pruebas para automatizar el proceso de control de calidad, pero aún así las escriben desarrolladores como usted y como yo. Por lo tanto, existe la posibilidad de pasar por alto alguna situación que le pueda surgir al usuario.
Al mismo tiempo, no creo que la cobertura completa del código mediante pruebas sea mala. Me parece que el ideal del 100% no tiene un significado concreto. Basta con cubrir el código con pruebas en lugares importantes donde no se pueden permitir errores y problemas para facilitarle la vida a usted y a sus colegas.
Pregunté a mis colegas sobre la necesidad de cubrir completamente el código con pruebas:
Y aquí la mayoría ya cree que es necesario. Curiosamente, no tantas personas adoptan la posición neutral en comparación con la posición de despido de cobertura total.
¿Código limpio o rendimiento?
En realidad, ahora surge la pregunta principal por la cual se escribió todo esto. ¿Qué es más importante: escribir código flexible y mantenible o ahorrar tiempo de ejecución del programa?
De hecho, si recordamos las reglas que Casey Muratori citó como ejemplo cuando dijo que el código limpio mata la productividad, encontraremos todo lo que hoy directa o indirectamente se ha puesto en duda.
¿Siempre vale la pena lograr la máxima abstracción? ¿Las funciones tienen que ser cortas y hacer una sola cosa? Mi respuesta: no, no siempre. Sin embargo, observo que no siempre es necesario exprimir el máximo rendimiento del código.
Algunas situaciones en sí mismas no requieren la máxima optimización. Podemos acelerar el método tanto como queramos y dividirlo en hilos, pero si entre sus pasos realiza una solicitud de red, entonces estaremos limitados por la velocidad de conexión.
Personalmente, trato de adoptar un enfoque en el que no necesariamente tengo que centrar mi atención en una sola cosa. Puede escribir código limpio que funcionará bien. el me dijo lo mismo Konstantin Kulikovotro de nuestros líderes técnicos del equipo de C++:
Depende del proyecto, pero sin contexto, la calidad del código es más importante. Dicen que tu código no huele, pero esta es la primera vez. Es mejor aumentar la productividad en los cuellos de botella. Por ejemplo, coloque un índice en una tabla, en lugar de reescribir el núcleo del motor.
Y nuevamente nos topamos con el hecho de que es necesario evaluar con sensatez la tarea que se está realizando, tomando decisiones sobre los medios que se utilizarán para resolverla. En este tema coincidimos con Konstantin Volojovskilíder del equipo de Java:
Lo único que se puede decir aquí es que hay que tener la cabeza sobre los hombros y tratar las recomendaciones como recomendaciones, y no seguirlas ciegamente.
Lo mismo puede decirse del debate sobre la elección. si o cambiar. No hay mucha diferencia aquí en términos de escribir código limpio y de alta calidad. Puede darle a su código una vida larga y pacífica, independientemente de los enfoques de diseño. El tío Bob también dijo esto. Si la cantidad de operaciones en su código crece más rápido que la cantidad de tipos, entonces ¿por qué complicar intencionalmente su trabajo?
Como dije antes, el código limpio es genial, la productividad es genial, pero no debes olvidarte de los problemas que estás resolviendo y los objetivos que deseas alcanzar. En pocas palabras, no seas fanático de estas cosas.
Sólo por diversión, pregunté a nuestros desarrolladores con qué frecuencia tenían problemas con el código limpio y los principios SÓLIDOS. Al final, sólo Taras Shevchenkonuestro desarrollador me dijo que debido a problemas en las jerarquías de herencia, una vez tuvo una actualización de la interfaz que llegó tarde.
Me parece que el problema de la pérdida de productividad debido al código limpio es realmente exagerado. Incluso si este no es el caso, al diseñar su programa, solo necesita considerar lo que desea obtener.
Veamos si los desarrolladores de PVS-Studio consideran que la limpieza del código es más importante que el rendimiento:
¡Y aquí la mayoría adopta la misma posición que yo! No es necesario priorizar la limpieza o el rendimiento del código sobre cualquier otra cosa. Debe mantener un equilibrio para que el código esté bien escrito y el rendimiento sea suficiente.
Resultados
Es hora de resumir todo lo dicho en el artículo.
El debate sobre qué es más importante (código limpio o rendimiento) es útil para encontrar puntos donde estos conceptos no pueden cruzarse. Sin embargo, no creo que tenga mucho sentido separar claramente uno del otro.
Un código bien escrito debe ser tal que después de leerlo no quieras comprar un nuevo implante óptico. Pero no debes olvidarte del rendimiento del programa. Este compromiso realmente ayudará a obtener un buen resultado de trabajo.
Todas las actividades: desde escribir código hasta probarlo y brindarle soporte, no deberían ser un golpe en la rodilla del flujo de trabajo. “Todo debe ser con moderación”: eso es lo que quería decir con estos dos artículos. Espero que hayamos podido aportar un número suficiente de argumentos en defensa de esta posición.
“Mantenerse firme a menudo significa ser terco. La capacidad de hacer concesiones razonables es prueba de sentido común”.
Jane Austen
Si desea compartir este artículo con una audiencia de habla inglesa, utilice el enlace de traducción: Valerii Filatov. Código limpio: ¿bendición o maldición? Acto II. Compromiso.
