Cada vez que me encuentro con un programador a quien le gusta programar me echo a temblar. La razón es que programar es como escribir, escribir es como hablar y hablar es más fácil que escuchar.
Los pedagogos saben por experiencia que es casi tan fácil enseñar a un niño a escribir que enseñarle a leer. El motivo es que, si bien escribir es intrínsecamente más difícil, el niño está interesado en primer lugar en que le escuchen y le entiendan antes que en escuchar él mismo ningún rollo patatero prefabricado.
Cuando me topo con un programador a quien se le llena la boca sobre la manera correcta de implementar la solución a un desafío me resulta sencillo determinar rápidamente si es (o no) tan bueno como él mismo cree. El pecado capital de los programadores es el orgullo, la ilusión de hacerse cargo, la convicción de que ellos harán (por fin) lo correcto allí donde otros menos capacitados sólo desarrollaron algo mediocre. La realidad suele ser que son optimistas sobre su capacidad de resolver un nudo gordiano porque no conocen su verdadera complejidad.
Escribir código es más divertido que leer código. Esto es porque cuando lo escribes lo que haces es plasmar en el editor los detalles de lo que tienes en la cabeza, le pones palabras a tu imaginación y eso mola; mientras que cuando lees código lo primero que necesitas es adivinar qué tenía en la cabeza la persona que lo escribió y el esfuerzo que requiere empatía no mola.
Lo que diferencia un código que simplemente resuelve un problema de otro código realmente grandioso es que este último (además de resolver el problema) está pensado para que alguien se lo lea.
Programar es explicarle todos los detalles de cómo se resuelve un problema a la persona más incapaz del mundo. Diez atributos que debe tener esta explicación para ser de escritura/lectura y no sólo de escritura son los siguientes:
1º) Debe ser posible intuir de un vistazo cual es la arquitectura general, en qué consiste a alto nivel la solución, cómo se comunican las partes entre ellas.
2º) Para que sea fácil entender la arquitectura mencionada en el punto primero, la implementación debe resolver directamente el problema y no un caso más general del cual el problema es sólo una instancia particular.
3º) No obstante el punto segundo, debe ser fácil refactorizar el código para resolver un caso más general.
3º) El código debe explicar no sólo lo que hace, sino también por qué lo hace de esa manera. Para eso se inventaron los comentarios insertados dentro del código. Escribe la puta documentación. Es ilegal vender gadgets sin un manual de uso e instrucciones de seguridad. Entonces ¿por qué das por acabado software simplemente con una licencia que dice que se entrega «tal cual»?
4º) Si no queda otro remedio que introducir código espagueti hay que documentar cuándo se introdujo, porqué y qué pasará si se elimina.
5º) Si el programa genera una excepción inmanejable automáticamente, debe ser fácil determinar dónde y por qué ha fallado.
6º) Cuando no funcione correctamente debe informar del funcionamiento degradado. No debe fallar silenciosamente.
7º) Si funciona no hay que tocarlo. Cada vez que se añade una línea de código aumenta el número de defectos software y el coste de mantenimiento. Agregar nuevo código para mejorar uno anterior (sin retirarlo de servicio) sólo es más bugs y más coste de mantenimiento. Por otra parte, todo ese horrible código espagueti del programador anterior está ahí por una razón la cual conviene saber antes de re-escribirlo para retirarlo.
8º) Salvo casos excepcionales, las funciones tendrán entre 10 y 100 líneas de extensión. No tan cortas como para no hacer nada significativo ni tan largas como para que no quepan enteras en la pantalla.
9º) La configuración del comportamiento específico para cada cliente se encontrará en un único lugar donde se especifiquen todos los parámetros que condicionan un modo de comportamiento u otro.
10º) No es suficiente con tener un patrón Modelo-Vista-Controlador, además hay que tener una capa de microservicios agrupados en servicios que el controlador pueda llamar.
En conclución: ¿Tu escribes o lees? Si sólo escribes eres un pedante. Si sólo lees careces de creatividad. El trabajo en equipo consiste en mantener una conversación con los otros programadores; es lectura/escritura.
Posts relacionados:
Prioridades al escribir código.
Por qué hay que enseñar a los niños a programar.
Pingback: Código de sólo escritura