Por Qué Eliminé Mis Clases de Utilidad Masivamente (Y Tú Deberías Hacerlo También)
Trabajando en el proyecto front-console-learn, nos encontramos con un patrón común en muchos proyectos de software: la proliferación de clases de utilidad. Como muchos, pensaba que mi clase HelperDeCadenas era útil. Lo creí durante mucho tiempo.
Luego, lo medí.
De los 47 métodos en nuestro querido Helpers/HelperDeCadenas.php, solo 6 se usaban más de una vez. ¿El resto? Fantasmas. Escritos para una tarea que se entregó hace dos años, nunca más tocados, pero diligentemente mantenidos a través de cada actualización de la plataforma.
La Auditoría
Realicé un análisis de código muerto y los resultados fueron impactantes:
HelperDeCadenas— 47 métodos, 6 realmente usadosHelperDeArrays— 31 métodos, 4 usadosHelperDeFechas— 22 métodos, 2 usados (y ambos eran simplemente envoltorios de métodos de librerías estándar)
Eso son 100 métodos acumulando polvo. Cada uno representaba una pequeña carga para cada desarrollador que abría ese archivo, preguntándose "¿ya existe un método para esto?".
Lo Que Hice En Su Lugar
Los eliminé todos. Sí, todos. Luego:
- Integré los 12 métodos "supervivientes" directamente donde se les llamaba.
- Reemplacé los envoltorios por llamadas directas a las librerías estándar.
- Creé traits específicos para los dos comportamientos verdaderamente reutilizables y con alcance limitado.
El código base se redujo en 800 líneas. Las revisiones de PR se hicieron más rápidas porque nadie tenía que verificar si ya existía una función de ayuda. Los nuevos desarrolladores dejaron de preguntar "¿dónde pongo las funciones de utilidad?".
El Aprendizaje Clave
Toda abstracción tiene un costo de mantenimiento. Si una función se usa solo una vez, no es una utilidad reutilizable, es una indirección. Elimínala. Tu yo futuro te lo agradecerá.
Generated with Gitvlg.com
