Principios SOLID

Estos principios, que supongo ya conoceréis todos, están orientados a los que se inician en la programación orientada a objetos. Después de todo, el sentido común ya nos orienta a este tipo de prácticas, pero es gracias a su recopilación, que los que empiezan pueden aplicarlas.

Ayer un compañero me comentaba: “Oye Roberto, a veces las nuevas incorporaciones las formamos mucho y bien en tecnologías, en frameworks y lenguajes de programación. Pero no les enseñamos realmente a programar”. Pensaba en la afirmación, y efectivamente, saber programar es algo mucho más complejo que saber un lenguaje o un framework. Es por eso que me he acordado de este post que llevaba mucho tiempo sin completar.

Por si algún despistado no conoce los principios SOLID, vamos a revisarlos.

Robert C.Martin, introdujo a principios de la década del 2000 este concepto. SOLID corresponde a 5 principios en los que fundamentar la orientación a objetos:

  • S: Single responsibility.  Principio de responsabilidad única. Cada objeto, debe dedicarse a una sola cosa. Si os fijáis, es una ampliación del concepto clásico de programación en el que un método o función debe tener un único propósito.
  • O: Open-closed. Las clases u objetos han de estar abiertas para su extensión, pero cerradas para su modificación. Este principio está directamente relacionado con la herencia en Orientación a Objetos.
  • L: Liskov substitution principle (principio de substitución de Liskov). Este principio promulga que todos los objetos deberían ser sustituibles por instancias de sus subtipos sin afectar al funcionamiento del programa. Es decir, que no debemos reimplementar los métodos en las clases heredadas, sino utilizar los de las clases base.
  • I: Interface segregation principle (principio de segregación de la interfaz). Este principio afirma que es mejor muchas interfaces cliente específicas, que tener una sola interfaz de propósito general. Este principio busca el desacoplamiento entre clases.
  • D: Dependency inversion principle (principio de inversión de la dependencia), donde Robert C.Martin nos indica que se debe depender de abstracciones, no de implementaciones. Por ejemplo, la técnica o patrón de inyección de dependencias sigue este principio.

¿Y tú, tienes en cuenta los principios SOLID a la hora de programar?

 

La línea de Base y los cambios en producción

branch-per-taskMuchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva “foto”, y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y “jugárnosla”, hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

MasterDev, el MasterChef del software

Hala, por fin se ha acabado en España la versión infantil o “Junior” de un conocido concurso internacional de televisión llamado “MasterChef”.

Yo, personalmente, os propongo hacer uno parecido llamado “MasterDev”. Los objetivos de este nuevo concurso serían más o menos los siguientes:

  • Los concursantes, tendrían una sección inicial del programa en el que se mostraría el lado humano: cómo han convivido, cómo han aprendido las últimas técnicas de programación, frameworks, lenguajes, etc. Se les vería su día a día encerrados en “la casa”, donde tendrían sus momentos de roce, tensiones internas, se formarían grupos…
  • Por supuesto, habría un apartado de “expulsados” en el que los concursantes elegirían a los 3 nominados. De entre ellos, uno sería expulsado por votación del público.
  • Finalmente, el plato fuerte del programa sería el desarrollo “en directo” de una aplicación, basada en los requisitos y exigencias de los chefs (bueno, en este caso, scrummasters o similar). En este apartado, unos famosos programadores harían de estrellas invitadas y propondrían los casos de uso/historias de usuario a desarrollar. Serían los jueces que elegirían a los mejores programadores cada semana. Éstos “Master-Dev” podrían salvar a uno de los nominados, tal y como se hace en otro conocido concurso: “Gran Hermano”. Durante esta parte del programa, se nos estaría mostrando a los programadores llevando a cabo las tareas encomendadas, con la tensión de ver el reloj. Para darle mayor realismo, podría ser un reloj marcando la hora de salida del  trabajo, lo que aportaría una tensión increíble.
  • Finalmente, el momento culmen del programa sería cuando los jueces irían diciendo los puntos fuertes y débiles de cada programador, y se elegirían los “Master-Dev” de la semana.

No sé lo que os parece, pero yo creo que no tendría la misma tensión que el programa original “MasterChef”. Ver 20 minutos a una serie de programadores, sentados en sus sillas, tecleando como si les fuera la vida en ello, no se si sería digno de ocupar el prime-time de las principales cadenas de televisión.
En el cine, “Swordfish” (2001) ha sido una de las películas en las que más tensión se ha podido observar mientras se mostraba a un programador (Hugh Jackman) tecleando en sus teclados y observando con pasión sus múltiples monitores. Sin embargo, veo difícil el llevar esto a la televisión, especialmente recordando el motivo que hace que Hugh Jackman salve su vida cuando es sometido a presión por John Travolta (sí, se trata del trabajo realizado por cierta señorita). Por cierto, ver a Hugh Jackman programando un peligroso virus simplemente “pegando” cubos entre sí en pantalla, es un puntazo. No tendría la misma tensión si “Swordfish” tuviera un diálogo más realista:
– “A ver…mierda. Me he dejado un punto y coma”
– “Compilo…y a ver….15%….40%….mierda. Dos warnings y 1 error. Pues vaya.”
– “A ver…busco el error en google, pero ¿esto que es?”
– “Ah ya lo tengo. Venga, cambio el tipo de la variable….añado el parámetro que faltaba…”
– “Compilo…y a ver…15%…40%…(dios que lento)…60%…mierda. Otro error.”

Tal vez se le podría dar algo más de emoción. Y no, no me refiero al trabajito que le hacen a Hugh Jackman en SwordFish para motivarle. Me refiero a comentarlo como si fuera….no sé…un partido de fútbol:
– Atención, John recibe el código, lo compila yyyyyyyyy Uyyyyyy. Un erroooor. Sí señores, un error ha entrado de llenoooooooo. Neumáticos Martinez, los mejores. Compreeeee neumáticos Martínez (no podía faltar la publicidad en una retransmisión deportiva).
– Señoras y señores, qué tensión! John todavía no ha corregido su error, y Anthony ha compilado con éxito atencióoooooon que ha compiladoooooo.
– Cuidado, cuidado, que un tercer programador está a punto de terminar, es Juan. Recuerden que Juan no había destacado en otros programas, pero ha terminado sólo 1 segundo y 3 décimas por detrás de Philips. Cuidado, todavía no han hecho checkin! Beba Rock-cola, burbujeante, maravillosa!
– Increible! Philips ha perdido el código! Error de aplicación, eso lo deja fuera del concurso! Qué tensión, John está terminando de depuraaaaaar yyyyy gana Juan!  Por tan sólo unas líneas de código por delanteeeeee.

¿Y vosotros? ¿Os gustaría ver un “MasterDev” como concurso?
En fin. Feliz año nuevo.

Update: Gracias a Julián Gómez por la idea de cambiar el titular, y por leerme. Me había quedado muy simplón como “MasterDev” sin más.

La doctrina del comentario

Hoy voy a hablar del comentar o no comentar el código, que parece que se está convirtiendo en una doctrina.

¿Qué es lo que ocurre? Vengo observando un tiempo la tradicional defensa del comentario como algo necesario, pero que hay que controlar en tamaño (nº de comentarios respecto al código), forma (estándares), etc.

Por otro lado, está la defensa a ultranza de la total ausencia de comentarios. Ojo, porque aquí sí que se suelen excluir los comentarios JavaDoc o NDoc que suele haber al principio de las clases y que se utilizan principalmente para documentar el código. Esto, menos mal, parece que nadie lo pone en duda (o al menos, no he identificado un grupo que esté por la labor de eliminarlo).

A continuación, veremos algunos argumentos o doctrinas que la gente utiliza en sus blogs en internet, y que me parecen interesantes. No los copio aquí para ensalzar ni tampoco ridiculizar a sus autores, sino sólo para intentar entender este tipo de argumentos y poder entender de qué hablamos. El objetivo no es tanto quitar la razón a los que están en contra de los comentarios, sino más bien entender el porqué de su postura, y tratar de ir un poco más allá. Yo de momento, sí me declaro abiertamente defensor de comentar el código, aunque luego hablaremos de con qué matices (mmm veo que de aquí tengo material para otro artículo de enfermedades del software: la “comentaritis”). Siempre creo que “menos es más”.

Frases en contra o a favor de los comentarios que podemos encontrar por la web:

  • Usar comentarios va en contra de mis principios.
  • los comentarios son siempre “el patito feo” del código fuente, cuando en realidad son tan importantes como el resto
  • comentar antes de programar, es lo que todo programador debe hacer. No puedes lanzarte a programar sin saber lo que quieres lograr.
  • al desarrollador por lo general no nos gusta “perder el tiempo” comentando y mucho menos documentando
  • si lo he hecho yo, ya sabré porqué lo he hecho
  • los comentarios en el código son algo completamente inútil que no hacen más que entorpecer y causar problemas
  • Cuando el código es modificado, tenemos que modificar también los comentarios, pues corremos el riesgo a explicar algo que no es lo que estamos haciendo. Ya bastante trabajo resulta mantener un código para también tener que mantener un paquete de oraciones.
  • Provocan problemas culturales, ya que muchas veces los comentarios están en un idioma diferente al que es capaz de leer el desarrollador actual, o en la mejor intención de hacerse entender, el “escritor” dejó una lista de oraciones sin concordancia, sentido, y con cientos de faltas de ortografía y errores gramaticales.
  • El que un comentario parezca necesario es signo de que el código no es lo suficientemente claro. Un buen código debe siempre explicarse por sí mismo sin necesidad de un “bastón” (o comentario).
  • Reducen la claridad en el código. ¿Alguna vez han visto un método con 50 líneas de las cuales menos de 10 son de código y lo otro es todo un tratado científico? Yo sí, y resulta un verdadero dolor de espalda descubrir las líneas reales ejecutables entre tantas palabras
  • Esta técnica de crear métodos para aislar secciones de código y dejar bien clara su función es extremadamente útil para aumentar la claridad. En vez de tener un módulo con 500 líneas ejecutables, podemos dividirlo en varios métodos cuya responsabilidad esté bien delimitada. El resultado final será mucho más claro y flexible.
  • los comentarios son la prostitución de las incapacidades de un programador.

¿Qué radicales son algunos de los comentarios, verdad? Y no es para menos. Por desgracia, es frecuente encontrarse programadores poco experimentados en los equipos que acaban sufriendo de “comentitis”: lo llenan todo de comentarios por su inseguridad y falta de método. Aquí os recomendaría los que a mi modo de ver son dos libros indispensables tanto para programadores que se creen experimentados, como para los que empiezan. (Creedme, nunca seremos suficientemente experimentados, y lo que es peor, el paso del tiempo, la destreza se pierde). Los libros son:

  • Code Complete, de Steve McConnell
  • Clean Code, de Robert C. Martin

Dejaremos para otro día unas recomendaciones sobre qué y cómo comentar, y porqué. Ahora vamos a dar un breve repaso a algunos consejos para evitar que nos afecte:

  • No podemos controlar todo lo que hacen los demás. No podemos exigir que respeten nuestra forma de trabajar si no respetamos la de los demás. No todo el mundo tenemos el mismo nivel técnico.
  • Si algo te molesta, dilo. Pero ten respeto por las personas y su trabajo. Además, te encontrarás con que quizás a ese programador le obligaron a hacerlo así, o quizás era su primer trabajo (todos hemos tenido un primer trabajo, y un segundo trabajo).
  • Controla tu ego. No puedes imponer a todo el mundo trabajar como te gusta. Porque se trata de eso: tu gusto.
  • No confundir lo anterior con normas de codificación. Si el proyecto o la empresa (o el cliente), tiene unas normas de codificación, hay que seguirlas. Peor que ver código mal hecho, es ver código hecho de dos formas distintas en función de miembros del equipo disciplinados, y los “libres y ajenos a toda norma”.
  • las normas de codificación, y sobre todo, las relativas a los comentarios, han de ser muy simples. Un comentario no es tan importante como para perder tiempo con 200 páginas de normas y un curso intensivo de 3 días.
  • El comentario no nos va a dar de comer: el código sí. Dicho esto, no significa que debamos ignorar y eliminar los comentarios. Si cada palabra clave o sintaxis del lenguaje que no nos gusta o “nos parece” poco útil se eliminara, os aseguro que entre unos y otros, sólo dejaríamos en el código líneas en blanco.
  • Todos dejamos código basura. (unos más que otros,es cierto). Pues también hay comentarios basura. Y contra ambos hay que luchar.
  • En tu empresa, en tu proyecto, adopta una forma de comentar simple y efectiva, minimalista. Usa sólo lo imprescindible y haz que todos lo adopten. Si trabajas solo, ten en cuenta que tu código o lo pueden usar en otros proyectos, o ya se está integrando en otros proyectos. Recuerda: hazte respetar respetando tú antes la forma de trabajo de los demás.

¿Estáis de acuerdo? ¿O sois defensores de los comentarios? ¿O abogáis por su más absoluta erradicación?
Por cierto, habrá que acuñar el término “Genocida de Comentarios”, si esto llegara a ocurrir 😉
Y bueno, creo que ya vale para una entrada un tanto improvisada.
Un saludo a todos.