archivo

Archivos diarios: septiembre 28, 2010

Se codifica, se construye la aplicación, pero en demasiadas ocasiones se tiene en cuenta como fin único la entrega del proyecto, dejando al margen o dedicándole menos importancia a una programación pensando en futuros mantenimientos.

La dificultad de los mantenimientos depende de muchos factores y algunos de ellos están por encima en importancia de una codificación clara y de calidad, como por ejemplo la búsqueda de una alta cohesión y un bajo acoplamiento, lo cual no debería ser una excusa para olvidarnos de este asunto ya que no se trata solo de que se pueda comprender lo que se ha programado (que no es poco) sino que un código poco cuidado probablemente influirá en una mayor complejidad ciclomática de la aplicación (además de a la mayoría de las variables que determinan la deuda técnica de la aplicación) dificultando, en consecuencia, a la mantenibilidad.

Generalmente nos solemos acordar de todo esto cuando toca realizar el mantenimiento del sistema de información y nos encontramos con que la forma en que se ha codificado hace que se requiera un mayor esfuerzo y en consecuencia coste. Por este motivo importa y mucho como se codifica.

El problema de todo esto es que resulta complicado detectar este tipo de problemas en tiempo de desarrollo ya que obliga a estar encima y revisar el código, lo que puede hacer que casi cueste más el collar que el perro. Por tanto, tenemos que utilizar otras estrategias que faciliten la localización de estos problemas, como es por ejemplo estudiar variables que se pueden incrementar indirectamente por una mala programación (se puede realizar una revisión periódica de las métricas que devuelve Sonar) y complementarlo, si es posible, con la revisión, también periódica, de una muestra de clases de la aplicación.

Siendo realista, veo complicado que una empresa de desarrollo, salvo que las deficiencias encontradas en el proceso de verificación interno sean serias, se pongan a rehacer a módulos ya codificados, pero por lo menos si se aplican estas políticas se puede reconducir la tendencia en el desarrollo y que el proyecto se encuentre dentro de unos umbrales de calidad aceptables (los cuales en algunos casos podrán ser exigidos y verificados por el cliente y provocar un rechazo en la entrega y la consiguiente necesidad de refactorizar partes de la aplicación lo cual se volverá en contra del proveedor ya que tendrá que sufrir en sus carnes las consecuencias de unas malas prácticas.

Martin Fowler es un importante y reconocido autor especialista en ingeniería del software y en el proceso de desarrollo (particularmente en el campo de la refactorización) el cual ya he tenido la oportunidad de citar en un artículo sobre una regla de CheckStyle que no comprendía su significado.

Steve C. McConnell es otro reputadísimo autor y especialista en ingeniería del software, tanto es así, que durante años fue considerado junto a Linus Torvalds y Bill Gates unas de las personas más influyentes en el negocio del desarrollo de software. En la actualidad posee una empresa llamada Construx Software que se dedica a consultoría y formación sobre buenas prácticas en desarrollo de software.

Ambos autores son responsables de las siguientes citas relacionadas con la comprensión del código:

Martin Fowler (traducción libre): “Cualquiera puede escribir código que un ordenador pueda entender. Los buenos programadores son aquellos que escriben código que los humanos puedan entender”.

Steve McConnell (traducción libre): “El buen código es su mejor documentación. Cuando vayas a escribir un comentario, pregúntate, ¿cómo puedo mejorar el código para que este comentario no sea necesario?”.

Sobre este tema ya publiqué una cita que se atribuye a Martin Golding en unos casos y a John F. Woods en otros que complementa perfectamente a éstas.

Como he comentado en otras ocasiones, hacer las cosas bien, tarde o temprano, marca la diferencia.

Cuando hablo de enfrentamiento no me estoy refiriendo a tener opiniones distintas o que en el transcurso de una reunión o en el contenido de un correo haya una palabra más alta que otra.

El desarrollo de software es un negocio y por tanto detrás de él hay dinero, carreras profesionales, intereses personales, etc… y no se puede esperar que en un entorno como ese todo sea siempre paz y tranquilidad. Este mundillo es así y ese tipo de problemas los terminarás percibiendo de una u otra manera independientemente del puesto que ocupes en tu organización, ya que incluso estando recién incorporado a tu puesto de trabajo y sin experiencia te puede tocar un proyecto con unos plazo de entrega digamos que complicados.

No obstante a los problemas normales de funcionamiento dentro de una organización (plazos, trabajo en equipo, etc…) hay que sumar aquellos derivados de trabajar con el cliente y con sus usuarios.

Habrá proyectos que vayan bien, ¿por qué no?, esos casos existen, pero también habrá otros donde vengan mal dadas, pudiendo ser los motivos de lo más variopinto (mala estimación temporal y/o económica del proyecto, requisitos funcionales cambiantes, equipos improductivos, errores en el proceso de desarrollo, etc…).

Cuando el proyecto vaya mal las posibilidades de choques con el cliente incrementan casi exponencialmente ya que si se llega a este punto quiere decir que el proyecto está en pérdidas o tiene todas las papeletas para estarlo. En estos casos se tratará por parte del proveedor de intentar reenfocar el proyecto de alguna manera con el objeto de que la cuantía de las perdidas no se dispare, pero el cliente, sobre todo si considera que no ha sido el responsable máximo de la situación, tratará de que el proyecto vaya hacia donde cree que debe ir (pudiendo ser este destino y el del proveedor discordantes y en algunos casos, opuestos).

Cuando surge el conflicto hay que evitar el enfrentamiento con el cliente, más tarde cuando finalice el proyecto puedes tomar la decisión (o tu empresa) de no volver a trabajar más con él (antes de tomar una decisión de este tipo hay que valorar lo más objetivamente posible, cuáles han sido los problemas que han existido en el proyecto y la responsabilidad de los mismos), pero un enfrentamiento con un proyecto no finalizado no arregla nada y pone más barreras entre cliente y proveedor que serán motivo de mayores costes. Ante el problema, negociación, mejor una mala negociación que un buen enfrentamiento (en el primer caso por lo menos puedes conseguir algo, en el segundo se llegará a que las cosas vayan a peor).

Los resultados de la negociación deben quedar por escrito y aprobados por las distintas partes que han participado en la misma. Lo mismo una negociación concreta no soluciona los problemas del proyecto, pero nadie dijo que no se pudiera negociar más de una vez cuando los asuntos que se traten sean distintos a los que se hayan negociado anteriormente o bien las circunstancias hayan cambiado.

Que habrá ocasiones en que las cosas no se puedan arreglar por las buenas o por las medios buenas, no lo niego, pero por lo menos es necesario intentarlo.