Consideraciones sobre reglas
El escritor francés, Jules Renard, en alguna oportunidad dijo «Las personas que quieren seguir reglas me divierten, puesto que en la vida únicamente existe la excepción», algo de esto encontramos en algunos autores de libros de programación (aunque con menos diversión), pues, es normal encontrar en estos textos «las reglas para construir un buen software», esto es, al menos, en primera instancia, un intento de hacer formal el desarrollo de software, pero, por otro lado, una forma de coartar la creatividad a la hora de programar y de penalizar la alternativa.
Los autores que proponen reglas son valientes —y a veces, pedantes (al igual que muchos tuiteros de informática)—. Hay que serlo para creer que ya se tiene una manera de hacer software correcta. Una manera de ser un buen informático. Una manera de ser algo —«¿qué?»—. Esto lo vemos a diario, un ejemplo de ello es uno de los textos populares que hay de programación el cual promete mucha limpieza y buenas prácticas (usted sabe a quién me refiero).
Ahora esta entrada no es una defensa del otro grupo: los empíricos-subjetivistas. Los que creen que no hay reglas y todo debe ser experiencia pura y dura. Los que defienden el ala ingenieril a ultranza que, en su desconocimiento y soberbia, creen que el desarrollo de software es todo relativo y depende de la experiencia: sin experiencia no puedes hablar, es lo que quieren decir —pero pocos se atreven a decirlo abiertamente—.
No; no creo que sea la respuesta en todos los casos. Yo propongo que más que hablar de reglas se hable de consideraciones. Una consideración no es algo cerrado y no transable. Es más amable y deja abierta la puerta a ser discutida y puesta a prueba. Abrir el diario de vida de una persona es algo similar: se puede aprender aunque eso no significa que todo lo que se describa ahí se pueda rescatar o sea repetible a nuestra vida. La experiencia de otros se puede conocer, pero no implica aceptar.
Por supuesto que alguien que se ha movido por diversas empresas de software, sean estas pequeñas o grandes, repleta de personas amables o canallas, con una buena paga o no, tiene cosas para contar: la experiencia laboral no se compra. Empero, esa experiencia se encuentra, más bien, en el trato con las personas en búsqueda del objetivo de llevar adelante un proyecto de software. No tanto con el buen código en sí mismo.
Muchas de las cuestiones que se refieren a las buenas prácticas de desarrollo de software no tienen que ver con otras personas; son, por otro lado, un conocimiento teórico-personal. A los programadores senior no les gusta esto porque suponen que la experiencia con el trato con otros, es, lo más importante, para sacar adelante un proyecto. Yo considero una mezcla de ambas es una vía más transitable en estos días.
El código de calidad no es subjetivo. El buen comportamiento dentro de un equipo no es subjetivo (un canalla lo es siempre). Aunar ambos mundos es complicado, no obstante, si usted cree que crear software es más que llenarse los bolsillos de dinero acaso pueda abrirse a nuevas oportunidades en donde no todo es blanco o negro (perdón, cero o uno).