jueves, octubre 17, 2013

Creación de aplicaciones empresariales

Muchas veces, los profesionales que se dedican al desarrollo software nos encontramos con que no se comprende nuestro trabajo, no se nos valora como nos gustaría,... E incluso se nos llega a decir que eso también lo hace un amigo de alguien, que esta todavía en secundaria.
Queda claro entonces que no se sabe muy bien que hacemos en nuestro trabajo, como lo hacemos, ni el sin fin de decisiones que debemos tomar por el camino. Pero ¿qué diferencia un desarrollo de software "profesional" de uno "de chapucillas"?

Cuando digo "chapucillas", me refiero a un aficionado que ha aprendido cosas sueltas, que no tiene una formación o equipo humano en el que apoyarse. No confundir con los proyectos de código abierto, ya que muchos de ellos están gestionados de forma profesional.

Me he permitido recopilar algunas de las diferencias más importantes que hay o debería haber:
  • de proceso de creación 
  • de características del producto 
  • de mantenimiento
De creación
Aquellas características propias del proceso de creación del software, metodológicas, de entorno, de gente,...
  • Código mantenible y fácil de entender. Como veremos en la descripción de muchas características, la etapa de vida más larga del software de empresa es el de mantenimiento, por lo que se suele intentar hacer cosas sencillas y fáciles de parametrizar. Por el contrario, uno en casa puede dar con una idea feliz y llevarla a la práctica, pero luego le costará entender y modificar dentro de un tiempo.
  • Equipos de más de una persona. Son raros los proyectos software en una empresa que haya realizado durante todo su ciclo de vida sólo una persona. Lo cual obliga a negociaciones, a veces puede frenarse el proceso,... Pero lo más probable es que el desarrollo evolucione más rápido, sea más compartimentado o modular,...
     
    Equipo de trabajo
    Equipo de trabajo

    Trabajo en casa
    Trabajo en casa
  • Gestión de versiones. Al desarrollar varias personas, y durante un tiempo, hay que resolver 2 problemas: sincronización / mezcla de código y repositorio fiel del que hacer copias de respaldo. Cada vez está más extendido el empleo de control de versiones en todos los entornos de creación de software, tanto profesional como aficionado, gracias al éxito de webs como sourceforge o github.
    Versionado de código
    Versionado de código
  • Gestión de dependencias. Dado que desde el principio suele haber más de un desarrollador, y que no se sabe a ciencia cierta donde acabará ejecutándose nuestra aplicación, es más probable que haya algún tipo de gestión de configuración, tanto del entorno de desarrollo como del esperado entorno de ejecución. Y más concretamente de las bibliotecas necesarias para compilar y ejecutar. También de los parámetros, servidores / servicios mínimos necesarios,
  • Reutilización. Ya sea por las prisas, o porque se hagan proyectos muy similares en la empresa, o porque alguien ya realizó algo parecido, es muy habitual un alto grado de reutilización. Aunque en algunos casos sea tan burdo y peligroso como copiar-pegar trozos de código, en lugar de referenciar código reutilizable, catalogado y mantenido, como a todos nos gustaría. Aunque los aficionados cada vez reutilizan mas, gracias a la web y lugares como stackoverflow, enseguida tienden a rehacerlo todo para que sea mejor y más a su gusto, a la menor diferencia detectada.
  • Código / características compatibles. A veces motivado porque en el entorno de producción hay versiones antiguas de los productos (también conocidas como versiones estables), u otras porque no nos queremos casar con un proveedor, u otras porque no hemos reciclado la formación en años, se tiende a emplear productos o características más estables / probados / antiguos. En nuestra casa, enseguida tendemos a querer emplear lo último de lo último, o a ponernos a usar bibliotecas, entornos de desarrollo o ejecución que todavía no han llegado a tener una versión estable.
  • Código portable de máquina. Para aplicaciones empotradas o que puedan ejecutarse en entornos variopintos de CPU, memoria, disco,... Es esencial hacer que la mayor cantidad de código sea común y funcione en las mas diversas circunstancias. Por ejemplo, que el mismo código fuente compile para 32 bits y para 64 bits, como puede pasar ahora con el software de iPhone 5s, respecto de anteriores.
  • Capa de abstracción de hardware. Principalmente en la industria del software empotrado, se trabaja con diseños que pueden evolucionar con el tiempo (aunque sea tan breve como el tiempo de creación del producto), o que pueden variar por diferentes entornos donde van a funcionar. En tales casos, la famosa capa HAL (Hardware abstraction Layer) se suele emplear, poniendo todo el código dependiente del hardware en dicho módulo o capa, y publicando hacia arriba una Interfaz mas estable.
    Capa HAL en Android
    Capa HAL en Android
  • Orientado al mantenimiento. En varias ocasiones se ha mencionado el mantenimiento, y es que el periodo mas largo dentro del ciclo de vida de una aplicación empresarial será el mantenimiento. Las empresas no adquieren un producto que no vaya a tener soporte durante varios años. En diferentes instalaciones pueden hacer falta pequeños retoques de la aplicación para su despliegue... Todo esto sin mencionar las mejoras que se vayan pensando para la solución informática.
  • Estado anímico del equipo de desarrollo. Como todos nos podemos imaginar, no es lo mismo desarrollar un sistema por un sueldo, que hacerlo por aprender, o para practicar, o por cualquier otro motivo personal. No pondremos el mismo interés, ni ganas, por lo que echar unas horas mas no nos sentará igual, la productividad tampoco sera la misma.
    Volviéndose uno loco
    Volviéndose uno loco
  • Entregas parciales, orientadas a demostraciones. A nivel empresarial es muy habitual tener que enseñar el progreso de un proyecto a un jefe o al cliente. Por ello, siempre hay mas presión para tener cosas en un estado mostrable, aunque por detrás sea puro cartón piedra. Y esto es independiente del modelo de ciclo de vida que se lleve a cabo en la empresa, ni que sea una metodología ágil u orientada al prototipo. Es ley de vida, hay que tener algo que enseñar para mostrar nuestro progreso. En muchos proyectos abiertos, es muy común leer aquello de "estará cuando tenga que estar", pero a todos los externos al proyecto nos pone de los nervios.
  • Entorno de desarrollo bien definido. Dado que puede haber varios desarrolladores, casi desde el principio hay que estandarizar y documentar la creación del entorno de desarrollo, no solo el IDE, sino bibliotecas necesarias, posibles claves de servidores, parámetros de configuración,...
    IDE en todo su esplendor
    IDE en todo su esplendor
Del producto
Aquellas características que tienen que ver con el producto resultante del proceso.
  • Internacionalizacion. Es raro que un producto vaya a funcionar solo en un idioma, salvo que sea un producto a medida que solo va a funcionar en unas instalaciones. En los demás casos, aunque sea solo a nivel de demostración, suele estar preparado para añadir algún otro idioma ( al menos, en nuestro caso, el inglés). Y añadir idiomas es muy sencillo cuando en la arquitectura interna de la aplicación se ha tenido en cuenta esta posibilidad. 
     
  • Localizacion. Relacionado con el punto anterior, pero muy diferente, y mucho menos habitual. Consistente en adaptaciones locales mas variadas como escritura de izquierda a derecha o viceversa, vertical, el símbolo del decimal, formato de fecha,... Se suele confiar todo en el sistema operativo y bibliotecas intermedias, lo que lleva a que falle mas a menudo. Solo cuando es un paquete software o servicio orientado a clientes varios, es cuando se trata este asunto de verdad. Cuando el desarrollo es casero, se minimiza este aspecto, por desconocimiento o por dificultad de acceso a sistemas diferentes.
  • Trazas. Dependiendo de si es software empotrable, o con alta concurrencia, o de ejecución remota, la importancia de unas buenas trazas o log, bien definidas, puede ser capital. Y esto lo han manejado los desarrolladores en empresa ya desde hace muchos años, incluso con mayor importancia que la depuración con un debugger. Son esenciales para un análisis post-mortem de lo que ha podido ir mal en la aplicación.
  • Monitorizable. Ya no hay empresa que no tenga algún sistema de monitorizacion de sus maquinas y aplicaciones principales, desde un básico ocupacion de memoria y Cpu, hasta métricas mas específicas de cada caso. Por ello es tan importante tener incluido en la arquitectura de la aplicación servicios y recopiladores de información, orientados a otros sistemas de recopilación automáticos. Solo como último caso, se simularía un usuario que entra en la aplicación para obtener la información que nos interesa, siendo fuentes de problema con cada cambio de interfaz.
  • Adaptable a imagen del cliente. Tiene que estar preparado por arquitectura para adaptarse a la imagen del cliente (cambios de logo, colores y textos corporativos,...). Si se tuvo en cuenta desde el principio esta posibilidad, la mayoría de adaptaciones serán muy sencillas e, incluso, sin necesidad de implicar al equipo de desarrollo, pudiendo crear paquetes independientes de personalización. Incluso, en algunos casos, cada instalación dentro del mismo cliente puede tener algún elemento de imagen diferente para evitar errores y acciones a la ligera. Por ejemplo, el entorno de pruebas con fondo rojo chillón y el de producción de color corporativo.
  • Adaptable a los servidores del cliente. Estar preparado para funcionar con diferentes motores de bases de datos, o variantes de sistema operativo, sin tocar o solo con pequeños retoques localizados. Para funcionar con unos servidores u otros (hard y soft),...
  • Exportar interfaces. Cada vez menos las aplicaciones funcionan en una isla. Es raro que no tengan que dar acceso al gestor de lanzamiento de tareas programadas o nocturnas, o para que una aplicación recolectora de datos pueda hacer estadísticas, o para que otra pueda acceder a algún dato / pantalla, integrandose en la ejecución,... Suelen seguir algún estándar, más por reutilizar bibliotecas o herramientas que por convicción, como SOAP, RPC, JMI,...
  • Integración con servidores LDAP. Mención especial merece la posible integración con un servidor de directorio corporativo, compatible LDAP, e incluso compatible Directorio Activo de Microsoft. Rara es la empresa que no tenga hoy en día algún tipo de unificación de usuarios y gestion de permisos, por lo que la aplicación deberá venir adaptable a ello, ya que compatible con todo, de fabrica, es imposible, porque aunque LDAP es una cosa, cada uno la usa en su casa como quiere ;-)  Y con especial énfasis en la gestión de diferentes permisos a lo largo de toda la funcionalidad de la aplicación.
    Árbol LDAP
    Árbol LDAP
  • Escalable. Ya no solo para dar mejor rendimiento, sino que mas por evitar al máximo los tiempos de caída de servicio, las aplicaciones deben permitir el crecimiento mediante algún tipo de concurrencia. Clusters de varios nodos activos / pasivos, mas nodos de computación paralelos, posibles instalaciones remotas con sincronizaciones, algo en la nube ( que ahora vende mucho),...
    Servidores a go-go
    Servidores a go-go
Del mantenimiento
  • Periodo largo. Una empresa, tras invertir en una aplicación, licencias, servidores, formación, adaptaciones,... espera que el sistema ea productivo durante varios años y, en el peor de los casos, que tenga vías de migración a futuros / otros sistemas. De ahí que el mantenimiento de las aplicaciones se vuelva el periodo mas largo, con diferencia, de una aplicación. Por aburrido que pudiera ser, el soporte es necesario, y uno de los puntos mas estudiados a la hora de adquirir software
  • Responsabilidad a la hora de corregir errores. Muy ligado con el punto anterior, continuamente se están gestionando incidencias de la aplicacion. Un aficionado preferiría añadir nueva y fascinante funcionalidad, pero la realidad empresarial es que hay siempre errores que corregir, y el cliente esperará un grado de resolucion de errores e incidencias alto y rápido
    KDE Bugtracking
    KDE Bugtracking
  • Más adaptaciones. Por muchas pruebas que se hubieran hecho, por mas entornos que se hubieran previsto, seguiran surgiendo arquitecturas o instalaciones con peculiaridades. Si hicimos bien nuestro trabajo al definir la arquitectura, las modificaciones serán fácilmente absorbibles.
  • Varios entornos. Incluso en el caso de que solo hubiera un cliente o instalacion en producción, habrá al menos otros 2 entornos importantes: desarrollo, que ser donde los programadores van probando nuevas versiones recién codificadas y preproducción o calidad, donde se probará, en un entorno lo más parecido posible a producción, el método de instalación ,su comportamiento general,...
  • No lo instala el autor. Dado que es un trabajo en equipo, es lógico que uno no haga todo. Incluso, aunque el autor estuviera en las mismas instalaciones donde luego va a estar ejecutándose la aplicacion, la gente que gestiona los ordenadores personales y los servidores preferirán ser ellos quienes lo instalen , para asegurarse de que sigue sus criterios de seguridad, instalación, de compatibilidad para los backup,...
  • Procedimiento de entrega. Tras cada cerrado de versión, antes de pasar a producción, habrá un procedimiento más o menos definido que incluirá, entre otras cosas: creación de registro de cambios, pruebas de lo nuevo, pruebas de regresión para comprobar que no se haya roto algo importante que antes funcionaba, procedimiento para pase a preproducción y procedimiento para pase a producción.

En resumen
Como hemos visto, hay multitud de elementos que caracterizan un desarrollo software a nivel empresarial. La mayoría no suelen estar presentes en los desarrollos de "adolescentes novatos" pero otros se han vuelto cool, y han entrado con fuerza en este mundo más aficionado como la gestión de versiones con git.
Independientemente de un ciclo de vida elegido,o de lo escrupulosa que sea una empresa, cumplirá o tendrá presentes muchos de los puntos aquí expuestos. Para los demás, espero que les haya servido para coger ideas para mejorar en su producción y gestión. 

NOTA: dado el tipo de artículo, la mayoría de imágenes aquí mostradas provienen de otras fuentes. Si crees que alguna no debería aparecer, no dudes en avisarme.

No hay comentarios: