Otra forma de programar: más martillos para otros clavos

Hace unas semanas terminamos una aplicación programada en PHP… pero nada de `espagueti code´, PHP del bueno. Con nuestro MVC (modelo-vista-controlador), utilizando Composer para gestionar las dependencias, Doctrine para la capa de persistencia, Smarty para las plantillas, JSON y por supuesto con programación orientada a objetos, con sus clases, instancias y demás. Seguro que mi admirado Esteban Guerrero –El sabio– estaría muy orgulloso de nosotros.

Fue todo un reto del que El Guerrero de la Carretera consiguió salir victorioso y con el que sobre todo hemos aprendido un montón… dando el salto a Java ahora entendemos mejor frameworks tipo Spring, con su inversión de dependencia, su Hibernate, Maven y demás. Pero confieso que una vez superada la euforia de ver terminada la tarea me queda la sensación de que para nosotros esta forma de programar `de libro´ no siempre nos va a merecer la pena:

  1. Para empezar, para lo que nosotros estamos acostumbrados, hemos tardado una cantidad obscena de tiempo programando esta aplicación y no sólo porque muchas cosas eran nuevas, es que programar así lleva muchísimo más trabajo. Sólo para hacer un formulario que almacene datos en una tabla ¡madre mía la que tienes que montar!.
  2. Con tanta abstracción y abstracción de la abstracción… uno se siente como si estuviera colocando los alimentos por orden alfabético en el frigorífico: aquí los Puerros, a lado de las Peras junto al  Pan de molde… uhmm, ¿pan de Molde?, ¿sería más correcto ponerlo junto con la Mayonesa y el Maíz?. Reconozco que al final consigues un conocimiento más profundo de la esencia tu aplicación, de como fluyen los datos de una lado para otro, de la lógica de negocio… pero da miedo cuando te ves a ti mismo filosofando sobre si un método sería mejor dividirlo en dos partes o moverlo a otra clase, te adentras peligrosamente en el terreno de la `paja mental´
  3. Es una forma de trabajar que la veo más propia de equipos multidisciplinares, donde hay una persona que se ocupa de la base de datos, otras que programa el controlador, otra que se ocupa de las plantillas, otra que hace el testing… Pero en nuestro caso, rara es la aplicación en la que terminamos interviniendo más de tres personas distintas, lo más normal es que trabajemos sólo dos en `pair programming´. Así que cuando estás recopilando todos los datos que le vas a lanzar a la plantilla TPL para que pueda hacer su trabajo, uno tiene la sensación de estar tirando una pelota al aire para volverla a recoger tu mismo.
  4. Esta claro que terminas creando algo que cualquier persona que domine las técnicas que has empleado podría entender y meterle mano con rapidez y solvencia. En última instancia puede que ese sea el objetivo, que incluso otra empresa pueda llevar sin problemas el mantenimiento de una aplicación que ha desarrollado tu empresa y  que a ti sólo te tengan que llamar para realizar evolutivos o puede que ni para eso. Pero en nuestro caso, tanto los mantenimientos como los evolutivos los hacemos nosotros…. y muchas de las aplicaciones que desarrollamos  están pensadas para cumplir su cometido durante un periodo reducido de tiempo de 2 ó 3 años.
  5. Sientes que estás perdiendo el control de tu aplicación, ya que le has tenido que meter a tu app tropecientos ficheros para que funcione Doctrine, otros tropecientos para las Smartys… y la realidad es que no tienes ni idea de lo que tienen dentro. Desde luego que es maravilloso eso de ver que tu aplicación está cacheándose ella solita para funcionar más rápido, hasta que te da por preguntarte ¿y eso cómo lo hará? ¿que SQL estará ejecutando Doctrine? ¿estará utilizando bien todos los índices o estará haciendo alguna chapuza por debajo?
  6. A veces sientes que te obligan a aprender formas nuevas de hacer exactamente lo mismo. Vale que un LOOP o un FOR no sean exactamente iguales en PHP, Visual Basic, Java o C#… ¿¡pero en serio que ahora tengo que aprender como se hacen en un TPL?!, con lo que me costó aprender SQL con sus INNER JOINS, sus HAVING, sus USE INDEX… ¿¡ahora tengo que aprender a hacer lo mismo en ORM!?. Soy consciente de que gracias a todas estas maravillas mañana en dos patadas puedo decidir migrar la base de datos de mi aplicación de MySQL a Oracle o a PostgreSQL, pero sinceramente eso no va a pasar.
  7. WTF!!!… No estoy plenamente seguro de querer seguir viviendo en un Mundo en el que alguien es capaz de escribir cosas como ésta sin ser arrestado de inmediato: “in order to do a hello world, you must first create a hello world service to create the hello world factory to create the hello world service so you can print hello world on the screen.“… sigue leyendo en You Have Ruined Javascript (no te pierdas los comentarios de la entrada, pueden servir de réplica a todas las sandeces que yo mismo he podido haber escrito en esta entrada)

En definitiva, hemos adquirido un montón de nuevos conocimientos que pasan a formar parte de nuestra caja de herramientas… pero ahora toca hacer un reflexión y ver exactamente con qué nos vamos a quedar para el día a día, y que otras habilidades van a quedar reservadas para ocasiones especiales.

2 opiniones en “Otra forma de programar: más martillos para otros clavos”

  1. Mi opinión es que el uso de esas tecnologías para proyectos cerrados o casi cerrados y muy bien definidos está muy bien, creo que al final llega a facilitarte trabajo, ahora bien los desarrollos que dia si o dia también necesitan de alguna pequeña modificación sobre todo a nivel de datos creo que es mejor no depender tanto de estas tecnologías, tienes tu mismo el control de la aplicación, y como bien dijiste en otro post. “Vives en un mundo creado por mi” (un excelente post).

    1. Proyectos cerrados y muy bien definidos… yo creo que eso no existe y mucho menos en nuestro mundo que como bien sabes es más en plan “acabalo todo pronto para poder cambiarlo de cabo a rabo cuanto antes”

Comentarios cerrados.