Escribe menos código
En incontables ocasiones discutiendo con mis amigos y colegas desarrrolladores, les digo que me encanta saber tan poco sobre desarrollo y conocer tan pocos artilugios. Siempre que he entrado a proyectos dirigidos por estos personajes que se las saben todas, encuentro una miríada de interfaces, capas y artefactos estrambóticos, casi incomprensibles que inyectan el contenido de un par de redes sociales en un único timeline personalizado o cosas aún más simples, de las formas más sobrehumanas posibles.
La complejidad nos asusta, nos paraliza como dice Don Norman. Pero la complejidad no es mala per se. No debemos tratar siquiera de evitarla porque vivimos vidas complejas, trabajamos en ambientes complejos y por tanto necesitamos soluciones complejas. Pero no por eso debemos hacer que sea tan difícil de entender. Por eso, y porque creo que lo dice con inmejorables palabras, les dejo a continuación este artículo de Umer Mansoor.
Originalmente escrito por Umer Mansoor y publicado el 16 de junio del 2016
No hace mucho tiempo, me puse a “limpiar” un proyecto que me pasaron. Me dieron las riendas de la refactorización porque el proyecto tenía muchos errores en producción. Estaba bloqueado en el circulo vicioso de que al arreglar un error, se generaban nuevos errores. Así que me adentré en el código un fin de semana y pronto el problema fue evidente: El proyecto era un gran embrollo. Grande porque había cantidades innecesarias, redundantes y altamente acopladas de código. Por embrollo, no quiero decir que el código pareciera de principiantes o que estuviera lleno de atajos. El problema era todo lo contrario. Había demasiada magia y por donde mirara, había practicas de diseño ingeniosas y ostentosas que no tenían relación alguna con el problema que el proyecto buscaba resolver. Cosas como reflection, programación orientada a aspectos, anotaciones personalizadas, todas se implementaban en el proyecto. El proyecto era un monstruo sobre-diseñado. Para ponerlo en perspectiva, después de terminar la refactorización, el modulo quedó reducido a menos de la mitad de su tamaño original.
Estoy seguro que los desarrolladores que escribieron el proyecto lo hicieron con las mejores intenciones, pero sus ingeniosos trucos se volvieron contra ellos. Gastaron mucho tiempo en mantenimientos periódicos y corrigiendo errores. Los clientes estaban inconformes por la cantidad de errores en el software. Los desarrolladores se sentían tremendamente mal porque alguien siempre se quejaban de algo en el proyecto. Pero ¿a quién se debía culpar de su miseria, por las largas horas que debían trabajar para arreglar los errores sin sentirse satisfechos con su trabajo? A nadie más había que culpar que no fueran los mismos desarrolladores. Uno de mis bloggers favoritos, Jeff Atwood, escribió que el mejor código, es no tener ningún código en absoluto.
Es difícil para la mayoría de los desarrolladores aceptar esto, porque aman mucho el código, pero el mejor código es no tener ningún código en absoluto. Cada nueva línea de código que de buen grado traes al mundo, is código que debe ser depurado, código que debe ser leído y entendido, código que debe ser soportado. Cada vez que escribes nuevo código, deberías hacerlo reprochando, bajo presión, porque has agotado todas las demás opciones. El código es tu enemigo porque hay tantos otros programadores escribiendo demasiado código. Si no puedes lograr eliminar el código, lo mejor que puedes hacer es empezar con ser breve
El punto de Jeff es innegable. Como desarrolladores, tenemos la manía de salir con soluciones ingeniosas que pensamos que nos harán lucir profesionales o que nos ayudarán a aprender una nueva herramienta o tecnología. Construimos capas complejas para resolver problemas simples y lo justificamos como “realmente necesarias”. Pero debemos darnos cuenta de que cuanto más código escribimos, cuanta más magia ponemos, tantas más oportunidades y puertas abrimos para que los errores aparezcan. Estos errores volverán tras nosotros o nuestros colegas después, con una carga de tiempo adicional para poderlos solucionar a tiempo. Obviamente no estoy hablando de usar buenas practicas para reducir las líneas de código. Deberíamos mejor preguntarnos si en verdad necesitamos escribir todo ese código para resolver el problema. He visto algunas implementaciones de ORM y gestores de procesos en mi vida que me llevan al siguiente punto:
No reinvente la rueda, porfa
Pero no se detengan ahí. Piensen si ese pomposo framework se necesita en verdad. Un proyecto en el que trabajé usaba Hibernate junto a objetos DAO y DTO complementarios para ejecutar una simple y directa consulta a un repositorio de datos. Otro proyecto tenía un buen manejador de eventos para un filtro que usaba la API de reflection para encontrar e invocar el manejador, basado en el tipo de evento. Era una solución brillante y me tomó un tiempo entender que los métodos no referidos que señalaba el IDE eran invocados usando reflection. Lo mejor de todo era que el sistema solo manejaba un tipo de evento. Cerca de cinco clases de código se podrían haber condensado en un simple bloque IF.
if (event.type == THE_ONE_TYPE_THIS_SYSTEM_CAN_HANDLE) {
process_the_event_and_return_result;
}El mejor código es no tener ningún código en absoluto y el código más rápido es el que nunca llega a ejecutarse. Nuestro objetivo debería ser mantener nuestras soluciones tan simples como sea posible a mantenerse lejos de nuestra tendencia naturales a sobre-diseñar, usar trucos ingeniosos y patrones de diseño hasta que sean absolutamente necesarias para resolver el problema. La complejidad es nuestro peor enemigo. Terminaré esta entrada con un excelente consejo de Jeff:
Si amas escribir código, si real y sinceramente amas escribir código, Lo amarás tanto como para escribirlo lo menos posible.
