Pues eso me contaron hace unos días en un evento. En mi proyecto no nos paga el cliente si no hay comentarios en el código, mmmm.
No pretendo entrar en el debate de si comentarios sí o comentarios no, de esto ya hablamos largo y tendido en aquel post de poner comentarios en el código… ¿es una buena práctica o es típico en software de mala calidad?, y la conclusión mayoritaria fue un «depende», el código debería estar muy bien escrito como para no necesitar comentarios, pero como no suele estarlo… mejor tenerlos.
Lo que me llamó la atención del «pago por comentarios» o «no te pago si no los hay» es que sólo se mire eso, los comentarios. Dudo que quien paga sólo si hay comentarios se lea todos y cada uno de ellos (al menos, en un software mínimamente grande), lo que, en momentos de presión, y de fechas apretadas, se da a la pillaresca de comentar cosas sin sentido, meter parrafadas o meter código ya escrito como comentarios. Todos los anteriores los he visto y vivido.
Y lo que me llama más la atención es por qué, además de pagar si hay comentarios, casi nadie paga sólo si la complejidad ciclomática está en límites razonables, si el código repetido es mínimo, sino hay dependencias cíclicas entre paquetes, si la cobertura de pruebas unitarias está en lo pactado, etc.
Por no entrar, además, en temas de diseño, en el estado del control de versiones, el control de la compilación (control de librerías, un POM de maven fiable, etc.), etc.
Si lo que buscas obligando a tener comentarios es que el código sea fácil de mantener una vez que aquellos que lo desarrollaron no estén, ten presente que eso puede ayudarte, si los comentarios son fieles y fiables, pero que los que antes te mencioné pueden afectar un por 10 más a lo que te va a costar mantener el código en un futuro.
Lo sé, las otras medidas de calidad, más allá de los comentarios, son más difíciles de entender, poca gente las comprende, pero es que gestionar bien el desarrollo de un sistema software mediano o grande no es fácil, y requiere de mucha ingeniería (si quieres que sea sanamente rentable)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Buenas noches.
He estado leyendo estos dos últimos días un libro que saqué de la biblioteca de la Universidad sobre «Código limpio».
En este libro decían que los comentarios no son útiles, que como mucho su utilidad puede servir para API´s o para alguna línea de código que no es fácil de entender.
Los comentarios como tal que nos exigen en la carrera, fuera de esta, no tiene ninguna utilidad.
Si el código está bien redactado, no es necesario casi comentar.
Saludos
De acuerdo en escribir codigo auto-legible a nivel de clase, pero opino que tambien es importante comentar o hacer diagramas UML de alto nivel para tener una vision global de las interacciones (quien crea esta clase, con quien interacciona..)
Hola,
Yo igualmente comparto lo de hacer diagramas de visión global, y no intentar «fotocopiar» el código en un papel con UML (al menos hasta que alguien invente una manera que de verdad funciones para tenerlos actualizados sin costes innecesarios)
Saludos