En los anteriores posts quedó claro que, en mi postura, lo importante de un proyecto es que resuelva (o ayude a resolver) el problema del cliente.
Bien, ¿dónde queda todo lo que aprendemos de patrones, OOP, y demás?
Imaginemos que tenemos que desarrollar un sistema que nos diga cual es el número de la lotería de este sábado que viene. Nada más: el cliente nos lo pide, para solucionar el problema “No tengo dinero para encarar otros proyectos e ideas que tengo”. Hacemos el programa, funciona y resuelve el problema del cliente: la falta de dinero.
¿Acaso a alguien le importa los patrones, OOP, SOLID o lo que sea? NO. Solamente importan en dos circunstancias:
– Porque nos ayudan (a nosotros, no al cliente) en el desarrollo actual
– Porque van a ayudar a la gente que haga la versión 2.0 de lo que estamos haciendo
Los patrones son para los programadores. Si el sistema lo armamos de una vez, y funciona, a nadie en el planeta la importaran los patrones que usamos. Mientras nos de el número de la lotería que el cliente necesita, estará todo bien.
Solamente interesa YAGNI, DRY (Don’t Repeat Yourself) y demás en esas dos ocasiones:
– Para nosotros, cuando estamos desarrollando y queremos refactorizar algo.
– Para quien venga luego de nosotros, en la versión 2.0, a mejorar, extender, adaptar lo que armamos.
Ejemplo del primer caso: imaginemos que el algoritmo que estamos usando tiene código repetido. Aplicamos DRY y refactorizamos, sólo para seguir avanzando en el desarrollo. Sino, no hace falta refactorizar. Si así como está, la aplicación ya funciona, a nadie le importa los patrones o cualquier otro factor de diseño que se nos ocurra. “Make it works”, lo primero que hay que obtener.
Pero si vemos que todavía no alcanzamos el objetivo, podemos refactorizar y mejorar la implementación. Es una especie de “Make it right”. Al tener ordenado y “patronizado” lo que estamos armando, es más fácil, en general, irlo modificando.
Si no entendemos eso, no sirve de nada saber patrones. Los patrones se aplican EN CONTEXTO, y para resolver un PROBLEMA en particular. No porque son “cool” o es lo que dicen los librso.
Ejemplo del segundo caso: si nuestro sistema es un ERP, que solamente contemplaba algunos casos de uso, en la versión 2.0 es posible que necesite cubrir otros nuevos casos. Es ahí donde se ve el poder de haber “patronizado” la versión 1.0. El mantenimiento, la extensibilidad, la refactorización será más fácil para el que venga. Recuerden: hay que codificar como si el que vieniera luego de nosotros, sea un asesino serial que conoce el domicilio de nuestra familia 😉 Tenemos que facilitarle el trabajo.
Por supuesto, no todo es codificación en un proyecto. Hay comunicación, explicar lo que estamos haciendo, su adopción, despliegue, etc… Pero antes de proseguir sobre el tema “proyecto bueno”, quería hacer esa aclaración: muchas de las “best practices” que adoptamos son para encarar de forma efectiva la refactorización actual, o la modificación futura. Si no necesitáramos refactorizar ahora (por ejemplo, escribiendo todo bien desde el principio), o no se necesitara la modificación futura (sistemas “one shot”, como obtener el número de la lotería del sábado que viene y nada más), no tendríamos que preocuparnos por patrones o “best practices”.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez