Introducción
La forma en que creamos aplicaciones web ahora es muy diferente del código que nos llegó en busca de soporte desde la antigüedad, cuando Star Factory se mostró en la televisión, estaba de moda caminar con una concha y PHP recién comenzaba a adquirir signos de un lenguaje orientado a objetos. La programación en la década de 2000 me parece una excelente ilustración de las ideas de Darwin: en ese momento, casi cualquier desarrollador creaba sus propias soluciones, algunas de ellas capturaron las mentes de más de una persona, y después de pasar por la selección natural acelerada, los frameworks y CMS se convirtieron en los ejemplos principales de los mejores y más populares métodos de desarrollo. ... En algunos casos, sin embargo, sólo popular, sin la palabra "bueno" o incluso más "el mejor".
Pero a diferencia de los dinosaurios y los mamuts, no todas las soluciones alternativas han quedado en el olvido, especialmente en el backend, y lo sé de primera mano. Tuve la oportunidad de trabajar, no diré con una gran cantidad de legado en php. Algunos de ellos fueron simplemente horribles y algunos de los sitios e incluso el CMS fueron bastante interesantes. A veces me gusta ahondar en lo que nació en la mente de los pioneros. No existía tal estandarización en ese entonces, y aunque la mayoría de las veces es un material excelente para aprender antipatrones, este código me divierte, hace que el trabajo sea similar a la arqueología de TI.
Amado legado
Personalmente, me gusta trabajar con sitios que funcionan en el legado: hacer una edición, eliminar algunas muletas, reducir el nivel de caos y al mismo tiempo no romper todo el sistema. En esos momentos me siento como una persona que hizo este mundo un poco mejor, y es genial.
print " <button onClick='domultimove();' class=controlbutton><img src=syspix/ico32_move.gif border=0><br></button>";
print "<b>" . $ITEM->Description . "</b>:<br>";
$browsebgcolor = "#D9D9D9";
$sql = "select i.ID, m.Name, i.perm, i.descr from item4 i inner join main m on i.ID=m.ElementID";
echo "<script language='JavaScript'> document.location='" . $_SERVER['PHP_SELF']";
Una característica común del legado es un desorden de código escrito en diferentes lenguajes, aunque en el desarrollo moderno, por supuesto, podemos agregar, por ejemplo, código en SQL a clases de PHP. Pero estoy hablando de otra cosa, en el legado a menudo hay una corriente de pensamiento universal del desarrollador: qué y en qué idioma pensó, escribió en una corriente. Quiero hablar sobre una situación similar con una solución de CMS de la vieja escuela con la que he estado trabajando durante algún tiempo. Todo fue tan "maravilloso" que estoy muy contento de haber podido arreglar algo y hacer que el sitio funcione de manera mucho más correcta y rápida.
Entonces, obtuve un sitio web para una gran empresa, escrito en la primera mitad de la década de 2000. En este proyecto, todo se basaba en clases con un método, en el que todo sucedía: trabajar con lógica, mostrar la interfaz (vista) y acceder a la base de datos, además, sql estaba ahí entre los comandos.
print "<table>";No es difícil adivinar que facilité enormemente la vida de los desarrolladores de backend al incorporar primero la salida del diseño a las plantillas. Para esto utilicé el motor de plantillas de ramitas ya hecho y bastante popular. Fue fácil y rápido, así que ni siquiera dediqué mucho tiempo a refactorizarlo. El siguiente paso, en mi opinión, fue hacer algo con consultas a la base de datos, al fin y al cabo, MVC no es en vano tan popular en nuestra web.
Después de mirar Symphony y Laravel, decidí que el enfoque ORM también encajaría perfectamente aquí. Ayudará a realizar el trabajo con la Base de Datos y dejar por el momento que los controladores no trabajen solo con los datos ya recibidos. Es lógico y completamente correcto utilizar las soluciones existentes. Por lo tanto, en primer lugar, me apresuré a empacar para ver qué alternativas tenía además de Doctrine, pero después de pensarlo detenidamente, llegué a la decepcionante conclusión de que no es tan importante. El caso es que este proyecto tenía una estructura de datos bastante inusual. No he visto algo así en ningún otro lugar, aunque trabajé con MODx :) Me enfrenté a un problema: usar ORM populares de código abierto de la manera que quiero no funcionará, bueno, al menos será otra aventura. Entonces decidí crear una bicicleta.
Un poco de lo que hice
Sí, decidí que escribiría un ORM en PHP desde cero (no, bueno, tenía ideas y conceptos tomados del mismo Docktrine) específicamente para este proyecto, para que funcionara con la estructura de datos. Después de todo, este es un sitio de trabajo y nadie estaba listo para asignar los recursos de los programadores para la tarea de "reescribir todo desde cero con una estructura de base de datos normal". Los antepasados que fundaron este CMS crearon 2 tipos de objetos, y uno de ellos también se dividió en "tipos de datos" internos: recursos que tienen fechas, enlaces, diferentes tipos de texto, imágenes y varios otros tipos se almacenaron en 2 tablas, pero también había objetos. almacenados en una tabla, creo que se pueden llamar datos del sistema.
No quería tener que pensar en combinaciones al aplicar llamadas a modelos, o al menos intentar reducir esos momentos al mínimo. Por lo tanto, decidí que los modelos deberían ser de dos tipos: para objetos de una sola tabla y para objetos básicos de dos tablas. Dado que estas clases de modelo tienen muchos métodos comunes, el mismo ORDER BY o LIMIT, por lo tanto, cada clase base, sobre la base de qué modelos concretos se crearán, heredé de la clase abstracta general.
Como puede ver en el árbol, también agregué soporte para diferentes tipos de bases de datos, lo cual es redundante en este caso. Pero en ese momento entré en el "stream" y creé :). Además, el paso muy correcto en este caso fue que lo hice en base a PDO, porque el php-mysql usado en el código no permitía traducir el sitio a la séptima versión del lenguaje, y quería arreglar esto en la raíz, como dicen.
$element = (new Model())->getOne($id);Debido al hecho de que tenía una buena comprensión de la lógica de la estructura de la base de datos, pude buscar y recuperar un recurso solo por su ID, sin siquiera saber qué tipo de datos internos tiene el recurso, lo cual era necesario con el enfoque anterior. El objeto real funciona con datos y nos olvidamos de sql en el código.
Párrafos finales ...
Este trabajo me trajo 2 giros inesperados. Primero, intenté escribir todo a la vez en forma de código y nada funcionó. Tuve que tomar un bolígrafo, un cuaderno, salir a la naturaleza y, con el gorrión de los gorriones y el zumbido de las abejas, primero dibujar lo que quiero obtener, cómo se conectará, qué clases necesito y cómo se llamará en el código de "controladores". Por cierto, la implementación difería de los bocetos originales solo un poco. Entonces, si un programador no codifica nada, no significa que no esté haciendo nada útil.
En segundo lugar, lo hice muy rápido, a muchas empresas no les gusta cuando los programadores dedican tiempo a todo tipo de refactorizaciones incomprensibles. Implementé todo el proyecto en aproximadamente una semana, mientras realizaba simultáneamente las tareas para la implementación de nuevas funciones.
Notaré las ventajas que mencioné al principio del artículo: la secuencia y la gradualidad de reemplazar el código existente en un proyecto de trabajo, lo que significa que no hay necesidad de dedicar más tiempo a la transición, refactorizando el código dentro del marco de las tareas entrantes. En esto me despido, gracias por leer.