Connascence, nuestra guia para el camino

Posted on by

La semana pasada realice una pequeña presentación en Lifull Connect sobre el método Connascene, elegí este tema ya que realmente me pareció algo así como un salvavidas al que aferrarse cuando estas empezando en el mundo del TDD y la refactorizacion de código.

En este pequeño articulo compartiré un poco mi experiencia con esta técnica y dejare un enlace a mi presentación al final de este texto con ejemplos sobre los diferentes métodos por si queréis ir un poco mas allá.

Cuando creamos código desde cero o bien cuando refactorizamos uno que ya existe, una de nuestras metas ( ademas de que todo siga funcionando correctamente ) es que sea limpio, fácil de entender y sostenible. 

Pero es una meta difícil de alcanzar sobretodo cuando como yo, hace relativamente poco que has descubierto el mundo del TDD y las metodologías ágiles.

Hay muchos métodos y técnicas que se pueden implementar, como los Code Smells o Patrones de diseño, sin olvidarnos de SOLID, lo que hizo que al principio me sintiera un poco perdida. 

Yo vengo como muchas de vosotras de “ la jungla ” donde nada de esto importaba, solo primaba el sacar el trabajo a tiempo y que funcionara, con lo que al entrar en este nuevo mundo me di cuenta de que sí,tenemos muchos recursos y herramientas para facilitarnos el camino, pero cuando no tienes experiencia se hace muy difícil recordarlas todas.

Según avanzaba en el Apprenticeship de Cokaido me di cuenta que tenía todo un abanico de posibilidades ante mí que tenía que aprender no solo a aplicar sino a reconocer en el código, lo que hacía que echara de menos algo así como una “lista de pasos a seguir” para poder empezar a caminar e ir adquiriendo los conocimientos de manera más progresiva. 

Y estaréis pensando ¿Connascence? ¿Una herramienta más? ¿Podré recordarlo todo?…..¿Es una metodologia nueva? Si y no me explico

Connascence se refiere a cuando dos elementos o más de software, requieren que cambien otros o que cambien juntos cuando uno de ellos requiere una modificación.

Bien, ¿suena a nueva técnica verdad?, ahora os voy a explicar que ha sido para mí Connascence, y es ni más ni menos que la brújula que he estado buscando. Son una serie de pautas o pequeñas guías que nos ayudan realmente a implantar y visualizar más fácilmente todos los métodos anteriores. Aunque realmente mas que parecerse a una brújula es mas bien un gráfico con tres ejes.

Imagen de Agile Thecnical Practise Destilled

Cada uno de los ejes representa una casuística a tener en cuenta:

  • DEGREE :El impacto estimado que tendrá un cambio en nuestro código. Cuanto más alto más difícil será realizar un cambio.
  • LOCALITY: La cercanía entre sí de nuestros elementos. Debemos intentar mantenerlos lo más cerca posible para no hacer llamadas a lejanas y tener demasiadas dependencias
  • STRENGTH: Cómo de complejo será realizar esos cambios. Es las mas difícil y costosa de aplicar ya que conlleva una buena planificación y reestructuración 

Teniendo su significado en mente volvamos a nuestro gráfico , hacerlo perfecto es casi imposible por ello nuestra meta será mantenerlo lo más cercano al círculo que podamos. Intentando minimizar el impacto de los tres ejes y valorando que es mejor aplicar en cada momento.

Imagen de Agile Thecnical Practise Destilled

Ahora bien ¿Como podemos llegar a ese círculo sin morir en el intento ?

Connascence nos proporciona una pequeña guía que podemos seguir para acercarnos lo máximo posible a él. Nos divide las problemáticas en dos tipos Dinámicas que solo se ven en tiempo de ejecución y Estáticas que pueden verse en tiempo de compilación  

STATIC

  • NAME: Varios componentes de una aplicación deben ponerse de acuerdo en el nombre de una entidad
  • TYPE: Varios componentes de una aplicación deben ponerse de acuerdo en el tipo de una entidad
  • CONVENTION(MEANING): Dos o más componentes tiene que tener un acuerdo en el significado de su valor. Es decir que tiene que tener un significado entendible. Evitar nombres de variables poco intuitivas o por ejemplo en switch case usar valores como 1,2 sino algo más descriptivo como una palabra que defina esa casuística.
  • ALGORITHM: Dos o más componentes usan un mismo algoritmo de manera individual, por lo que si este cambia se debe propagar en todos los  componentes  
  • POSITION: Ocurre cuando en un método añadimos varios componentes que deben ser adjuntados en un orden concreto. Es muy común el ejemplo del email, donde en vez de usar 3 strings para construirlo (emisor,receptor y mensaje) podemos utilizar tres objetos diferentes que eviten así que un dia nos equivoquemos en el orden y tengamos un comportamiento no deseado. TIP: Suele estar relacionada con Primitive obsession

DYNAMIC

  • EXECUTION ORDER: La llamada a componentes de una aplicaciones debe tener un orden concreto que no está registrado explícitamente. Este tipo de información suele parecer muy clara en el momento en que escribimos el código, mejor definir siempre el orden de ejecución y dejarlo claramente implementado para que mas tarde cualquiera pueda entender el flujo de ese programa. 
  • TIMING:Dos o más llamadas depende del tiempo , es decir de cuando deben ejecutarse. Parecido al anterior si para que funcione correctamente se tienen que llamar en un momento concreto dejarlo implementado de manera que sea obligatorio que así ocurra
  • VALUE: Cuando dos o más componentes estar interrelacionados o tienen un rango de validación que no se expresa o deja constancia. Si tenemos que meter un  valor con un rango concreto, dejarlo codificado de manera que no pueda salirse de ese rango y que dicho rango sea definido de manera explícita en el código. 
  • IDENTITY: Cuando uno o más componentes hacen referencia al exactamente la misma instancia de otra entidad

Como veis tiene muchos componentes que en realidad forman una lista de “cosas a evitar / solucionar” En esta gráfica se puede ir pasando de una a otra de manera lineal y cuando encontramos una volver a la inicial  repitiendo el mismo proceso. Esto ayuda a tener una especie de cuerda a la que aferrarte mientras coges soltura aplicando las otras técnicas y ganas experiencia en reconocer los code Smells por ejemplo. 

Connascence puede ser la brújula que te indique el camino hacia un mejor código, puede ayudarte a aplicar correctamente otros métodos y que aprendas a verlos en el código más fácilmente.

Si queréis saber un poco más sobre esta técnica, os recomiendo el libro Agile Technical Practices Distilled de Pedro Moreira, Marco Consolaro y Alessandri Di Giola. Donde podréis encontrar ejemplos explicados más detalladamente sobre las diferentes técnicas, además de un montón de información sobre Agile con ejercicios y documentación de apoyo.

Mis aventuras con Agile continúan mientras dedico mi escaso tiempo libre a regar plantas en el Animal Crossing o a trabajar en mi TFM pero eso ya es otra historia….

Comments

Leave a comment

Your email address will not be published.
Required fields are marked *