Siempre me gust\u00f3 participar de peque\u00f1os debates que se arman en el ambiente de sistemas. Uno de los que vuelven recurrentemente vuelve es si \u00abX lenguaje es mejor que Y\u00bb. Existen muchas bromas y memes acerca de los lenguajes de programaci\u00f3n, y la verdad, es que como dice el refr\u00e1n, en gustos no hay nada escrito. Para pensarlo juntos, les propongo que hagamos un ejercicio. Vamos a compilar y ejecutar mentalmente el siguiente c\u00f3digo:<\/p>\n\n\n\n
String lenguajeElegido = \"Java\";\nboolean codigoBueno = heVistoCodigoBuenoEn(lenguajeElegido);\nboolean codigoMalo = heVistoCodigoMaloEn(lenguajeElegido);\nboolean resultado = codigoBueno and codigoMalo;\nprintln(resultado);<\/pre>\n\n\n\nVayan cambiando el valor de lenguajeElegido. C\u00f3mo les di\u00f3 el resultado? A mi me di\u00f3 siempre true, sin importar que lenguaje consider\u00e9. <\/p>\n\n\n\n
Entonces? Qu\u00e9 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\u00ed. Hay lenguajes que nos gustan m\u00e1s, o que nos gustan menos. Hay lenguajes que se adaptan m\u00e1s a lo que necesitamos hacer, y lenguajes un poco m\u00e1s r\u00edgidos. Hay lenguajes cuya sintaxis nos gusta m\u00e1s, y hay otros que nos gustan menos. Pero hasta ah\u00ed llega el tema del lenguaje. Podemos escribir buen c\u00f3digo independientemente del lenguaje que elijamos (si, hasta en ese lenguaje que mir\u00e1s de costado)<\/p>\n\n\n\n
Est\u00e1s por cambiar de lenguaje porque tu c\u00f3digo est\u00e1 ilegible?<\/h3>\n\n\n\n
Par\u00e1! Te tengo una noticia. Probablemente el lenguaje no sea el problema. Si tenemos c\u00f3digo ilegible, cambiar de lenguaje no nos va a salvar. El c\u00f3digo 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\u00f3digo mantenible, probablemente escriba c\u00f3digo mantenible independientemente del lenguaje en que lo haga. Y lo mismo al rev\u00e9s: un equipo que escribe c\u00f3digo de mala calidad, probablemente lo haga independientemente del lenguaje. Todo c\u00f3digo es, entre otras cosas, hijo de un determinado contexto, y normalmente el c\u00f3digo ilegible es consecuencia de otros factores que no necesariamente son las herramientas. Si realmente nos interesa tener c\u00f3digo legible, tenemos que enfocarnos en otras cuestiones.<\/p>\n\n\n\n
C\u00f3mo hacemos para que nuestro c\u00f3digo empiece a ser m\u00e1s mantenible? <\/h3>\n\n\n\n
Bueno, lamentablemente la f\u00f3rmula m\u00e1gica y secreta no existe (o al menos no la conozco), sino que son distintas opiniones, que algunas pueden servirnos m\u00e1s, y otras menos. Algunas cosas que nos pueden ayudar: <\/p>\n\n\n\n
Escribir menos test unitarios y m\u00e1s tests que validen el comportamiento de nuestra aplicaci\u00f3n (de componentes e integraci\u00f3n) lo que nos va a permitir hacer refactors m\u00e1s frecuentes con la confianza de no romper nada. Los tests unitarios resultan poco flexibles para los refactors. <\/p>\n\n\n\n
Hacer revisiones de c\u00f3digo peri\u00f3dicas, incorporando cambios al c\u00f3digo productivo e implementar pull-requests para que todo el equipo est\u00e9 al tanto de los cambios en la aplicaci\u00f3n <\/p>\n\n\n\n
Usar herramientas de an\u00e1lisis est\u00e1tico de c\u00f3digo, que nos van a se\u00f1alar las cosas \u00abturbias\u00bb que a veces no nos damos cuenta. <\/p>\n\n\n\n
Dise\u00f1ar en equipo. Hacer Pair programming.<\/p>\n\n\n\n
Verificar que todo el c\u00f3digo \u00abhabla el lenguaje del negocio\u00bb. Nuestros m\u00e9todos y clases deber\u00edan expresar lo que hacen en funci\u00f3n del negocio. Si esto no sucede, es se\u00f1al de que quiz\u00e1s estemos escribiendo c\u00f3digo que podr\u00eda ser de una librer\u00eda.<\/p>\n\n\n\n
Como norma general, deber\u00edamos empezar por preocuparnos por escribir c\u00f3digo que ande. Una vez que tenemos c\u00f3digo andando, con tests que verifiquen que hace lo que tiene que hacer, podemos preocuparnos por hacerlo m\u00e1s extensible. Una vez que tenemos c\u00f3digo que anda, y extensible, y s\u00f3lo 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\u00f3digo incomprensible y rebuscado.<\/p>\n","protected":false},"excerpt":{"rendered":"