Sí, entiendo tu frustración con la regla tonta. He leído muchos programas con comentarios inútiles como
x = x + 1; // add 1 to x
Y me digo a mí mismo, ¡Así que eso es lo que significa un signo más! Wow, gracias por decirme, no lo sabía.
Pero dicho eso, el cliente está pagando la factura. Por lo tanto, les das lo que quieren. Si trabajara en un concesionario de automóviles y un cliente me dijera que quería una camioneta, no discutiría con él si realmente necesita una camioneta y le preguntaría qué espera transportar. Le vendería una camioneta.
Bueno, hay ocasiones en que lo que los clientes dicen que quiere y lo que realmente necesita están tan lejos que trato de discutir el asunto con él, tal vez convencerlo de que acepte algo más racional. A veces esto funciona, a veces no funciona. Al final, si no puedo cambiar de opinión, le doy lo que quiere. Si regresa más tarde y dice: "Oh, eso realmente no cumplió con mis requisitos comerciales, entonces podemos cobrarle más por hacer lo que le dijimos que hiciera la primera vez". La cantidad de dinero que usted puede negociar con el cliente depende de su confianza en su experiencia, de cómo su contrato con usted se adapta a la organización y, francamente, de cuán optimistas son.
Sería un caso muy raro en el que, suponiendo que dependiera de mí, perdería un contrato porque pensé que los requisitos no estaban bien concebidos.
Tenga en cuenta que las personas con las que su empresa está negociando pueden o no ser las que inventaron esta regla del 25%. Podría ser una regla impuesta desde arriba hacia arriba.
Veo cinco respuestas posibles:
Uno. Convenza a su jefe o a quien esté negociando con el cliente para discutir sobre esto. Lo más probable es que esto no logre nada, pero puedes intentarlo.
Dos. Se niegan a hacerlo. Es probable que esto lo despida, o si la compañía está de acuerdo con usted, puede perder el contrato. Esto parece improductivo.
Tres. Escriba comentarios inútiles para llenar el espacio, el tipo de comentarios que simplemente repiten lo que está en el código y que cualquier programador capaz de modificar el código podría ver en 2 segundos. He visto muchos comentarios como este. Hace años trabajé para una empresa en la que debíamos colocar bloques de comentarios delante de cada función que enumeraba los parámetros, como:
/*
GetFoo function
Parameters:
name: String, contains name
num: int, the number
add_date: date, the date added
Returns:
foo code: int
*/
int GetFoo(String name, int num, Date add_date)
La objeción de que dichos comentarios son una carga de mantenimiento porque tiene que mantenerlos actualizados no es válida. No hay necesidad de mantenerlos actualizados porque ningún programador serio los verá nunca. Si hay alguna duda al respecto, asegúrese de dejar claro a todos los miembros del equipo que los comentarios inútiles y redundantes deben ignorarse. Si desea saber cuáles son los parámetros de una función o qué hace una línea de código, lea el código, no mire los comentarios inútiles.
Cuatro. Si va a agregar comentarios sin valor redundantes, tal vez valga la pena escribir un programa para generarlos. Algo de una inversión por adelantado, pero podría ahorrar un montón de escribir en el camino.
Cuando empecé en este negocio, una empresa para la que trabajaba usaba un programa que se anunciaba como "¡Escribe tu documentación para ti! ¡Documentación completa para cada programa!" El sistema requería que le asignáramos a todas las variables nombres esencialmente sin significado y luego tuviéramos una tabla con un nombre significativo para cada variable, por lo que básicamente lo que hizo la "documentación automática" fue reemplazar el nombre sin significado que nos obligó a usar con un nombre significativo. Así que, por ejemplo, esto funcionó con COBOL, tendría una línea en su programa que decía
MOVE IA010 TO WS124
y generarían una línea de "documentación" que decía
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
De todos modos, seguramente se podría escribir un programa para generar documentación igualmente sin valor con bastante facilidad. Lee una línea como
a=b+c
y genera el comentario
// add b to c and save result in a
Etc.
Cinco. Haz lo mejor de la regla tonta. Trate de escribir comentarios útiles y significativos. Hey, podría ser un buen ejercicio.
Por cierto, puedo añadir que siempre se puede jugar con la métrica.
Recuerdo una vez que un empleador dijo que iban a comenzar a medir la productividad de los programadores por la cantidad de líneas de código que producíamos por semana. Cuando nos dijeron esto en una reunión, dije: ¡Genial! Puedo aumentar mi puntuación fácilmente. No más escritura
x=x+4;
En su lugar escribiré:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Loops? Olvídalo, copiaré y pegaré el código diez veces. Etc.
Así que aquí, si van a contar líneas de comentarios, haga que cada línea sea corta y continúe con la idea en la siguiente línea. Si hay un cambio en lo que sucede en los comentarios, no actualice el comentario existente. Ponga una fecha en él, luego copie el texto completo y escriba "Actualizado" y una nueva fecha. Si el cliente lo cuestiona, dígales que pensó que era necesario mantener el historial. Etc. etc.