2010-12-02 10 views
7

Tengo una biblioteca que se ocupa de varios formatos de mensaje. Cada uno de estos formatos está estrechamente relacionado, son un XML base común y cada uno tiene algunas restricciones adicionales o datos adicionales encima.¿Cuál es la "mejor práctica" para eliminar el soporte para una característica?

Uno de estos formatos fue creado solo para respaldar una prueba de concepto o esfuerzo piloto. El piloto ha terminado, ya no se usa, y ha impuesto algunas restricciones incómodas. Obtuve permiso para eliminar el soporte para ello. ¿Cuál es la forma correcta de hacer esto?

estoy pensando:

  1. Abrir un problema para rastrear/documentar los cambios
  2. etiqueta de revisión del SVN, "FEATURE_X eliminado aquí"
  3. @Deprecate las clases específicas. Cita el problema. Cometer.
  4. ver a los avisos y ver lo que la depreciación afecta
  5. se deja reposar un poco, darle al equipo la oportunidad de hacer frente a la desaprobación
  6. Finalmente eliminar el código. Verifique que las pruebas estén correctas. Cometer.
+3

Lo único que agregaría a su lista sería un alcance a sus consumidores, si son externos, y asegurándose de que tengan lo que necesitan para pasar a la API. – hvgotcodes

+2

+ bump el número de versión :) –

+0

+1 lista útil - casi una receta de refactorización – orangepips

Respuesta

3

Para los pasos anteriores, sugiero que se comunique claramente a los demás que la característica se eliminará dentro del plazo establecido. Y si la función y/o el equipo son grandes, sugiero que otros se comprometan a eliminar sus dependencias de código para esa fecha (mientras más grande sea el equipo, más importante es el compromiso, considere la compatibilidad de los gerentes para esta tarea). Como lo demuestra mi experiencia, quitar algo es una gran sorpresa para algunos usuarios, y siempre hay alguien en algún lugar con algún código que todavía depende de FEATURE_X. Y por último pero no menos importante, un paso adicional para realizar una eliminación de ejecución en seco, que puede ser fácil y rápidamente deshacer.

+0

Buena llamada. La biblioteca general es utilizada internamente por una docena de personas, algunos clientes externos, pero solo 3 o 4 personas saben que esta característica en particular existe. – Freiheit

+0

@Freiheit Yo diría: nunca se sabe. En algunos casos, realmente me sorprendió cómo y quién usó una determinada pieza de código. –

+0

Aceptado. Cubre algunos de los aspectos del "espacio de carne" que a menudo son más difíciles de abordar que los aspectos del código. – Freiheit

5

Creo que tiene una buena lista. Para hacer eco en @hvgotcodes, esto presupone que nadie use la API fuera de su equipo. En cualquier caso, dentro del método desaprobado, registraría las trazas de pila para cualquier llamada a él. Esto captaría los usos internos y externos.

Cuestiones relacionadas