Biblioteca de post técnicos |
---|
> Gestión de errores en una aplicación > Virtual Village: multiplayer |
Inspirado y motivado por un atículo que escribió mi compañero Andy, me he decidido a escribir.
Quizás el tema del que voy a hablar no da para mucho, ni resulte atractivo para la mayoría de programadoras y programadores, pero si te dedicas profesionalmente al desarrollo de aplicaciones, normalmente trabajarás con un equipo y para un cliente, y este es el principal motivo por el que la documentación y calidad del código se merecen un artículo.
Sí… documentar código no es programar… pero forma parte de la programación, como el agua de nuestro cuerpo.
-¡Oh, qué profundo!- Lo profundo es el batacazo que se puede llevar el cliente -y por ende, tú- cuando se entere de lo que cuesta mantener su aplicación, provocando a la larga un descontento general y un cambio de proveedor.
Vale, quizás así suene exagerado, pero tengo la suerte de haber participado en muchos proyectos y puedo decir que he aprendido el valor de entender un código a la primera. Claro que un código legible y fácil de entender, no solo consta de una documentación clara, también debe estar bien estructurado y formateado.
Algunos casos
¿Quién no ha tenido que enfrentarse a un código que no es suyo y tirarse de los pelos para entenderlo? ¿Quién no se ha encontrado con un cliente que contrata tus servicios para rehacer un proyecto que se ha convertido en una pesadilla? ¿A quién no le gusta entender lo que lee? ¿Quién no ha picado de nuevo un código que no es suyo porque es mucho más rápido y fiable que mantener el ya existente? ¿Por qué es tan difícil explicar y hacer entender la importancia de un código de calidad?
Algunos de los que han trabajado conmigo, me han preguntado alguna vez por qué dedico tanto tiempo a pensar en el nombre de una variable. El motivo es simple: el nombre adecuado en una variable la convierte en autoexplicativa y ayuda a entender el contexto en el que se encuentra, evitando tener que revisar otras líneas de código para comprender su finalidad. Lo mismo es aplicable para una clase o un método.
No quiero aburriros con más historietas, voy a daros algunos consejos que seguramente vuestr@s compañer@s y el cliente agradecerán algún día.
Consejos
- Antes de picar la primera línea de código, busca información sobre tips de buenas prácticas para el lenguaje de programación que vayas a utilizar.
- Prepara tu IDE con un formateador automático de código. Si puede ser, basado en estándares. En caso de no disponer de esta funcionalidad, trata el código como si fuera tu proyecto de final de carrera.
- Tratar el código con amor.
- Tratar el código con respeto.
- Piensa en los demás.
- Entiende lo que quiere el cliente. Eso te ayudará a crear un código mucho mejor, porque te permitirá plasmar los conceptos del negocio de forma adecuada.
- No hagas las cosas porque te las dicen, hazlas porque las entiendes. Así que no me hagas caso, excepto si entiendes mi mensaje y compartes su finalidad.
- Intenta documentar primero la cabecera de un método antes de implementarlo. Te ayudará a tener claro que quieres conseguir y luego te resultará más fácil implementarlo.
- No documentes un método porque sí, por pura burocracia. Hazlo porque entiendes su utilidad, para que otros o tú mismo lo podáis entender con el mínimo esfuerzo pasado el tiempo.
- Evita la redundancia en la medida de lo posible. Por ejemplo para explicar lo que hace un método no escribas «Método que …». Aligera la lectura y ocupa menos espacio en pantalla. Pero cuidado, a veces la redundancia es útil para clarificar un contexto complejo.
- Utiliza programas o plugins del IDE para revisar la calidad del código. Como SonarLint en el caso de Java. Recuerda, respeto por el código.
- Somos el código, el código nos une. Sin el código estamos vacíos.
- Documentar y escribir un código de calidad forma parte de la tarea de implementación. De lo contrario, la funcionalidad estará incompleta por mucho que el código compile y funcione. No caigas en la tentación y líbrate del mal, amén. En serio, lo que te ahorras, te lo devolverá por triplicado negativamente más adelante. Solo en casos extremos, de proyectos agresivos o urgencias, puedes saltarte esta parte, pero en un futuro no muy lejano algo o alguien se resentirá.
Aprender estos consejos requiere un esfuerzo. Hay que practicarlo y habituarse. Luego todo fluye. Es cómo un mago cuando aprende un hechizo.
Gracias Adri por tu pala de
Gracias Adri por tu pala de arena
Gracias Adri por tu pala de
Gracias Adri por tu pala de arena
Gracias Adri por tu pala de
Gracias Adri por tu pala de arena
Ya lo decía un antiguo
Ya lo decía un antiguo programador griego: «Comento, luego programo»
Gracias Adri
Ya lo decía un antiguo
Ya lo decía un antiguo programador griego: «Comento, luego programo»
Gracias Adri
Ya lo decía un antiguo
Ya lo decía un antiguo programador griego: «Comento, luego programo»
Gracias Adri