Angular Customizable Templates

The code on GitHubAngular Customizable Template

I’m currently working on a project where we have inherited a lot of AngularJS code. The application was developed as a prototype, so some things were coded in a very quick and provisional way and with a lack of very good practices.

We are now working on the transformation of the prototype to a real product. I’ve ended up making a deep refactoring of all the browser-side code that in some parts it seems more a reboot than a refactoring.

One of the things that terribly frightened me more was to bump into code containing those huge chains of nested $parent.

<span ng-if="$parent.$parent.$parent.object.property">
  {{$parent.$parent.$parent.$parent.object.property}}
</span>

It is generally a very bad idea to access to the parent scope using the $parent property, but it is even worse to reach that level of nesting. The code is unmaintainable. A minimum change in the template will change the depth of the accessed scope and will invalidate all the bindings. There are some core directives that create new scopes, for example the ng-if directive.

It seems that kind of code was driven by the need to customize the HTML templates of certain custom directives.

<my-directive customHeader="/templates/customHeader.html">
  <div>Some content wrapped by the directive using transclusion</div>
</my-directive>

The <my-directive> directive is based in a HTML template and it is declared with an isolated scope. When the customHeader attribute is defined, the directive includes that template HTML file using the <ng-include> directive.

The problem is that all the code included in the customHeader.html file will be accessing the isolated scope of the <my-directive>. An isolated scope doesn’t use prototypal inheritance, so the customHeader.html template needs to use the $parent property to access to the scope where it is supposed to be defined.

While working on that kind of code I thought another way to make it possible to create directives based on HTML that allow the customization of some parts of their templates while retaining access to the right scope.

I made the Angular Customizable Template module. It is based on ‘element’ transclusion. It currently has the drawback that the mechanism only works for directives that wrap its content using simple transclusion. So it is still a work in progress but I think it can give you some ideas.
Seguir leyendo

¿Me creo eso del Refactoring?

La primera vez que escuché algo de metodologías Agile como Extreme Programming o Scrum, una de las primeras cosas que pensé fue:

¡Vaya una mierda que nos están vendiendo!

Esta primera evaluación de las metodologías Agile fue debida precisamente a todas esas historias de trabajar al día. Programar lo justo para cumplir. Evitar la codificación de funcionalidad futura. No perder el tiempo en la creación de arquitecturas para pretendidos frameworks reutilizables. Todo se acabará mejorando en un hipotético refactoring posterior.

 

“Keep it simple, stupid” (KISS)
“You ain’t gonna needed it” (YAGNI)
“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?”

 

Habían sido muchos años de lucha contra el Spaghetti Code, intentando evitar las anti-metodológicas prácticas del Death March o el Cowboy Coding, que es a lo que me sonaba todo lo Agile.

Harto de enfrentarme a código con chapuzas, pegotes y parches, ¿¡Me vienen ahora con unas metodologías que hace apología de todas esas prácticas!?.

Lo estaba entendiendo bastante mal, porque me habían contado a medias la verdadera práctica del refactoring.

La lección aprendida es que para que el agilismo funcione, sin lugar a dudas es vital combinar “GESTIÓN + INGENIERÍA”.

Scrum proporciona una gestión y planificación agile de proyectos. La implantación de prácticas agile en un grupo muchas veces se queda sólo en Scrum, ya que la parte de gestión y planificación es es siempre más fácil de cambiar que las prácticas de ingeniería.

Extreme Programming proporciona la Ingeniería del Software Agile. Son metodologías más complicadas de introducir, ya que requiere de expertos programadores, son prácticas que emergen de la programación y no de la gestión, que es donde suele estar el mayor poder de influencia.

 

Cuando conocí el bucle micro-incremental e iterativo de TDD, o del BDP (Behaviour Driven Programming) de BDD, es cuando realmente entendí el paradigma YAGNI y sus derivados.

 

El refactoring es vital en TDD.
Si no haces un refactoring continuo no estás haciendo TDD.
Si no haces refactoring no estás diseñando.

Usando este tipo de metodologías es como se hacen viables principios como YAGNI. Así es como se puede diseñar directamente desde el código. El código nos va mostrando el diseño y la arquitectura de nuestra aplicación.

 

El refactoring es lo que hace posible que ese framework reutilizable, esa arquitectura o ese gran diseño surja de forma orgánica, justo en el momento que se necesita. Además con la libertad de modificación y trasformación que proporcionada la amplia cobertura de los Small Scaled Tests que han dirigido dicho refactoring.

Deberíamos llamar a la metodología Test Driven Refactoring (TDR).

Me horroriza oír hablar de “la deuda tecnológica”. Este concepto no debería existir. Da la sensación de que se le ha puesto un bonito nombre a lo comúnmente conocido como chapuza tecnológica.

No deberíamos calcular la chapuza tecnológica acumulada a lo largo de los sprints para decidir si necesitamos un período de refactoring. Se trata de un refactoring que nunca jamás nos van a permitir hacer, ya que nunca vamos a tener tiempos muertos.

Los períodos de refactoring no existen porque el refactoring es continuo.

Sí, me creo eso del refactoring, pero cuando se utiliza de forma continua, incremental e integrado en un bucle de trabajo basado en Test Driven Refactoring (o Behaviour Driven Refactoring).

Quiero un Scrum Master Especializado

Muchas veces da la sensación de que el rol del Scrum Master se está convirtiendo en una figura algo devaluada y fácilmente sustituible dentro de los equipos de Scrum.

Parece que el trabajo que realiza un Scrum Master es tan trivial que cualquiera puede desempeñarlo con sólo unas meras pinceladas de la metodología. He oído hablar incluso de equipos que se turnan el rol de Scrum Master de un sprint a otro (personalmente me parece anti-scrum).

No soy Scrum Master y nunca he desempeñado dicho rol.

Sólo soy un miembro más del equipo de desarrolladores, y aun así quiero revindicar la figura del Scrum Master. Trasmitir la importancia de que para vivir un buen Scrum es vital la existencia de un buen Scrum Master, con las habilidades adecuadas, y a ser posible formado y experimentado.

Es cierto que los equipos de Scrum son auto-organizados.

Aun así la figura del Scrum Master es fundamental. El trabajo que debe realizar al margen de los sprints requiere gran dedicación y esfuerzo.

A veces se simplifican las funciones reales de un Scrum Master, reduciéndolas a una mera organización y moderación de reuniones.

¿Es el Scrum Master un simple Moderador de Reuniones?

Seguir leyendo

Test Driven Development: Eliminando Malentendidos

Últimamente cuando alguien me pregunta por TDD acabo planteándome la misma pregunta:

¿Están interesados en la metodología de desarrollo llamada Test Driven Development o en realidad tan solo están pensando en codificar unos tests antes del desarrollo?

Parece una pregunta redundante ¿acaso no es lo mismo aplicar TDD que codificar tests antes del desarrollo de la funcionalidad?

Esta es precisamente la raíz de muchos malentendidos y la respuesta es un rotundo NO.

La Raíz de los Malentendidos

Cuando se habla de TDD en realidad muchas veces se está pensando en técnicas para  la automatización de tests de alto nivel (integración, sistema o interfaz de usuario). El interés que despierta TDD es el interés hacia las técnicas para la programación de tests automáticos, reduciendo TDD a un nombre de moda que aconseja programar los tests antes de escribir una sola línea de código funcional – lo que deja de lado aspectos fundamentales de Test Driven Development, que en realidad es una metodología con reglas propias.

Quizás el problema se deba a que la primera letra ‘T’ dirige el foco hacia el testing en lugar dirigirlo hacia la última letra ‘D’ del development (designing/coding).

Se confunde una metodología del equipo de desarrollo con una metodología del equipo de control de calidad (quality assurance).

Malentendido comprensible al formar parte del nombre de la metodología – esperemos que el cambio de vocabulario propuesto por Behaviour Driven Development con la eliminación de la palabra "test" evite este malentendido.

Test Driven Development es precisamente una metodología diseñada como herramienta de trabajo para los programadores.

No se trata de una metodología para el equipo de QA. Existen otras prácticas más directamente relacionadas con la QA como ATDD – además de prácticas específicas de Agile Testing.

Seguir leyendo