Aunque no lo entiendo muy bien, resulta que hay personas a las que les gusta programar. Bueno, está bien, lo respeto. A un programador perteneciente a este extraño conjunto de seres humanos, que gozan de mi admiración, le pediría que hiciese la siguiente reflexión: después de implementar ese software, de escribir cientos (incluso miles) de líneas de código, de haber disfrutado de lo lindo ¿Qué esperas que pase?. Mantenimiento: corrección de errores, nuevas funcionalidades, migración a una infraestructura mas potente,etc., etc. Todas estas tareas ¿Quién las va a acometer? ¿Cuándo? ¿Has pensado por un momento en la deuda técnica que se ha incorporado al desarrollo?
Lo has pasado bien, te gusta, ha quedado genial, pero ¿Te has parado a pensar tan solo un instante para quién lo has hecho?
Voy a escribir este "recordatorio" desde un punto de vista pragmático, a modo de resumen de ideas recopiladas de varios libros ( working effectively with Legacy Code, Clean Code, Refactoring Improving the Design of Existing Code, The art of readable code,...) y de mi propia experiencia.
Se lo voy a dedicar a todas aquellas personas que están aprendiendo a programar, a todos aquellas personas con las que podría colaborar en algún proyecto futuro, a todas aquellas personas con las que actualmente comparto ratos de código, y por último, pero no menos importante, a mi mismo, para que no se me olviden. Escribamos código para los demás.
Pensaba que a estas alturas en la evolución del desarrollo de software no era necesario recordarlo, pero el listado que a continuación propongo es un conjunto de ideas simples a la vez que no tan fáciles de seguir:
La lista queda abierta a incorporaciones, pero creo que siguiendo esta lista de "consejos" o "buenas prácticas" entre todos conseguiremos que el legacy code que generemos sea mejor mantenido y aceptado por nuestros herederos. Además será mas agradable, e incluso divertido incorporar nuevas funcionalidades al software, y nuevos miembros al equipo de desarrollo.
Estoy bastante de acuerdo en que programar es como escribir un libro, mucha gente puede hacerlo, pero no todos los libros quedan igual de bien; por supuesto a un escritor le gusta escribir, también le gusta que se lea lo que escribe, que se entienda y que el lector disfrute con su libro. Mas aún le gustará sacar una segunda edición, con mejoras, ¿no crees?
Parece fácil ¿verdad? Entonces ¿porqué carajo no lo hacemos? Estimados colaboradores pensad en mi cuando llevéis mas de 5 líneas de código, prometo que yo pensaré en vosotros. 😃
Lo has pasado bien, te gusta, ha quedado genial, pero ¿Te has parado a pensar tan solo un instante para quién lo has hecho?
Voy a escribir este "recordatorio" desde un punto de vista pragmático, a modo de resumen de ideas recopiladas de varios libros ( working effectively with Legacy Code, Clean Code, Refactoring Improving the Design of Existing Code, The art of readable code,...) y de mi propia experiencia.
Se lo voy a dedicar a todas aquellas personas que están aprendiendo a programar, a todos aquellas personas con las que podría colaborar en algún proyecto futuro, a todas aquellas personas con las que actualmente comparto ratos de código, y por último, pero no menos importante, a mi mismo, para que no se me olviden. Escribamos código para los demás.
Pensaba que a estas alturas en la evolución del desarrollo de software no era necesario recordarlo, pero el listado que a continuación propongo es un conjunto de ideas simples a la vez que no tan fáciles de seguir:
- Escribe menos código. El código más rápido de leer es el que no está.
- El código debería ser fácil de entender.
- Mantén tu base de código lo más pequeña y liviana posible: elimina los duplicados, elimina el código/característica que no se usa, reutiliza las bibliotecas, ...
- El código debería escribirse para minimizar el tiempo que le llevaría a otra persona entenderlo.
- Empaqueta la información en los nombres (Naming).
- Es mejor ser claro y preciso que bonito.
- Prefiere nombres concretos sobre nombres abstractos.
- Adjunta información adicional a un nombre cuando sea necesario.
- Cuanto mas largo es un nombre, mas difícil es de de leer y de recordar.
- Los nombres cortos están bien para alcances cortos.
- Cuidado con los acrónimos y abreviaturas.
- Pregúntate, "¿Qué otros significados podría interpretar otra persona de este nombre?"
- Palabras como "is", "has", "can", hacen los tipos booleanos mas claros.
- La estética importa. Si entra por los ojos es mas agradable de leer.
- Divide el código en "párrafos".
- El estilo consistente es más importante que el estilo "correcto" (piensa en el equipo).
- El propósito de comentar es ayudar al lector a saber tanto como el que lo escribió.
- No comentes los hechos que pueden derivarse rápidamente del código.
- Si un nombre necesita un comentario, cambia el nombre.
- Comenta las imperfecciones: TODO, FIXME, HACK, XXX.
- Haz los condicionales y bucles para controlar el flujo lo más "natural" posible.
- Minimiza el anidamiento (vigila la complejidad ciclomática).
- Evita anidar dentro de un bucle.
- En condicionales prefiere el caso positivo primero.
- Divide tus expresiones gigantes en piezas más digeribles.
- Haz que las variables sean visibles al menor número de líneas de código posible (alcance).
- SRP: El código debe organizarse para que solo haga una pequeña tarea a la vez, Reorganiza tu código. Extrae métodos, clases, ...
- Simplifica la interfaz. (entiéndase métodos accesibles desde otros sitios).
- Describe en texto plano qué es lo que estás intentando hacer.
- Lee tu códidgo y refactorízalo hasta que verifiques que se corresponde con lo escrito en el punto anterior.
- Test: fáciles de leer y mantener, simples y límpios, por favor.
- Haz los mensajes de error legibles.
- Cuidado con la "Patronitis". El uso de patrones es genial, pero algunas veces es mas simple no usarlos.
- Cuidado con la "Featuritis". Implementa lo justo y necesario que cubra la necesidad. Lo demás serán mejoras "futuribles".
- Vigila el scroll (horizontal y vertical).
- NO uses el "Patrón enterrador". Piensa en los vivos.
La lista queda abierta a incorporaciones, pero creo que siguiendo esta lista de "consejos" o "buenas prácticas" entre todos conseguiremos que el legacy code que generemos sea mejor mantenido y aceptado por nuestros herederos. Además será mas agradable, e incluso divertido incorporar nuevas funcionalidades al software, y nuevos miembros al equipo de desarrollo.
Estoy bastante de acuerdo en que programar es como escribir un libro, mucha gente puede hacerlo, pero no todos los libros quedan igual de bien; por supuesto a un escritor le gusta escribir, también le gusta que se lea lo que escribe, que se entienda y que el lector disfrute con su libro. Mas aún le gustará sacar una segunda edición, con mejoras, ¿no crees?
Parece fácil ¿verdad? Entonces ¿porqué carajo no lo hacemos? Estimados colaboradores pensad en mi cuando llevéis mas de 5 líneas de código, prometo que yo pensaré en vosotros. 😃
Comentarios