Categoría: Arquitectura & DevSecOps

Últimamente se oye hablar mucho sobre la industrialización del software, como algo no siempre adecuado, y muy asociado al ciclo de vida en cascada o waterfall.

No tengo muy claro si el termino de industrialización en el campo del desarrollo de software está muy claro. En alguna ocasión he expuesto mi punto de vista.

Si por industrialización entendemos la cadena de montaje de un coche si puede asimilarse al ciclo de vida en cascada.

Si por industrialización entendemos el tener definido un método de trabajo adecuado a la empresa y proyecto en el que estamos desarrollando el trabajo, con sus correspondientes procedimientos, etc. No creo que sea necesariamente asimilable al ciclo de vida en cascada.

Es decir una empresa o proyecto puede tener metodologías y procedimientos perfectamente ágiles.

Lo que no creo que sea asumible son los proyectos o empresas en las que, por ejemplo, se ha perdido código por no tener un control de versiones riguroso.

Creo que en el planteamiento del agilismo, como por ejemplo en Scrum, hay una trampa. Cuando se habla de equipos autoorganizados, se pone una precondición muy importante y que aveces se nos olvida, que es la de conseguir gente con talento. Pero no siempre es posible tener ese tipo de personas.

Por eso me parece importante, tanto en agilismo como en el ciclo de vida en cascada el definir la metodología y los procedimientos, ágiles o no, y que se cumplan a rajatabla. Y si hay que adaptarlos se adaptan.

En mi opinión lo ideal sería que se definiesen a nivel de empresa, para que si se tiene que mover una persona de un proyecto a otro el tiempo invertido en ponerse al día sea mínimo. Al final nuestros clientes lo que quieren es un producto Bueno, Bonito y Barato.

Todos estos tipos de condicionantes hacen que no se pueda aplicar una metodología ni ágil ni no ágil sin una adaptación, labor que se debe hacer por los ingenieros de software.

Desde mi punto de vista la industrialización del desarrollo de software debe propiciar una serie de beneficios a la empresa o proyecto.

– Aumento del control sobre el proceso productivo y reducción de la producción artesanal.

La producción artesanal entendida como el programador que está en su sitio haciendo las cosas en principio perfectamente, pero a su aire. Llegado el momento que por ejemplo se pone malo y sea una odisea que alguien retome su trabajo.

Suelo aplicar un decálogo que me funciona muy bien.

– Reducción de los tiempos dedicados a tareas que no aportan valor al cliente.

A los clientes les importa cero nuestras elucubraciones mentales de metodologías, herramientas, polimorfismos, complejidades ciclomáticas y demás parafernalia. Lo que quieren es un producto Bueno, Bonito y Barato.

Unos compañeros que llevaban una parte del proyecto me comentaban que una de las cosas que más valoraban los usuarios, médicos en este caso, era que a la hora de pedir una radiografía para un paciente, les aparecía un dibujo de una persona y si querían una radiografía del brazo, pinchaban en el brazo en vez de en un desplegable… Estas cosas como técnicos nos debieran de hacer reflexionar.

– Aumento de la homogeneización de los productos elaborados.

Sobre este punto ya he comentado en alguna ocasión con un ejemplo práctico de como encarecer el producto sin aportar valor al cliente.

– Creación o mejora de los procedimientos técnicos para las auditorias externas (CMMI, ISO,…)

Estudié en un colegio de «curas» y una vez uno nos dijo que «En esta vida además de ser santo hay que parecerlo«. Que un auditor externo te ponga un sello significa que por lo menos tienes cierta preocupación por la calidad y que cumples unos mínimos.

– Reducir el malestar entre los involucrados en el proyecto debido al sobre esfuerzo que se debe realizar para compensar las ineficiencias.

Siempre que pienso en la industrialización del desarrollo de software me viene a la cabeza la imagen de la maquinaría de un reloj. Si la maquinaria no está bien ajustada y engrasada hay que aplicar mucha más energía para moverla. Y eso cansa y sobre todo desespera. Y este es un sector en el que lo principal son las personas.

Decía Kent Beck en su libro de programación extrema que si sales de casa para ir al trabajo y tienes un nudo en el estómago es mala señal. Hay que ir con cierta alegría y volver a casa cansado pero satisfecho.

La primera vez que escuche que el cliente/usuario no probaba la aplicación sino que solo la validaba no entendí nada.

Total si es lo mismo, pensaba yo, entrar en la aplicación y comprobar que funciona bien… Pero no, no es lo mismo probar que validar.

Sin ponerme muy academicista, con un ejemplo se entenderá mejor.

Un cliente/usuario no tiene que entrar en la aplicación y comprobar que si no mete un dato en un campo obligatorio la aplicación le saca un mensaje de error sin «petar». Eso es probar la aplicación, es tarea del programador y del responsable que da el visto bueno en caso de que exista. Os dejo una entrada sobre pruebas que no podemos fallar.

El cliente/usuario si tiene que entrar a la aplicación y comprobar que la lógica es la correcta, es decir que, si por ejemplo, es una aplicación de venta, cuando se vende un producto este se descuenta del almacén y se genera la factura y si hay poco stock envía una notificación a compras para que …

Es importante distinguir esos dos conceptos. Hay clientes que ya se están incluso negando a probar la aplicación en producción, por el tiempo que les lleva…

Unas reflexiones a raíz de una entrada en el blog de Javier Garzás sobre si se va a necesitar cada vez menos programadores.

En los casi 15 años que llevo en la profesión lo que si que he visto es que se ha ido modificando la tarea del programador.

En aquella época lo que se hacían eran Webs, lo que hoy serían portales. Se hacían a medida. Hoy día existen multitud de herramientas, tanto gratuitas como de pago que te permiten montar un portal en un periquete, con muchísima funcionalidad. Tres cuartos de lo mismo ocurre con el tema del comercio electrónico, etc.

Esto hace que se empiecen a necesitar menos programadores y más parametrizadores de paquetes.

También hace que se empieze a necesitar más profesionales de integración de diferentes paquetes.

Es cierto que cada vez el desarrollo es más de producto y de nicho.

De producto porque alguien tiene que desarrollar esos gestores de portales, por ejemplo. Es decir se ha ido pasando del traje a medida al traje estándar. Por dos motivos. Porque el traje a medida es muy caro y tampoco hay tantos sastres buenos para tanto traje y porque al final todos tenemos un cuerpo más o menos a medida.

De nicho porque siempre habrá alguien que tenga una necesidad no cubierta por paquetes estándar.

También dentro de la programación hay un cambio ya que cada vez existen más librerías o herramientas que te ayudan a construir tu aplicación. Por ejemplo hay multitud de librerías para el acceso a datos, que hace 15 años no existían.

Es decir hasta en la programación cada vez se necesita tirar menos líneas de código y más el conocer librerías y sus peculiaridades.

Las pruebas de cobertura son una herramienta útil para poder bucear en nuestro código. Supongamos que disponemos de una aplicación desarrollada que vamos a probar, bien de forma automatizada bien de forma manual.

Nos pueden surgir dos dudas. ¿Hemos probado todos los casos posibles? o bien ¿Existe código muerto, es decir que no se usa nunca?

Para ayudarnos a despejar estas dos dudas existen herramientas que nos permiten hacer pruebas de cobertura. Es decir, en el caso de Java, ponen la máquina virtual en un modo que va indicando que líneas de código va ejecutando. Con esa información podemos saber si hay alguna línea de código por la que no se ha pasado nunca y averiguar si es que nuestro juego de ensayo no es suficientemente exhaustivo o por el contrario hay código muerto, que sobra.

Dentro de las herramientas gratuitas para Java la más popular es JaCoCo, aunque existen otras que están descontinuadas o con muy poco soporte.

Hace tiempo trabajé en una empresa en la que era la punta de lanza en cuanto a tecnología de desarrollo de Web con Java.

Un jefe que tuve me solía decir que para coger cosas nuevas tenia que dejar parte de las que ya tenia, porque sino no iba a poder.

Es decir, si eres el que sabe de un tema (tecnología, producto,…) y no traspasas ese conocimiento a otra persona, todas las dudas o necesidades que existan sobre ese tema vas a tener que atenderlas tu y eso te va a quitar tiempo para poder coger nuevos conocimientos sobre otros temas.

No me parece un mal planteamiento, siempre y cuando tengas claro que ese traspasar conocimiento es porque efectivamente vas a coger otro nuevo y no para que puedan prescindir de ti.

En aquellos tiempos de principios del 2000 el desarrollo de web con Java era una materia relativamente abarcable por una persona. Hoy día no lo es. Ha crecido mucho y se hace complicado el poder mantener un nivel, ya no alto sino aceptable en tantas áreas.

En aquellos inicios del 2000 básicamente podías desarrollar en el modelo 1 o modelo 2, es decir hacías una jsp con todo o la jsp solo tenia le presentación y la lógica de negocio la implementabas en un servlet.

Actualmente hay multitud de frameworks, incluso alguno son diferentes sabores.

Hoy día tienes que renunciar conscientemente a ser un experto en ciertos temas para poder mantener un nivel aceptable en otros, sino caes en el riesgo de no saber de nada.

Cuando diseñas una infraestructura para industrializar el desarrollo de software hay que tener en cuenta las diferencias entre el entorno de desarrollo y el entorno de integración. En ambos quieres compilar y probar el software, pero los requisitos son diferentes.

En el entorno de desarrollo, donde están trabajando los desarrolladores es muy importante el tiempo. Es decir hay que ser muy ágil en el ciclo de hacer una modificación y se probarla. La falta de agilidad hace que se pierda mucho tiempo en un ciclo de modificación y prueba que se realiza muchas veces a lo largo del día.

En cambio en el entorno de integración, en el que el compilar y probar se va a realizar una vez que la modificación ya se ha dado por terminada, no es tan crítico el tiempo, obviamente dentro de un orden.

Es en este entorno de integración en el que podemos invertir más tiempo en realizar más comprobaciones.

Ya en la carrera, y de esto hace algún tiempo, de hecho soy de la última promoción de licenciados en informática, cuando no estaba tan en boga términos como integración continua, ya nos decían que cuanto más tarde se encuentren los fallos más caro cuesta arreglarlo. Es lo que también se conoce como deuda técnica.

Ha llovido bastante desde entonces y hoy día tenemos herramientas y técnicas para poder abordar la detección de los problemas de forma temprana. Pero muchas veces seguimos con la mentalidad de que hay que llegar a las fechas a toda costa. Y ese a toda costa suele ser dejar cadáveres por el camino. Cadáveres que como andamos con prisas no enterramos bien y más pronto que tarde se levantan de sus tumbas para exigirnos cuentas.

Creo que uno de los elementos que hacen más por estos temas de bajar la deuda técnica es la rigurosidad de nuestro cliente. Si el cliente es riguroso en sus controles de calidad, sabes que los cadáveres que dejes van a resucitar, así que procuras no dejarlos. Si el cliente no es exigente, es cuando más cadáveres suele haber, porque como nadie mira… hasta que algo peta y miran, claro.

Hoy día es relativamente sencillo el disponer de una herramienta como Jenkins o similares para realizar la integración continua. Esto nos ayuda a asegurarnos que lo que tenemos en el repositorio cumple con los criterios de calidad y si no lo hacen detectarlo cuanto antes, para que se solucione de inmediato, y a ser posible por la persona que ha roto la integración.

He estado en proyectos relativamente grandes en los que prácticamente era imposible bajarse el código y que este compilase a la primera. Pero les costaba ver que poniendo una herramienta de integración continua podían reducir el tiempo que alguien desperdiciaba cuando se tenia que bajar el código para realizar un cambio. El problema es que esos tiempos nunca se computan en las herramientas de seguimiento como tiempos improductivos. ¿Cuanto tiempo nos pasamos esperando a la máquina? Es decir sin generar valor a nuestros clientes…

Me parece que como tope la integración debe ser diaria, y si es constante mucho mejor, sobre todo con herramientas como git que facilitan el realizar commits atómicos.