La culpa no es del chancho

Mirá lo que es este código. Es un chiquero!!! Esto en [lenguaje favorito] no pasa!!!

Siempre me gustó participar de pequeños debates que se arman en el ambiente de sistemas. Uno de los que vuelven recurrentemente vuelve es si “X lenguaje es mejor que Y”. Existen muchas bromas y memes acerca de los lenguajes de programación, y la verdad, es que como dice el refrán, en gustos no hay nada escrito. Para pensarlo juntos, les propongo que hagamos un ejercicio. Vamos a compilar y ejecutar mentalmente el siguiente código:

Vayan cambiando el valor de lenguajeElegido. Cómo les dió el resultado? A mi me dió siempre true, sin importar que lenguaje consideré.

Entonces? Qué quiere decir? Que no hay lenguajes mejores que otros? Son todos iguales? Y si son todos iguales, por que no seguimos codeando en Assembler y nos dejamos de joder? Bueno, no es tan así. Hay lenguajes que nos gustan más, o que nos gustan menos. Hay lenguajes que se adaptan más a lo que necesitamos hacer, y lenguajes un poco más rígidos. Hay lenguajes cuya sintaxis nos gusta más, y hay otros que nos gustan menos. Pero hasta ahí llega el tema del lenguaje. Podemos escribir buen código independientemente del lenguaje que elijamos (si, hasta en ese lenguaje que mirás de costado)

Estás por cambiar de lenguaje porque tu código está ilegible?

Pará! Te tengo una noticia. Probablemente el lenguaje no sea el problema. Si tenemos código ilegible, cambiar de lenguaje no nos va a salvar. El código no se escribe solo. Lo escribimos los programadores. Somos nosotros los que hacemos que algo sea legible o un asco. Un equipo que produce código mantenible, probablemente escriba código mantenible independientemente del lenguaje en que lo haga. Y lo mismo al revés: un equipo que escribe código de mala calidad, probablemente lo haga independientemente del lenguaje. Todo código es, entre otras cosas, hijo de un determinado contexto, y normalmente el código ilegible es consecuencia de otros factores que no necesariamente son las herramientas. Si realmente nos interesa tener código legible, tenemos que enfocarnos en otras cuestiones.

Cómo hacemos para que nuestro código empiece a ser más mantenible?

Bueno, lamentablemente la fórmula mágica y secreta no existe (o al menos no la conozco), sino que son distintas opiniones, que algunas pueden servirnos más, y otras menos. Algunas cosas que nos pueden ayudar: 

Escribir menos test unitarios y más tests que validen el comportamiento de nuestra aplicación (de componentes e integración) lo que nos va a permitir hacer refactors más frecuentes con la confianza de no romper nada. Los tests unitarios resultan poco flexibles para los refactors. 

Hacer revisiones de código periódicas, incorporando cambios al código productivo e implementar pull-requests para que todo el equipo esté al tanto de los cambios en la aplicación 

Usar herramientas de análisis estático de código, que nos van a señalar las cosas “turbias” que a veces no nos damos cuenta. 

Diseñar en equipo. Hacer Pair programming.

Verificar que todo el código “habla el lenguaje del negocio”. Nuestros métodos y clases deberían expresar lo que hacen en función del negocio. Si esto no sucede, es señal de que quizás estemos escribiendo código que podría ser de una librería.

Como norma general, deberíamos empezar por preocuparnos por escribir código que ande. Una vez que tenemos código andando, con tests que verifiquen que hace lo que tiene que hacer, podemos preocuparnos por hacerlo más extensible. Una vez que tenemos código que anda, y extensible, y sólo en caso de que sea necesario, preocuparnos por que sea performante. En ese orden. Invertir el orden de esos factores normalmente redunda en tener código incomprensible y rebuscado.