Mi regla general es que cuando tengo que hacer algo por tercera vez, es hora de escribir un pequeño script para automatizarlo o repensar mi enfoque.
No estoy haciendo una "herramienta" completa en este punto, solo un pequeño script (generalmente bash o python; perl también funcionaría, o incluso PHP) que automatiza lo que hice manualmente antes. Básicamente es una aplicación del principio DRY (o el principio Single Source Of Truth, que es esencialmente lo mismo): si tiene que cambiar dos archivos fuente en conjunto, debe haber alguna verdad común que compartan, y que la verdad tiene que ser factorizada y almacenada en un lugar central. Es genial si puedes resolver esto internamente refactorizando, pero a veces, esto no es factible, y ahí es donde entran los scripts personalizados.
Luego, más adelante, el guión puede o no evolucionar en una herramienta completa, pero generalmente comienzo con un guión muy específico con muchas cosas codificadas.
Odio el trabajo duro con pasión, pero también creo firmemente que es un signo de diseño incorrecto o malo. Ser perezoso es una cualidad importante en un programador, y es mejor que sea del tipo en el que pasas grandes distancias para evitar el trabajo repetitivo.
Claro, a veces el saldo es negativo: pasas tres horas refactorizando tu código o escribiendo un script para ahorrarte una hora de trabajo repetitivo; pero, por lo general, el balance es positivo, más aún si considera costos que no son directamente aparentes: falla humana (los humanos son realmente malos en el trabajo repetitivo), base de código más pequeña, mejor mantenibilidad debido a la redundancia reducida, mejor auto documentación, futuro más rápido desarrollo, código más limpio. Entonces, incluso si el saldo parece negativo en este momento, la base de código crecerá aún más, y esa herramienta que escribió para generar formularios web para tres objetos de datos seguirá funcionando cuando tenga treinta objetos de datos. En mi experiencia, el equilibrio generalmente se estima a favor del trabajo duro, probablemente porque las tareas repetitivas son más fáciles de estimar y, por lo tanto, se subestiman, mientras que la refactorización, la automatización y el resumen se perciben como menos predecibles y más peligrosos, y por lo tanto sobreestimados. Por lo general, resulta que la automatización no es tan difícil después de todo.
Y luego existe el riesgo de hacerlo demasiado tarde: es fácil refactorizar tres nuevas clases de objetos de datos en forma y escribir un script que genere formularios web para ellos, y una vez que lo haya hecho, es fácil agregar 27 clases más que También trabaje con su guión. Pero es casi imposible escribir ese script cuando ha llegado a un punto en el que hay 30 clases de objetos de datos, cada una con formularios web escritos a mano y sin ninguna coherencia entre ellos (también conocido como "crecimiento orgánico"). Mantener esas 30 clases con sus formas es una pesadilla de codificación repetitiva y reemplazo de búsqueda semi-manual, cambiar aspectos comunes lleva treinta veces más de lo debido, pero escribir un guión para resolver el problema, lo que habría sido una pausa para el almuerzo sin complicaciones cuando el proyecto comenzó ahora es un terrible proyecto de dos semanas con la perspectiva temible de un mes posterior que consiste en corregir errores, educar a los usuarios y posiblemente incluso darse por vencido y volver a antigua base de código. Irónicamente, escribir el desorden de la clase 30 tomó mucho más tiempo de lo que lo habría hecho la solución limpia, porque podrías haber estado usando el script conveniente todo ese tiempo. En mi experiencia, la automatización del trabajo repetitivo demasiado tarde es uno de los principales problemas en proyectos de software grandes de larga duración. porque podrías haber estado usando el conveniente guión todo ese tiempo. En mi experiencia, automatizar el trabajo repetitivo demasiado tarde es uno de los principales problemas en proyectos de software grandes de larga duración. porque podrías haber estado usando el conveniente guión todo ese tiempo. En mi experiencia, automatizar el trabajo repetitivo demasiado tarde es uno de los principales problemas en proyectos de software grandes de larga duración.
