Informarse sobre la infraestructura en que la aplicación dará servicio: software de base, las versiones,S.O., si está en cluster, que tipo de cluster, características de la/s máquina/s, proceso por el cual se valida una aplicación para su puesta en producción, si convivirá con otras aplicaciones,…, en resumen: informarse.
Construir un entorno los más similar posible al entorno que servirá la aplicación, donde desarrollar la aplicación y realizar pruebas de carga en él pues una aplicación para uno no se comporta igual que para 10000, aunque el desarrollador debería saberlo. No se las veces que he escuchado “lleva meses funcionando sin problemas” y que no haya pasado la implantación del despliegue de ficheros por errores en el código o base de datos. Hoy que está tan de moda la virtualización, cualquiera con un equipo actual puede simular una infraestructura más o menos compleja para desarrollar.
Un error es un error, “eso no importa” es una frase que no debería estar dentro del vocabulario de un desarrollador.
Con lo que he comentado se pueden ahorrar hasta dos semanas de adaptación de la aplicación por haberse desarrollado para un entorno diferente del que la servirá finalmente.
Espero que a quien lo lea le sirva para algo aunque venga de alguien que no sabe demasiado de desarrollo pero que al menos una vez leyó sobre Ingeniería de Software
Pues… a ver… repasemos…
Un comercial/preventa/señorconcorbataypalodeescobaenelculo (que no tiene ni idea de programación), le vende una aplicación a un cliente/vocalistadelegadodelcliente/clienteconsorte/cuñadodelcliente (que normalmente no tiene ni idea de programación y a menudo no sabe ni lo que quiere). El comercial le da al jefe técnico una versión de lo que el cliente quiere (la versión de uno que no sabe programar, no lo olvidemos).
Llegados a este punto igual te preguntas por qué no puede ir el técnico a tomar los requisitos. Pues bien, algunas de las teorías existentes al respecto hablan de cosas como corbatas, gominas y escobas en el culo inspiradoras de confianza. Pero otras hablan de ritos arcanos que si se rompen destruirían el orden espacio-temporal y cosas así…
El jefe técnico estima que se tarda en desarrollar la aplicación x horas (sin colchón, porque como le pongas colchón si que no cuela) y así se lo dice al comercial. El comercial, bajo el famoso lema “vende, vende, que luego ya veremos” hace un contrato por una aplicación (que es la versión que le dio al técnico más un número indeterminado de “poyaques”) por x-y (que es que los técnicos ponen unos colchones que no veas…).
El jefe técnico tiene que hacer algo más grande de lo que pensó con menos coste del que estimó (y frecuentemente con requisitos cambiantes en el tiempo, es que la nuestra es una profesión muy bonita). Y como además hay que ahorrar costes, donde el jefe técnico decía analista o programador senior, le ponen monchitos (con muchas ganas de aprender, pero que se pasaron las clases de programación bebiendo litros en el césped del campus. Si es que estudiaron programación, tú sabes…)
Sobre el entorno de desarrollo en la oficina que sea similar al entorno de producción del cliente: el jefe técnico habla con su jefe supremo y se lo pide. Pero es que mire usted, eso lo lleva informática interna y cobra un tanto por hacerlo, más el tiempo de que eso esté disponible (más que me llevo mal con el jefe de informática interna porque me mira mal en el café). Y en fin, este proyecto ya va justo de beneficios y tal. Y que de toda la vida ha estado programando cada uno en su máquina y se han vendido aplicaciones de gran calidad, como todos sabemos, y que a ver a qué ahora ser tan sibaritas. Para eso está el período de pruebas en el cliente, para corregir los pequeños problemas que puedan surgir (ese período son unas dos horas según la planificación que todos pueden ver en el project y los pequeños problemas pueden ser haber desarrollado la aplicación con rutas absolutas para ponérsela a un cliente que para publicar a internet tiene veinte proxies inversos delante…).
Con todo esto, la aplicación llega al cliente sin una sóla prueba (¿cuándo? ¿departamento de calidad?), con todas las pifias posibles de programadores sin experiencia ni supervisión. Porque se me olvida comentar que el jefe técnico lleva este proyecto, pero es que además lidera otros siete proyectos estratégicos, hace i+d en sus ratos libres, defiende que su puesto de trabajo no lo ocuparía mejor el hijo de nosequéjefazo que entró ayer y además, barre la oficina por las noches. Pero no se puede quejar porque tiene a su cargo a doscientos hobbits/monchitos que le sacan el trabajo en tiempos mucho más bajos que los de la competencia.
Y ahora llega el de sistemas (tú y yo) y nos quieren colar un gruyère que no funciona. Pero ojo, no es porque los plazos sean imposibles, ni porque el único analista del proyecto está más quemao que la pipa de fumanchú, ni porque los programadores consideran que eso de comunicarse entre ellos mientras programan sólo puede conducir a herejías de la fé, ni porque el cliente ha cambiado siete veces de requerimientos… no, no funciona porque el Tomcat/Jboss/Linux/Taca… está mal montado porque tú no sabes hacer tú trabajo, o en el mejor de los casos porque el servidor (un opteron de cuatro núcleos con veinte gigas de ram y más megaflops que el último cohete de la NASA) no está bien dimensionado y claro, la aplicación requiere más (es que tiene tres usuarios concurrentes de media y eso es mucha carga).
Opciones que te quedan:
1. Enfurruñarte.
2. Enfurruñarte. Y después, respirar hondo y pedirles amablemente un informe que justifique los consumos de recursos de su aplicación (no te lo van a dar y si te lo dan estará vacío de contenido). Y amablemente, ofrecerles tú mejor máquina como entorno de pruebas, para que veamos todos si la aplicación va bien (esa máquina también está mal dimensionada, que lo sepas a priori). Y presentar un informe de auditoría hecho por ti sobre cómo consume recursos la cosa esa que llaman aplicación (porque lo del garbage collector les sonaba a grupo musical y lo de los hilos a algo de la costura de la abuela).
Y, ¿sabes qué? En cualquiera de los dos casos, la aplicación acabará en tus máquinas, con un montón de pegas y necesitando un grid que toma recursos de las máquinas de toda la oficina para soportar dos usuarios concurrentes en el aplicativo éste tan chuli. Y, ¿sabes por qué? Porque nadie va a reconocer que se ha equivocado y el que menos, el cliente que pagó para que hicieran esa aplicación.
(Pienso que el caso dos es más divertido de todas maneras, ya sabes que yo no soy muy buena persona que digamos)
Moraleja: ¿a qué enfurruñarse? Riéte por dentro, tomatelo con filosofía y pon siempre los medios para que tu trabajo sea irreprochable (porque sí, porque lo valemos, porque podemos) y si los demás quieren ser unos chapuzas… pues mira, ellos allá, ¿no?
Como decía el fuckowsky: ¡qué les den por culo!
Amén