Lycka Bonita

Cuando empecé a programar profesionalmente, yo pensaba que escribir código por párrafos era de cajón y que todo el mundo lo daría por supuesto por las enormes ventajas que aporta a la hora de mantener un sistema, pero para mi sorpresa me encontré que no es asi.

Cuando leo una novela y veo un párrafo de varias páginas, tiemblo porque el autor no ha sabido / querido  ordenar suficientemente bien sus ideas y te lo suelta todo ahí de sopetón. Como si fueses a un restaurante y pidieses una entrada, un plato, un postre, un café y una bebida y el camarero te lo sirviese todo junto pasado por la batidora.

Y a la hora de escribir código ? No importa si es HTML, XML, C, Pascal, Java… Es importante escribir por párrafos para que la persona que no conoce el código lo lea y entienda rápidamente. Yo lo aprendí en Pascal, todos mis programas tenían únicamente 3 funciones : inicializar, procesar y finalizar.

Pongamos un ejemplo, un bean POJO en Java. Normalmente el contenido del bean lo podemos estructurar en 2 párrafos : declaración de las variables locales y declaración de los métodos públicos get y set de cada variable. A veces podemos tener 3, si declaramos constructores para ese bean. O 4 si sobreescribimos métodos get o set. O 5 si declaramos otros métodos (como sobreescribir el toString())… Pero si el bean está organizado por párrafos de un vistazo lo vemos, cualquiera tardaría 5 segundos en leer y entender la clase por muy grande que sea sin necesidad de leer cada letra.

En mis años de aprendizaje en mi escuela aprendí que la construcción de un software de calidad se basaba en dos pilares, la modularidad y la reutilización. Mi experiencia profesional me ha demostrado su enorme importancia : he podido disfrutar de sistemas que han seguido estos principios y he tenido que sufrir sistemas que no los siguieron. También que son insuficientes.

La modularidad es básica en software, como bien nos decía Jack el destripador :

Vamos por partes

La curva de aprendizaje es más suave, se puede desarrollar en paralelo reduciendo el tiempo de entrega, es más fácil realizar pruebas unitarias, es más fácil de mantener porque se aislan los errores en módulos.

Pero con qué criterios debemos dividir un sistema monolítico en módulos ? La reutilización es la respuesta, ya que nos permite disminuir el número de módulos necesarios en el sistema e incluso aprovechar módulos para futuros desarrollos.

Estos dos conceptos son suficientes ? Creo que se deberían completar con otros dos conceptos : desacoplo y sencillez.

El desacoplo se consigue con un buen interfaz y la reducción de dependencias externas. Debe ser un criterio complementario a la reutilización a la hora de dividir nuestro sistema en módulos. Por ejemplo si queremos hacer una llamada a base de datos para preguntar el número de usuarios de nuestro sistema, podemos tener un módulo para cada SGDB (uno para MySQL, otro para Oracle, otro para SQL Server…) o un único módulo que obtenga el mismo resultado para cualquier SGBD utilizado. Este módulo será un poco más complejo pero se convierte en mucho más reutilizable.

Ya lo dice el refrán :

Lo simple es bello

La sencillez es la meta común de todo lo anterior, y no sólo por alcanzar la belleza : nuestro sistema global es más sencillo, lo que se traduce en un sistema más barato de desarrollar, reducimos el tiempo del desarrollo, más barato de mantener, más fácil de aprender, reducimos el tiempo de respuesta a incidencias, conseguimos una calidad mayor y nos resultará más fácil de repetir con éxito en el futuro.

La aplicación de estos cuatro simples principios redunda en un beneficio para el cliente, para la empresa de software y para todas las personas participantes en el proyecto.

No olvides además que siempre hay tiempo para hacer las cosas bien, lección que he tenido que aprender en mis propias carnes : no se pierde un día, se invierte un día para luego ahorrarnos una semana.

Me ha llamado la atención un artículo en el suplemento del mundo, "Toca pasarlas canutas" de Pilar Cambra, del que reproduzco un extracto.

[...] si en un momento dado se le pide al niño o al adolescente que haga algo que supone un esfuerzo, incomodidad, salir del letargo, dejar de estar tumbado a la bartola, que nada, que no le apetece… En cambio, si se le propone al crío algo grato, que le mole, se apuntará el primero aunque tenga cuarenta grados de fiebre.

Y yo me pregunto… tanto cambiamos cuando nos hacemos adultos ? Sí, el artículo transmite que ahora es hora de apretar los dientes y trabajar, y estoy completamente de acuerdo. Pero también se puede leer desde el otro punto de vista, si quieres que tus empleados den el callo, lo más barato y eficaz es que le sea grato.

La última frase del artículo también merece ser resaltada:

Más vale apretar los dientes y dejar de quejarse. Porque con los lamentos se pierde mucha de la fuerza necesaria en el combate. Bastante fuerza…

Me gusta la gente que puede presumir de lo que hace, y lo que ha hecho este hombre es acumular una vida ejemplar y una carrera profesional ejemplar. Por eso creo que es digno de admirar e imitar.

Y lo mismo debieron pensar en la Universidad de Florida para pedirle que diera una charla a sus alumnos MBA. Enlazo el primer video de las nueve partes (1 hora y 20 minutos en total). Además a título personal añado mis notas sobre las partes

Parte 1

3 things in hiring people : integrity, intelligence and energy [3 cosas a la hora de contratar a algien : integridad, inteligencia y energía]

You write down those [positive] cualities [...] and write down those [negative] cualities and you look at those cualities on the rigtht and left side and they are all cualities that if you really want to have them [the positive ones] they are achievable and if you really want you can get rid off the others [the negative ones].

Time is the friend of the wonderful business, and it's the enemy of the bad ones.

Parte 2

To make money that they didn't have and they didn't need, they risked what they did have and they did need. [Para ganar un dinero que no tenían y no necesitaban arriesgaron el dinero que sí tenían y que sí necesitaban]

If I ever write a book it's gonna be called "Why smart people do dumb things" [Si alguna vez escribo un libro se titulará "por qué la gente inteligente hace cosas estúpidas"]

You only have to get rich once [Sólo tienes que hacerte rico una vez]

Parte 3

I like businesses that I can understand and I can see where they are gonna be 10 years from now.

Parte 4

 You must know what you do understand and what you don't understand

Parte 5

 El secreto de la Coca-Cola es que no hay memoria para su sabor : te puedes beber 8 al día.

Parte 6

What you're looking for, it's a way to get one good idea a year y llevarlos a su máximo potencial

Parte 7

Very few people had got rich on their seventh best idea, but much people had got rich on thier best idea.

Parte 9

Realiza una interesante reflexión sobre la felicidad en la vida.

El Patrón de Diseño Singleton (en español, Instancia Única) se utiliza para garantizar que una clase sólo tenga una única instancia y para facilitar un punto de acceso global a la misma.

Se utiliza cuando se necesita :

• que sea un único objeto el que coordine acciones a lo largo de todo el sistema
• que el objeto posea estado
• variables globales en el sistema (es más limpio y eficiente utilizar Singleton)

La propia clase es única responsable de crear la única instancia (ocultando al constructor) y de facilitar el acceso global a la instancia. Un ejemplo de implementación en Java :

public class Singleton {

      //Instancia como variable estática

    private static Singleton instanciaUnica;

    //Constructor privado : no se puede acceder desde fuera

    private Singleton() {}

    //Método para obetener una instancia

    public static Singleton getInstancia() {

      synchronized(Singleton.class) {

              if (instanciaUnica == null) {

                  instanciaUnica = new Singleton();

              }

      }

      return instanciaUnica;

    }

}

Es delicado en sistemas multihilo, ya que si dos hilos de ejecución intentarán crear una instancia al mismo tiempo y ésta no existiese todavía, sólo uno de los dos debería de lograrlo. La solución clásica para este problema es utilizar exclusión mutua en el método de creación de la clase que implementa el patrón.

En algunas ocasiones se aplica este patrón de una forma menos restrictiva, permitiendo que exista un número máximo de instancias en lugar de una única.