¿Los codificadores encuentran útil la documentación tediosa? ¿Cómo justificas esta sobrecarga?

Si está haciendo esto a mano, entonces suena un poco loco. Además del tiempo y el esfuerzo mental que roba el desarrollo del formulario, suena como un poco de CYA mezclado con una enorme lista de culpa. Incluso podría inducir efectos de cobra, de modo que las personas minimicen la “huella” del código que pisotean por miedo a ser culpados.

Habiendo dicho eso:

Si esto se puede automatizar (2 posiblemente se puede hacer con las herramientas de diferenciación del sitio, 3 se puede hacer con las herramientas de cobertura de código), y la administración usa esta información de manera responsable, esto podría minimizar el control de calidad, identificar áreas problemáticas del sitio y tener un mínimo Impacto en su productividad. Sin embargo, la gerencia debe estar dispuesta a asumir el éxito inicial en la implementación de 2 y 3.

http://en.wikipedia.org/wiki/Cob …

Un aparte:

Cada desarrollador debe tener cuidado al construir una cerca entre ellos y el control de calidad y simplemente arrojar el código. Debe asumir la responsabilidad de su propio código en todo momento. Existe una fuerte tentación de simplemente registrar las funciones y tacharlas de su lista. Es importante recordar que una nueva característica con errores o efectos secundarios simplemente no se realiza.

A menos que esté trabajando en una caricatura de Dilbert, los gerentes no deciden ralentizar el desarrollo y crear procesos adicionales solo por diversión. Si introdujeron un proceso como este, supongo que fue en respuesta a algún problema que estaba ocurriendo. Parece que el problema era que el código se registraba y se activaba, lo que rompía el sistema de producción de maneras inesperadas. Probablemente alguien estaba despertando a las 2 de la mañana porque el sitio tenía problemas. La pregunta en la sala probablemente fue “¿cómo evitamos que ocurran estos problemas?” y la mejor solución que pudieron encontrar fue este proceso.

Mi atención se dirige a esta línea tuya:

Quiero codificar, incluir una descripción del cambio en mi check-in (siempre codificamos la revisión antes del check-in), y listo.

La cuestión es que registrar el código no significa que haya “terminado”. Ahora es parte del código que maneja su negocio, y debe implementarse, mantenerse, monitorearse, actualizarse a medida que se escribe el nuevo código, etc. Podría ser esa actitud exacta la que hizo que sus gerentes agregaran este proceso que obliga a los desarrolladores a pensar en el impacto de este cambio de código, cómo se ha probado, etc.

Si está interesado en conocer la justificación de esta sobrecarga, le recomendaría que tenga curiosidad sobre los problemas que esta documentación pretende resolver. Pregúntele a sus gerentes, o a los miembros más importantes de su equipo, qué está pasando aquí. Podría darle una visión más amplia de los problemas que ocurren con su software o su organización.