¿Qué técnicas especiales utiliza al modificar el código existente?Mantenimiento comentando
Por ejemplo: Digamos que modificar una regla de negocio dentro de un método. ¿Marcas la sección modificada con comentarios especiales?
ningún tipo de codificación/comentando las normas se utilizan al modificar el código?
¿Quieres decir algo como:
foo(); // changed by SecretWiz, 20090131
Yo no recomendaría este. Agrupa los archivos de código, y el sistema de control de versiones debería manejar eso por usted. Realiza un seguimiento de quién cambió qué. Use
svn blame
No, esa es una muy mala idea. Su control de origen mantiene un historial de todas las ediciones. Si quieres algo más, haz una entrada en tu herramienta de seguimiento de errores. No hay necesidad de crear un comentario en secciones anteriores de código o de arena que con cosas como: comentarios
// modified by A.B. on 11/23/99 to fix issue #123456
que he visto de este tipo en nuestra base de código y no hacen ningún sentido años abajo de la línea. ¿Quién diablos es A.B., y cuál era el problema # 123456? Si el código aún está aquí, ¿significa esto que alguien planea volver a implementar estos cambios en el futuro?
Estos comentarios no tienen ningún valor y solo sirven para desordenar su código.
Creo que al referirse al problema # no es tan malo. A menudo tenemos una situación en la que la justificación de un cambio de una línea puede ser compleja, y la discusión en el rastreador de problemas es demasiado larga para copiar y pegar al código (ahora * eso * sería desordenarlo). Como el rastreador de problemas, como el control de versiones, no va a ninguna parte, me parece bien agregar la referencia. Incluso después de años, verá la discusión completa que resultó en esa línea específica de código. – Reunanen
Sugeriría crear un método & llamarlo desde el código que se está modificando.
También, nombre el método para sugerir el propósito/intención del método.
p. Ej. GiveRebateIfValidCoupon();
"¿Algún estándar de codificación/comentarios que se usa cuando se modifica el código?"
Sí. Haz nuevas subclases. Deje el código antiguo solo, salvo en el raro caso de que no lo haya probado correctamente y que esté realmente equivocado.
Los cambios en los requisitos implican la adición de subclases y nuevas pruebas para manejar las nuevas reglas comerciales.
Idea interesante, pero no sé si funcionará en todos los casos. A veces, las reglas comerciales cambian PARA SIEMPRE y no es necesario mantener este viejo código. –
Esto suena como una receta para la rigidez –
¿Huele un poco de C++ como tecnología en el fondo aquí? Si insististe en trabajar así en mi proyecto C#/java, te echaría del proyecto. -1 de mi parte – krosenvold
La única vez que añadir comentarios especiales es si la modificación se pretende que sea temporal. En esa situación, lo señalo con una palabra clave estándar (por ejemplo, TEMPFIX) para poder encontrarlo más tarde. Por supuesto, debe recordar regresar y eliminar el código o hacer un cambio permanente, pero en algunos proyectos hemos aplicado que usando una macro nos permitió especificar una fecha de caducidad después de la cual el código deja de compilar.
Aparte de eso, dependemos de control de código fuente.
El código debe cumplir los estándares de codificación lo tiene o tiene su organización.
Así que, no, no debería haber comentarios especiales de que el código haya sido modificado, todos o al menos la mayoría, el código se modificará tarde o temprano.
Si hay un código que heredó que no corresponde a los estándares de comentarios, entonces agregue todos los comentarios como refactor el código. Si el código es realmente viejo y no está documentado, naturalmente eso significa agregar documentación.
Es bueno entender el código antes de modificarlo (by-the-way).
Normalmente se acaba de cambiar el código y hacer mis comentarios en mi registro de control de origen. En la herramienta de seguimiento de tareas de elección, puede hacer referencia a la revisión, donde se llevó a cabo la tarea.
A veces sé que cierta funcionalidad va a cambiar de ida y vuelta, moverse, cambiar nombres, etc., dependiendo de cómo se debaten las necesidades de los usuarios. En este caso especial, mantendré la versión anterior y la comentaré. Luego, se vuelve trivial simplemente descomentarlo más tarde, en lugar de arrastrarse a través del control de código fuente buscando la versión anterior. Esto también puede salvarle el culo a alguien si tiene que mantener su código más tarde, porque cuando los usuarios cambien de opinión OTRA VEZ, el requisito ya estará en el código, esperando ser descomentada.
Tengo que estar de acuerdo con muchas otras personas aquí en SO. "Si no necesitas algo en tu código, quítalo". Especialmente en el código de producción, lo último que quieres es mucho desorden. Podría ser mucho más fácil para alguien averiguar cómo funciona su cambio que leer su comentario de mantenimiento y posiblemente confundirse.
que utiliza para mantener código obsoleto viejo en mis proyectos, pero con el tiempo un proyecto que debería haber sido sólo unos pocos miles de líneas terminó siendo más de 10.000 y difícil de manejar.
Si hago algo así como corregir un error relativamente oscuro, básicamente cualquier cosa que no sea bastante obvia por qué escribí el código de la forma en que lo hice, generalmente agregaré un comentario para explicarlo, para que yo (o alguien más, si alguien más alguna vez modificó mi código ;-) no lo eliminará accidentalmente más tarde.
Una cosa que siempre trato de hacer es poner en el error de identificación (ID o solicitud de función) en el sistema de control de errores en el código de checkin comentarios que hago por ese cambio. Agrego algo así como "ver los comentarios para este error/función en bugzilla para más detalles". Ahí puedo, y generalmente explico, la justificación para ese cambio de código. Esto significa que todos los cambios o al menos todos los cambios importantes deben rastrearse a través de una solicitud de función/ID de error. Muchas veces he creado un error solo para explicar en detalle las razones comerciales involucradas.
1 Me golpearon por un segundo ... –
De hecho, este me vuelve demasiado las tuercas. – DavGarcia
¿Quita cosas así cuando está trabajando en un archivo que otros decoraron de esa manera? – innaM