Una idea y un sueño.
En algún punto de 2021 o 2022 (ya no importa mucho), un pequeño grupo de estudiantes de INACAP decidimos crear una plataforma para que los estudiantes pudieran ayudarse entre sí. La idea era simple: compartir contribuciones, documentos escritos por los mismos estudiantes, explicando la materia de la manera en que ellos la entendían.
El desafío era claro: teníamos que diseñar la aplicación web desde cero y lanzar algo funcional (ojalá) antes de fin de año. Empezamos directamente con el back-end, y de esta forma fuimos modelando el front-end, según como modelábamos el back-end, las ideas para el front-end aparecían fácilmente…
PHP: La vieja confiable.
En ese momento, PHP era lo que sabíamos. No había mucho que discutir. ¿Django, Flask, Express-JS? Existían, si. Pero los estábamos aprendiendo, y PHP… bueno, lo conocíamos. Pero en un nivel básico, muy básico.
PHP puro: no usamos ningún framework. NADA. Ni Laravel, ni Symfony, ni nada. Solo PHP y «a la antigua». Recuerdo algo de las palabras de nuestro “jefe” de proyecto, que en aquel entonces se rehusaba a escuchar a los desarrolladores que, como yo, queríamos poner en práctica Django, que era lo que estaban enseñando en clases:
“Vamos a aprender en base al sufrimiento. Aprenderemos mucho.”
La primera gran decisión errónea fue el controlador para la base de datos. Elegimos MYSQLi. ¿Por qué? Porque sabíamos muy poco de PDO, y nadie se quejó en el entorno de desarrollo. Un par de meses después, ya con un prototipo del proyecto en un servidor de staging ABIERTO AL INTERNET (mala idea), tuvimos el primer gran desastre.
Nuestro «jefe» nunca revisó la configuración de aquel servidor, y nunca supimos que este controlador no estaba instalado… y ahí estábamos, con un error fatal en pantalla. ¿Lo peor? El error mostraba detalles de la base de datos al público.
«Algunas personas se rieron; algunas personas lloraron. La mayoría de la gente estaba en silencio.»
¿Patrones, estructuración y buenas prácticas? Nuh-uh…
Lo peor vino después. Nuestro código se convirtió en un laberinto de archivos PHP llamados sql_conn.php, sql_users.php y cosas similares, donde las consultas a la base de datos se mezclaban con la lógica de la aplicación.
Las consultas a la base de datos eran hechas directamente desde archivos PHP. Cada acción CRUD se manejaba directamente con consultas SQL: SELECTs, UPDATEs, INSERTs y DELETEs, sin procedimientos almacenados, sin nada que ayudara a estructurar o encapsular la lógica. Esto atormentaba al equipo cada vez que algo se debía arreglar o agregar; fue tanto el trauma ocasionado que se dice que esta fue una de las razones principales del porqué muchas características quedaron sin hacer:
- Comentarios
- Sistema de puntuación
- Listas de lecturas
- Entre otros, como la famosa promesa de un «Sistema de reportes y analítica» (que solo quedo en un pequeño sistema de contador de visitas)
La otra razón principal, el tiempo. Yo y el líder del proyecto y yo teníamos el tiempo para ver qué hacer; inclusive, nosotros dos fuimos los principales redactores de documentos. Yo en la asignatura Programación Back-End y nuestro dictador en Aplicaciones móviles e IoT.
El tiempo a los demás les quitaba la participación en el proyecto, muchas líneas de código quedaron al pendiente de una refactorización, de hecho, este es un fragmento de código que aún nos persigue a todos:
La función más larga del sistema de esta índole era parte del sistema de usuarios y controlaba las verificaciones de correo.
La moraleja de la terrible historia de El Cariñoso Equipo de KnowNode…
Fueron tiempos oscuros, y digo fueron porque las cosas dentro de ese equipo no existen más. El grupo se disolvió y el proyecto paso a mis manos, y yo como buen estudiante me dedique a reconstruirlo en un framework, como dios manda.
Ahora, KnowNode corre bajo Django, con una estructura mucho más limpia y eficiente. Lo que antes era un caos escrito en PHP, ahora es un sistema sólido, organizado y orgásmico.
En INACAP nos enseñaban Django mientras desarrollábamos KnowNode en PHP, y en aquel entonces no lo entendía y se me hacía muy difícil tocarlo y experimentar. Ahora me considero un maestro, sigo los patrones y mejores prácticas. De hecho, me enamoré de una de sus filosofías: «Big ass models, thin views».
De hecho, me gustaría volver a tocarlo; he aprendido mucho de Django y me gustaría aplicar ese conocimiento.
¿Qué aprendí de todo esto? Si pudiera resumirlo en una frase, sería:
“Haz las cosas de la manera difícil para entender cómo funcionan. Luego, hazlas bien, como se deben hacer.”
Con esta experiencia aprendí muchas cosas:
- Modelado de base de datos.
- Administración de base de datos.
- Motores de bases de datos (InnoDB, MariaDB)
- Uso de WordPress y conceptos básicos (KnowNode tenía un blog)
- Dominios: DNS, subdominios, etc…
Y hay otras cosas que ahora mismo no recuerdo, pero cuando las necesito, resurgen de algún rincón de mi mente, trayendo consigo una oleada de nostalgia… esa nostalgia que solo KnowNode y PHP pueden provocar.
El Cariñoso Equipo
Nos hacíamos llamar «El Cariñoso Equipo», teníamos este patrón. Cada vez que teníamos alguna idea, le poníamos al final «de <proyecto>». Así, cuando KnowNode apareció, nos llamamos «El Cariñoso Equipo de KnowNode».
Hoy ese equipo está completamente disuelto. Ciertas cualidades nos separaron. Una de las más tóxicas fue la mentalidad:
«Si funciona, no lo toques»
Frase que está bien, cuando lo que creaste está bien hecho. No cuándo:
- No sabes cómo lo hace.
- No te agrada el cómo lo hace.
- Tocarlo supone que algo fallara.
- No poder compartirlo con otros por miedo a la crítica.
Este post lo redacté para hacer memoria de lo que hicimos, lo bien que lo pasamos y lo mucho que aprendimos.