Nota: Traducido de la versión original en Inglés.
No me malinterpreten. Los comentarios son útiles y no todos tienen el propósito olfativo de la famosa analogía que estoy usando en el título de este artículo. Entonces, ¿qué tiene de malo los comentarios que los programadores están dispuestos a incluso vestir una camiseta sobre este oloroso asunto? Digamos que tenemos este fragante método:
nastyMethod() {
// conectar a la base de datos
... Código para conectar a la base de datos ...
// crear configuración predeterminada
... Código para crear la configuración predeterminada ...
// cargar configuración
... Código para cargar la configuración ...
... y más, y más, y aún más de esto...
}
El problema aquí es que los comentarios están diciendo lo que el código está haciendo. Los comentarios deberían decir POR QUÉ el código está haciendo algo, no QUÉ está haciendo el código. Además, esto típicamente lleva al anti-patrón Método Largo poniendo en riesgo dos principios básicos de diseño orientado a objetos: Principio de Segregación de Interfaces y Principio de Responsabilidad Única por decir lo menos.
Haz que tu código se explique por sí mismo:
betterMethod() {
connectToDatabase();
createDefaultConfiguration();
loadConfiguration();
}
connectToDatabase() {
... Código para conectar a la base de datos ...
}
createDefaultConfiguration() {
... Código para crear la configuración predeterminada ...
}
loadConfiguration() {
... Código para cargar la configuración ...
}
Podrías argumentar “este método de extraer a método llevará a clases con demasiados métodos, haciéndolos difíciles de entender”. Bueno, usa la refactorización Extraer Clase si llegas a ese punto. Recuerda: Los programas orientados a objetos que viven mejor y más tiempo son aquellos con métodos cortos.
¿Te gustó este artículo? Puedo ayudar a tu equipo a implementar soluciones similares. Contáctame para saber más.