Te va a interesar!

6/recent/ticker-posts

Reusabilidad vs simpleza en el código: Existe un balance?

Reusabilidad vs Simpleza en el código!

Hacía tiempo que no escribía por estos pagos, no? Estuve a mil con los clientes, los tutoriales del Patreon y otros proyectos personales con los que estoy trabajando. Estoy enseñando también a un grupo de 50 (!!!!!) personas de acá lo mismo que están viendo ustedes en el Patreon! Solo que en vivo en una oficina.

Entre todo este caos de proyectos, enseñanzas y el fin de año que se está acercando a un ritmo vertiginoso, tuve un par de charlas que me anoté y fueron a parar a una tarjeta de mi Trello personal para escribir acá. Y hoy traigo una especial que pasó hace relativamente poco. Preparen un té, café o mate y vamos con el post de hoy!

KISS vs DRY.

No, no me volví loco. Así se llaman dos de las corrientes filosóficocuánticas de la programación. KISS es para Keep It Simple Stupid y DRY va para Don't Repeat Yourself. A grandes rasgos, lo que dice KISS es que nunca la simpleza tiene que ocupar un segundo lugar frente a la reusabilidad, mientras que DRY dice justamente lo contrario. No escatimes reusabilidad, aun si hace falta hacer las cosas un poco más complejas. 

Cuando uno está programando, es generalmente una buena práctica hacer que las funciones sean reutilizables, fomentando el concepto de Don't Repeat Yourself. Esto es por un tema de mantenimiento y para evitar tener que reescribir algo que, a todas luces, vamos a necesitar usar de nuevo en otros lugares. 

Al mismo tiempo, es fácil meterse en el baile de empezar a hacer todo tan abstracto y "dinámico", que para una simple acción hace falta seguir un rulo de código interminable que hace que la reusabilidad sea más un parto que una bendición.

Dos cosas me pasaron en los últimos meses con este tema e hicieron que se me prenda la llama latina en el equipo, haciendo que ponga los puntos sobre las íes para corregir algunas cosas.

El Mundo a veces no es necesario...

El primer caso fue con el uso de inyección de dependencias, para mantener la instancia del WebDriver y otras cosillas, en un proyecto con una sola clase para las definiciones de Steps y que solamente validaba una acción muy sencilla que no requería más. 

El uso del objeto World para ese caso fue arbitrario, heredado de otra persona que, supongo, había tenido la necesidad de crear ese tipo de proyecto al tener que lidiar con algo más grande. En este caso, no solo era innecesario sino que traía una complejidad innecesaria que hizo preguntarse a varios de los que usaron ese framework "qué está pasando acá?" Sin mencionar que hubo entuertos para hacerlo más amigable a los que no estaban familiarizados con el concepto y muchos dolores de cabeza.

En este caso, DRY>KISS. Se intentó. intencional o accidentalmente, dotar de una reusabilidad no requerida por el proyecto y eso aumentó exponencialmente la complejidad, trayendo una retahíla de Pull Requests del averno que me dieron ganas de tirarme de palomita al frío mar del Pacífico. 

Envolviendo a Rest Assured para que sea más difícil de entender.

Esta segunda situación es un poco más compleja. Resulta que había que hacer un trabajo muy grande, con un framework que usa Rest Assured. El framework es sencillo de usar y super versátil, de hecho es el que hicimos en los tutoriales del Patreon. Entró una persona nueva, con un mindset más de desarrollador que de Tester y empezó con los "y qué tal si agrego ésto..." 


De repente, los pasos que eran hacer requests con lo que Rest Assured te da, se habían convertido en una ensalada de otras 4 clases, una para cada tipo de Request usada en el proyecto, metidas bajo capas y capas de complejidad innecesaria. Adivinen quién heredó el cataclismo para arreglarlo? Si...

Lo que se había intentado hacer, y lo entiendo y hasta cierto punto lo veo bien, es lograr que los Features de Cucumber se comportasen similar a lo que sería el Framework Karate para trabajar con APIs. Hacer todo dinámico y, desde Gherkin mismo, decir qué cosas queríamos meter en el body del request y demás, sin tocar código detrás de escenas. 

El problema fue cuando se entusiasmaron tanto con ir agregando cosas, que después hubo que agregar cosas para arreglar las cosas generadas por esas cosas y todo terminó en un ovillo de lana enredado que fue difícil encarrilar. 

Conclusión. 

Como le dije a la persona que terminó en ese lio: Si llegas a un punto en el que ves que tenés que empezar a arreglar tu propio código demasiado seguido para hacer lo que querés hacer, y eso encima te frena en entregar el trabajo que tenés que entregar...ahí creo que tenés un buen indicativo de que no deberías seguir por ese camino. 

Mantener las cosas ordenadas y simples debería ser una prioridad porque, quieran o no, a veces uno puede pecar de desarrollador y terminar por un camino de complejidad innecesaria que no solo no resuelve ningún problema real, sino que termina añadiendo futuros problemas, deuda técnica y desconfianza general hacia el código. 

Ustedes qué opinan? Me interesa saber la opinión y si son desarrolladores o testers!



Publicar un comentario

0 Comentarios