Capítulo 8. Refactorización y gestión de la deuda técnica
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Los programas deben escribirse para que los lean las personas, y sólo incidentalmente para que los ejecuten las máquinas.
Harold Abelson, Estructura e interpretación de los programas informáticos (MIT Press)
Sin refactorización, el diseño interno -la arquitectura- del software tiende a decaer. A medida que la gente cambia el código para alcanzar objetivos a corto plazo, a menudo sin una comprensión plena de la arquitectura, el código pierde su estructura [...]. La pérdida de la estructura del código tiene un efecto acumulativo. Cuanto más difícil sea ver el diseño en el código, más difícil me resultará conservarlo, y más rápidamente decaerá. La refactorización regular ayuda a mantener el código en forma.
Martin Fowler, Refactorización: Mejorar el diseño del código existente (Addison-Wesley Professional)
Como profesionales del ML, sabemos que el código puede volverse desordenado, y normalmente mucho más rápido de lo que esperamos. Por lo general, el código para entrenar modelos ML está compuesto por código semi-boilerplate pegado en un largo cuaderno o script, generosamente salpicado de efectos secundarios -por ejemplo, sentencias de impresión, marcos de datos con impresiones bonitas, visualizaciones de datos- y normalmente sin pruebas automatizadas.
Aunque esto puede estar bien para los cuadernos destinados ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access