Mala estructuración y mala comunicación

Días atrás nos pidieron que revisáramos el código de una aplicación en la cual no habíamos participado en su etapa de desarrollo, menos en su etapa de conceptualización, así es que podía pasar cualquier cosa y encontrarnos con un monstruo de n cabezas (eso da miedo cuando se trata de código).

La aplicación en si era bastante grande, lo nuestro era sólo revisar un módulo de ese universo y arreglar todo aquello que estaba fallando, incluso que reescribiéramos todo aquello que nos pareciera complicado y sucio.. así fue que empezamos a revisar, el backend estaba feo, me refiero a feo a… imaginen un libro escrito con diferentes tipos de letras, colores, espacios y saltos de línea dados de manera arbitraria.. código comentado para evitar que se ejecutase y muy pocos comentarios sobre que hacían algunos métodos y algunas rutinas, feo de verdad!! ..

Entendí que ya habían pasado algunos devs metiendo mano y dejando su huella, por lo que el  código era una maraña y ahora en etapa de finalización a todos les daba miedo tocar a que código porque aunque estaba todo desordenado, funcionaba y ya había sido certificado por su funcionalidad.

Nosotros fuimos contratados para arreglar, limpiar y mejorar aquello, así es q el miedo no debía existir, empezamos a modificar capas sobre capas, compilando, portando librerías entre proyectos y documentando con sentido las cosas hasta que logramos terminar..

Sobre el frontend, también era un desastre, aún más terrible de lo que habíamos encontrado en el backend, pues los devs sabían apenas manejar jquery y habían escrito combinaciones de javascript puro mezclado con el jquery, al parecer que quien había iniciado el proyecto había decidido que era buena idea usar librerías de esas que tienen de todo, del tipo devexpress o dhtmlx (hay muchas, esas son las que se me vienen a la cabeza) .. ya saben, mínimamente la aplicación web por cierto debería funcionar en los navegadores modernos, pero también ir bien con el IE8, así es que el CSS era otro problema q debíamos atacar, las reglas y la estructura también era lamentable.

Después de detectar tantos problemas en un mismo proyecto, resolvimos todo al fin, corregimos, probamos y recomendamos como idealmente debieron hacer las cosas, de esto sale un gran aprendizaje para las empresas, no tanto para nosotros.. ya que las empresas generalmente encargan sus aplicaciones a una sola persona a través de sus burocráticos sistemas de arquitectura de personal, esperando que sepan hacerlo todo y lo hagan bien, quizás ese sea el problema, digamos que habían pasado 3 personas por ese proyecto antes de nosotros, cada uno era muy bueno escribiendo código backend, pero tenían muy poca experiencia con el frontend y aún así con cada hack y truco que encontraron el la red, pudieron terminar la aplicación, mantenerla sería otro problema aunque menos complicado después de nosotros medio lográramos organizar ese desorden.

Creo que es triste ver como empresas tan grandes e importantes no tienen personas que realmente quieran hacer bien su trabajo o colaborar entre si, para hacer conjuntamente aplicaciones funcionales y bien estructuradas, la mayoría se preocupan por el puesto, por el horario y porque todo funcione, sin seguir estándares de calidad, piensen en todos los recursos que invierten en mantener esas aplicaciones y todo el tiempo que se pierde por cada vez que alguien quiere agregar algo, simplemente porque contrataron todólogos, no generalizaré, pero se que una gran mayoría de empresas están en esa situación.

Nosotros fuimos alguna vez desordenados, pero como empresa sería de desarrollo, logramos mejorar en cada proyecto en que participamos, hemos metido la pata y hemos aprendido de ello, eso nos hace ser muy buenos y saber contratar a las personas correctas.