¿El desarrollo de software hoy en día es más productivo que hace 10 años atrás?

La primera aplicación que hice en mi vida profesional, fue una típica intranet para una empresa. Todo el código y acceso a la base de datos, se ejecutaba en archivos ASP.
Luego me dijeron que está mal acceder directamente a las tablas de la base de datos desde el código, por lo tanto implemente store procedures para cada uno de los accesos a la base.
Luego me dijeron que está mal mezclar lógica de negocio y de presentación en el mismo archivo, por lo que implemente la lógica de la aplicación en un componente que era llamado por el ASP.
Luego me dijeron que con eso no alcanza, que hay que dividir la lógica de la aplicación en acceso a los datos y en reglas de negocio, por lo que tuve que crear 2 clases para trabajar con una entidad. Una que acceda a los datos y otra que tenga las reglas de negocio.
Luego me dijeron que había que implementar mecanismos de logueo de excepciones, por si ocurre algún error inesperado. Por lo tanto debíamos utilizar algún framework de logging (porque grabar texto en un archivo x DIA, es algo que requiere un framework).
Luego me dijeron que está mal instanciar directamente el framework de logging desde los componentes, que debíamos abstraerlo a una interfaz, por si el DIA de mañana cambiamos de framework.
Luego me dijeron que está mal tener toda la capa de presentación en solo archivo. Hay que usar el patrón MVC y tener un archivo de vista con el código HTML, una clase controller que maneje el flujo y comportamiento y otra clase modelo. Para eso, debería usar algún framework MVC.
Luego me dijeron que los store procedure son obsoletos, que esta mal poner lógica de negocio en la base de datos y que si el DIA de mañana migramos de base de datos vamos a tener problemas, por lo tanto, debería usar algún framework ORM y crear un archivo XML por entidad que mapee las clases con los datos.
Luego me dijeron que está mal subir todo esto directo manualmente a producción, por lo tanto, deberíamos configurar algún mecanismo de integración continua que baje los archivos del repositorio de fuentes, los compile, ejecute los test de integración y los suba a un FTP o los copie a un directorio. Para esto debíamos crear un archivo de compilando en NANT o MSBUILD o similar.
Luego me dijeron que por cada método que tenemos, hay que hacer test unitarios para verificar que algún nuevo cambio, no rompa el código, por lo tanto, hay que crear una nueva clase de testing por cada clase de negocio, usando algún framework de test unitario.
Luego me dijeron que ejecutar pruebas unitarias que accedan a la base de datos esta mal y es muy lento, por lo cual deberíamos utilizar algún framework de mocking que “simule” este comportamiento, por lo tanto, debíamos modificar los constructores de nuestras clases para que acepten inyección de dependencias y debíamos crear una interfaz por cada clase “mockeable”. Sin embargo, debíamos mantener nuestros antiguos test unitarios que accedían a la base que ahora pasan a llamar test de integración, porque necesitamos una prueba integrada con el resto de los componentes del sistema. Entonces por cada método, ahora debemos crear 2 tipos de test, el unitario y el de integración.
Luego me dijeron que no había razón alguna para utilizar “manualmente” inyección de dependencias existiendo frameworks que hagan esta tarea tan difícil y complicada (sic).
Luego me dijeron que autenticar nuestro usuario directamente contra la base de datos o un servidor Active Directory/LDAP es antiguo e inseguro. Ahora hay que utilizar algún mecanismo de autenticación por claims moderno, seguro y ágil. Por lo tanto, debíamos utilizar algún framework de autenticación como WIF.

Para crear un ABM de clientes, pasé de tener un simple archivo ASP (o ASPX, o JSP) a tener que crear un archivo HTML, una clase model, una clase controller, una clase repository de acceso a datos con su respectiva interface, una clase service que maneje la lógica de negocio con su respectiva interface, una clase para test unitarios, otra clase para test de integración, aprender a utilizar (como mínimo y básico) un framework MVC, ORM, de Unit Testing, Mocking, de inyección de Dependencias y de autenticación. También debemos crear varios archivos XML de configuración para los distintos frameworks. Por supuesto no hay que olvidarse que debemos también crear clases e interfaces adicionales para los distintos patrones de diseño existentes que hacen nuestro código más elegante, óptimo, lindo, portable, legible, etc. O sea, más PRO.
Todo para mejorar la productividad y velocidad en el desarrollo de aplicaciones. Todo para que el “desarrollador no pierda tiempo en programar aspectos secundarios de la aplicación y se concentre en lo mas importante, que es la lógica de negocio.”.

No se ustedes, pero a mi este ciclo de evolución del desarrollo de software me parece que esta muy alejado de la palabra “productividad”.



Advertisement