Categoría: Arquitectura aplicaciones

En una ocasión me encargaron un proyecto, no muy grande. Era un equipo de dos programadores más el jefe, pero como este no tenia conocimientos de tecnología Java entre yo como especialista.

Así que monté el proyecto con una visión más a largo plazo de lo que se suele hacer.

Sabía que íbamos a tener que entregar el diagrama lógico y físico de la base de datos, así que en vez de hacer las modificaciones de las tablas directamente en la base de datos y al final del proyecto documentar utilizamos una herramienta de modelado de datos para hacer los cambios, generar el script y rehacer la base de datos con ese script. Cuando tuvimos que hacer la instalación en el cliente ya teníamos el script hecho y perfectamente validado. Cuando tuvimos que entregar la documentación de la base de datos, también ya la teníamos y perfectamente actualizada.

Para la gestión de las tareas en vez del típico excel o emails utilizamos un gestor de tickets, que nos permitió tener muy controlado todo el trabajo que se iba realizando y el pendiente de realizar.

La lección que sacamos de esa experiencia es que si dedicas un poco de tiempo al principio del proyecto a construir unos pilares sólidos al final del proyecto te dan sus beneficios. El proyecto no se desvió por esos motivos, si por otros.

Fueron medidas sencillas de aplicar con un muy buen resultado. El problema es que a veces la gente se obsesiona con el «si hacemos esto mejoraríamos a largo plazo» y acaba cayendo en la sobreingeniería. Que es tan mala o incluso peor que el hacer las cosas chapuceramente.

Ú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.

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.

Hoy quiero hablar un poco de arquitectura de aplicaciones, concretamente de la distribución de información entre diferentes partes de la aplicación.

Si estamos diseñando la arquitectura de una aplicación en la que hay un intercambio de información entre componentes distribuidos muy alta, a diferencia de cuando el intercambio es bajo, hemos de buscar un método de ser muy eficientes, ya que una pequeña mejora nos puede suponer un gran beneficio. Esta situación se agrava si las comunicaciones no son muy fiables.

En el mundo Java, una de las primeras opciones que tenemos es la de serializar los objetos para poder transmitirlos. La serialización es un mecanismo que está implementado en el lenguaje desde hace mucho tiempo. El principal problema es que estás limitado al lenguaje Java y que si hay cambios en la definición de los datos, cosa que es casi seguro que suceda, puedes tener complicaciones.

Desde hace bastante tiempo está disponible el uso de XML para realizar ese intercambio de información. El problema con el XML es que da lugar a ficheros muy grandes, ya que están pensados para que puedan ser leídos por una persona. Si tenemos problemas con el ancho de banda, esto puede ser un serio problema.

Posteriormente al surgimiento de XML apareció JSON, que es menos pesado que el XML, pero sigue siendo relativamente grande.

Existe una opción que creo que es interesante. Se llama protocol Buffer y es de Google. Es una forma de transmitir información de una forma eficiente y multilenguaje. Muy interesante para comunicar las «tripas» de las aplicaciones.

Como he comentado alguna vez es interesante seguir a los mejores y a aprovecharse del camino que ellos ya han recorrido.

Otro de los problemas típicos cuando defines una arquitectura para una aplicación web es controlar los botones de ir hacia atrás, hacia adelante o los favoritos.

Hay que tener en cuenta que los navegadores web estaban originalmente pensados para mostrar información básicamente textual, no para hacer aplicaciones con un estado entre página y página. Es por ello cuando haces aplicaciones web los dichosos botones son un fastidio.

Técnicas para resolverlas hay muchas, desde las más peregrinas que utilizaba hace mucho tiempo, de poner un numerito incremental en cada petición y en el servidor comprobar que siempre venia uno superior, hasta soluciones más elaboradas como las que se aplican en el GWT (Google Web Toolkit)

Cuando defines una aplicación web una de las cosas a tener en cuenta es el control del temblor del dedo. Me refiero a los usuarios que pinchan sobre una opción varias veces, porque no están seguros de si han dado bien, o ven que la aplicación no responde y se creen que se no les ha hecho caso. Es lo que yo llamo «el temblor».

Antiguamente cuando no se hacían las aplicaciones AJAX esto se solía controlar de las formas más peregrinas, desde poniendo una capa de bloqueo mientras se procesaba la petición, con lo que se conseguía un doble efecto, eliminabas la posibilidad de pulsación múltiple y además dabas al usuario una indicación de que le habías recibido su petición y estabas trabajando en ella.

Hasta manteniendo un numero incremental por cada petición y controlando en el servidor que siempre te venia un valor superior al que tenias guardado.

Con la generalización de las aplicaciones AJAX esto se puede conseguir de una forma menos manual, ya que se dispone de la posibilidad de bloquear las peticiones hasta que se reciba la respuesta del servidor.

¿Utilizáis alguna otra técnica para controlar «el temblor»?