Mantenimiento - equilibrando la pregunta de cuándo y si hacer cambios

Question

Mantengo un par de bibliotecas para otras personas. Después de haber pasado por un par de lanzamientos para cada uno de ellos, hay algunas cosas que haría de manera diferente, si tuviera que repetirlas nuevamente.

La pregunta es: ¿Debo hacerlas otra vez? Creo que todos nos enfrentamos a ese dilema: cómo equilibrar la utilidad de la actividad de mantenimiento frente a los efectos perturbadores del cambio.

Obviamente para los errores, el cambio es imperativo. No hay dilema allí. Para las nuevas características, es una cuestión de utilidad frente a la complejidad agregada. Me siento cómodo tratando con esa pregunta.

Es el espacio borroso entre la corrección de errores y la nueva característica que estoy preguntando. Un ejemplo es el mantenimiento para cumplir con las pautas de diseño del marco o el cumplimiento de CLS. Para una biblioteca, lo escribí sin pensar en el cumplimiento de CLS, y luego la gente lo solicitó. Como resultado, tuve que modificar la interfaz para intercambiar uint por int. Ese es un cambio disruptivo, con poca ganancia (para la mayoría de las personas).

Otro problema: el cumplimiento de FxCop. Tuve que hacer cambios en los nombres de parámetros para algunos métodos, para hacer feliz a FxCop. Pero esos cambios realmente solo afectan a las personas que utilizan la reflexión: los tipos no cambiaron, solo los nombres de los parámetros.

El problema con el que me estoy ocupando ahora es: las pautas de diseño del marco. Las pautas con respecto a los eventos dicen que los eventos deben tener una firma con dos argumentos: (Origen del objeto, EventArgs e). Pero estuve ausente ese día en mi curso de Diseño de Marco;). Los eventos en mi biblioteca actualmente solo toman un solo argumento EventArgs.

Ahora estoy agregando nuevos eventos a la biblioteca. ¿Deben los nuevos eventos seguir las pautas de diseño del marco? ¿O el patrón ya establecido en la biblioteca? Si utilizo las pautas de diseño para los nuevos eventos, ¿debo modificar los eventos existentes para que también cumplan con las pautas de diseño? Y si es así, ¿cómo hacer la migración? ¿Debo usar el atributo [Obsoleto]? ¿Cuántos lanzamientos?

Más generalmente, me interesan las ideas sobre el mantenimiento en esta área difusa entre la corrección de errores y la nueva función.

Answer 1

En lugar de modificar el código antiguo, desactívelo. Comience su nuevo código con un diseño adecuado y escriba el código de reemplazo para las piezas utilizando el diseño anterior. finalmente, terminará con un sistema que utiliza el diseño adecuado, pero no será un cambio muy perjudicial.

Answer 2

Definitivamente tienes que comunicarte mucho si planeas hacer cambios importantes. Incluso si reiniciará sus bibliotecas como una versión 2, tendrá que decirles a sus usuarios que la versión 1 solo tendrá una solución de errores en el futuro y se dirigirá al desarrollo de la versión 2, donde podrán encontrar todas las nuevas características.

Pero creo que me gustaría ir por este camino. Compatibilidad con la versión 1 para correcciones de errores y portabilidad de una nueva versión 2 para los cambios de última hora.

Answer 3

Si trato de seguir algunas pautas que no seguí antes, lo haré en el nuevo código. Para el código existente, los arreglaré a menos que estén rotos. Pero si encuentra algunos errores en el código existente, es una buena práctica aplicar las directrices mientras se corrigen los errores al mismo tiempo.