Hay un proyecto que, a simple vista, creo no muchos tomarían. Sin embargo, no sería nuestra primera vez entrando a un proyecto sin documentación técnica y la posibilidad de muchos problemas internos.
En este caso, por un lado fue peor de lo esperado. Por otro, la poca funcionalidad incluida creo permitirá ir reemplazando el código problemático por alternativas más fáciles de gestionar.
La “plataforma” utilizada originalmente para el proyecto básicamente es un diseño desde cero en PHP de su creador original. Y por motivos que no puedo entender, en vez de utilizar un framework o un CMS reconocido como base, se decidió por una mezcla que resultó en malas practicas como código lasaña y vulnerabilidades fáciles de evitar con solo aprovechar la experiencia de otros proyectos a código abierto. Para efectos de explicar mejor la situación, no había un framework en uso.
Como recrear el sitio desde cero se propuso, pero no fue aceptado, lo que estuve pensando era como ir implementando mejores practicas en mi trabajo. Tal vez no serán Las Mejores Practicas, pero al menos vamos en el camino correcto y si no resultan al final en una mejor plataforma, al menos me hicieron más fácil el trabajo actual.
Lo primero fue tan sencillo como implementar un control de versiones. Un git init, .gitignore, git add y commit después tendría la oportunidad de “forkear” hacia un mejor ambiente de trabajo. Otro git clone después tendría un ambiente de desarrollo separado al ambiente de pruebas para ir mostrando los avances al cliente.
Usando composer pude obtener algunas librerías, también con su propio manejo de versión, para generar PDFs y también adquirí una licencia para un gestor de imágenes. Estos cambios el cliente los podía percibir rápidamente y a través de código probado por muchos y no solo por el propietario.
Donde vino un reto interesante fue en implementar lo que a futuro sería un mejor manejo de lista de control de accesos y gestión de usuarios. Estuve revisando varios proyectos, pero la mayoría requerían adaptarse a un framework u otro. Y justamente framework es lo que no teníamos.
Aquí es donde sobresale una alternativa llamada Nette. Desconocida para mi hasta entonces, prometía ofrecer el control de acceso a través de manejo de usuarios y roles que requería. Una búsqueda en Google me informó que el proyecto es bastante popular y lleva muchos años en desarrollo, lo que me ofreció algo de confianza en que el código ha sido probado. Pero lo que más me llamó la atención fue el énfasis que hace el proyecto en ser modular. La idea es que el framework tiene varios módulos: Seguridad, Unit Testing, Base de Datos, Plantillas, Debugging, entre otras a través de plugins. No tienes que usar el “core” obligatoriamente y puedes de manera independiente acoplar los módulos que necesites.
Para mi proyecto, la idea de poder usar composer y su funcionalidad de autoloading para acoplar la verificación de roles en las páginas a través de este modulo me pareció genial. Al finalizar, pude poner todo a funcionar como necesitaba, aunque no todo fue perfecto.
Una curiosidad de Nette, es que aunque parece ser enormemente popular y tiene una comunidad activa, la misma no parece tener como idioma principal el inglés. La consecuencia de esto es que la documentación existente no es siempre la más completa. Y aunque es cierto que es modular, la documentación se enfoca en el uso de esos módulos dentro de un proyecto que usa el core de Nette.
En mi caso, para poder simplificar el uso de Nette, termine acoplando los modulos de Seguridad, Base de Datos y Cache. Este último porque es utilizado por los dos anteriores. Fue un poco difícil encontrar ejemplos claros de como hacer los llamados a las funciones fuera un proyecto 100% Nette. Eventualmente, pude toparme con algunos Issues en Github de otros desarrolladores en una situación similar a la mía y aunque sus problemas eran distintos, el código y llamados me sirvieron para ir armando todo.
El motivo de querer usar el módulo de Database de Nette fue doble: Por un lado, porque habían ejemplos más claros de como acceder a los datos de usuarios y sus roles y también porque, pensando a futuro, evitaría depender del uso de código espagueti que actualmente abunda en el código original. La idea es que en lo que los proyectos requieran mejorar funcionalidad de un módulo del proyecto actual, ese código lo pueda ir reemplazando por llamados al framework de Nette.
El resultado final, es que la nueva funcionalidad para verificar roles permite, por ejemplo, usar 1 línea de código en vez de 3 a 6, cargando un archivo que dependía exclusivamente de sesiones php, no soportaba cookies y donde era trivial cambiar datos que identificaban al usuario de la sesión a través de parámetros GET. También adicionaba el uso de almacenaje de contraseñas cifradas en vez de las cleartext que habían. Además, pude quitar este código, que afortunadamente estaba “comentado”, pero la idea de que fue escrito para un trabajo de producción (cobrando) de hace un par de años aún me causa tristeza:
Me encantaría saber, aparte de chifear el proyecto (por lo que nos los culparía jamás), que alternativas tomarían ustedes para mejorar las malas practicas, o mejor aún si han utilizado Nette: cuáles han sido y sus experiencias con el framework, ya sea en su uso completo o individual?
