¿Puede un programador aprender a ser más responsable y empático en su vida gracias a aprender mejores formas de programar? Estoy empezando a generarme esa teoría en la cabeza… Cuanto más leo y aprendo sobre patrones de diseño, principios SOLID, clean code y demás buenas prácticas, más me doy cuenta de que puede que sea así.
Colocar el código donde realmente debe estar
A veces nos lanzamos a programar como locos sin pensar demasiado. Visualizamos qué queremos conseguir y paso a paso vamos construyéndolo. Cuando llegamos rápido al final, a lo mejor no echamos la vista atrás para analizar cómo de acoplado hemos dejado el código nuevo generado.
Por ejemplo, échale un vistazo a este video de 15 min (¡cada minuto vale!):
Si te fijas, en él se contemplan varios valores:
- Código más cohesionado: el código que tiene que ver con el mismo tema está junto, cosa que «tu futuro yo» u otro compañero agradecerá cuando tenga que tocar también este código (esto evita que si en el futuro hay que hacer evolucionar el código añadiendo o modificando cosas, no tendrás que cambiarlo en tantos sitios diferentes seguramente)
- Código más coherente y robusto: proteges el código de ciertos comportamientos indeseables, haciendo que no se pueda «usar mal» por diseño (¡me recuerda al concepto «poka-yoke» de Lean!)
- Responsabilidad repartida: no le das demasiada responsabilidad a una clase, mientras que a otra la dejas «tonta»; sino que haces que todas las clases sean «adultas» y que bien se encarguen de lo que se tienen que encargar
Analogía con la realidad: personas más responsables
Y tras este tema de la responsabilidad bien repartida, en el vídeo nombran el maravilloso principio de Martin Fowler, Tell-Don’t-Ask:
Lo que se ve en la imagen superior describe lo siguiente:
Rather than asking an object for data and acting on that data, we should instead tell an object what to do.
En lugar de tener la lógica en un lugar separado de los datos, cosa que te obliga a estar preguntando por esos datos una y otra vez para poder continuar, ten la lógica junto a los datos y simplemente desde la izquierda pídele a la derecha que se encargue de hacer «algo», para que esa clase lo haga como quiera, pero que lo haga bien.
Es que me encanta la analogía con, por ejemplo, un jefe tradicional con su equipo técnico. O en mundos «ágiles con comillas» (agilidad mal entendida) con roles de Product Owner y desarrolladores. Imaginemos que la clase de la izquierda es el jefe tradicional o el Product Owner actuando como cuello de botella. En lugar de que el jefe/PO-mal-entendido tenga que estar preguntando al técnico una y otra vez por conocimiento que no tiene para poder avanzar (estimar trabajo, aclarar qué hay que hacer con stakeholders o para debatir sobre la solución técnica con los desarrolladores…), ¡¡delega directamente en el equipo de desarrollo!! Explícales qué es necesario hacer (qué problema se necesita resolver) para que ellos decidan cómo hacerlo, y hacerlo bien.
Pero, no te obsesiones tampoco
Como siempre, lo mejor es parar un momento y pensar: ¿debo seguir esto que me dicen al pie de la letra siempre? Pues NO. Tanto si hablamos de dónde colocar el código o cómo es mejor gestionar cierta información con el equipo (hasta dónde delegar), habrá casos en los que venga bien hacerlo así y otros en los que sea mejor de otra manera. Habrá casos en los que tener un método set o get (como nombran en el video) será necesario para que otra clase lo use, y no hace falta que te sientas culpable por ello.
Lo dice muy bien Martin Fowler al final de su artículo también. No utilices el principio Tell-Don’t-Ask como un fin (ni el artículo ni nada de lo que leas, escuches, aprendas como regla), sino como el medio que te permita llegar a la mejor solución hasta el momento. ¡Lo mejor es plantearlo como una ayuda al aprendizaje!
Aquí hago mención a la frase que más me gusta de Borja Vilaseca, porque me parece que viene muy al caso:
No te creas nada de lo que te cuenten. Verifícalo con tu propia experiencia.
Y sobre esta frase, añado yo de mi cosecha:
No quieras aplicar una regla de forma sistemática para todos los casos. Piensa bien cómo gestionar la situación (tratando con código o tratando con las personas), dado todo el conocimiento que posees hasta el momento, para no «acoplarte demasiado» 🙂