La razón de este artículo fue otra publicación sobre Habré. Se llama "No aprenda frameworks, aprenda arquitectura" y puede leerlo
aquí .
Haré una reserva de inmediato y estoy completamente de acuerdo con el autor y solo quiero agregar mis "tres centavos". Al principio pensé en hacerlo bien en los comentarios del artículo, pero rápidamente me di cuenta de que el "centavo" es bastante voluminoso. Y así nació este texto.
Primero, un poco sobre ti
He estado involucrado en el desarrollo web durante un año desde el 98. Trabajó para la empresa y como freelance. Reclutó equipos. Tanto en la vida real como en línea. El primer lenguaje de programación fue Perl, que ahora ha fallecido con seguridad, y todavía lamento su desaparición prematura. Luego vino php. Un poco más tarde comenzó el rubí y la era de los fuegos artificiales.
Grandes promesas pequeños logros
La conocí con entusiasmo. De hecho, parece que ha aparecido una herramienta diseñada para facilitar significativamente el desarrollo, lo que puede salvarlo de una gran cantidad de rutina. Sin embargo, el entusiasmo desapareció rápidamente. Y aquí está el por qué.
No sé quién cómo, pero, en primer lugar, esperaba deshacerme de una gran cantidad de acciones monótonas que tenía que realizar cuando trabajaba en cada nuevo proyecto. Diseñe la "columna vertebral" de la base, escriba la salida de esencialmente las mismas páginas de texto, etc., etc. Aquellos que han escrito un número suficiente de sitios complementarán fácilmente esta lista con muchos, muchos puntos. Y la mayoría de los fuegos artificiales ahorran mucha rutina. Pero a qué precio!
Y esta vez ... y estos dos ...
Erast Fandorin
Mi primera reivindicación y RoR, y Yu, y el Symfony, y casi todos los demás, que tuvo que cumplir - sus monstruosas y toneladas de código totalmente superfluo, lo que invariablemente aparece en el proyecto. Acostumbrado a muchos años de trabajo, que el código debe ser lo más limpio y conciso posible, que la aplicación debe ser lo más rápida posible, no podría aceptar la basura (disculpe, no puedo decir lo contrario) que terminé en proyectos.
El segundo reclamo es un intento de todos, sin excepción, de los autores de fuegos artificiales para inventar, algo así como su lenguaje de programación. Voy a explicar lo que quiero decir. Tomemos, por ejemplo, la biblioteca js jQuery más común. Al mismo tiempo, haré una reserva de inmediato que considero que es casi el único epíteto útil, competente y muchos, muchos halagadores, entre otros. Doy jq como ejemplo solo porque seguro todos entenderán lo que quiero decir. Y así puede acceder al elemento por ID en js nativos como document.getElementById ("id") y como jQuery $ ("# id"). El hecho de que se haya escrito una docena de caracteres menos no es muy impresionante. Al mismo tiempo, jq tiene muchas otras ventajas para las cuales estoy listo para aprender una nueva sintaxis. Además, es confiable y casi nunca entra en conflicto con otras bibliotecas. Lo que no se puede decir, y un montón de su tipo, que se prevé que reemplacen.
Una vez más, haré una reserva; en ningún caso estoy en contra de aprender algo nuevo. Pero solo si este nuevo hace que mi código sea más limpio y rápido. Si necesito aprender algo para luego poder remachar sitios del mismo tipo que un mono y no me atrevo a dar un paso a la izquierda, a la derecha, porque no sabía cómo, gracias.
Sí, lo peor es que este enfoque de programación simplemente agota el pensamiento y cuando falla este nuevo marco súper genial, y esto, créanme, sucede tan pronto como el cliente le pide algo que está al menos un poco más allá del alcance, ¡ay del marco (descubrí recientemente que ahora existe tal profesión) cae en un estupor y comienza a hacer preguntas estúpidas en todos los foros accesibles para él. Todo se descarga por el hecho de que uno de los programadores (no un marco) esculpe una muleta y Dios no permita que el cliente no audite el código.
Y estos son tres ...
El es
Todo lo anterior se aplica no solo al frente, sino también a la parte posterior. Como resultado, surge la pregunta: al principio reconocí que durante cualquier desarrollo tengo que realizar muchos gestos innecesarios que me gustaría optimizar, pero ¿se puede hacer a ese precio? Y además, hay otro punto, que en su mayor parte se refiere al desarrollo en Ruby.
Para implementar las funciones más básicas de una aplicación web, debe conectar gemas separadas. Para alimentarse de la base de datos - mysql2, para enviar correo - correo o poni creado sobre su base. Y así sucesivamente. A primera vista, no hay nada de malo en eso: todas las gemas en Ruby generalmente están bien probadas y no hay problemas con ellas. Pero también hay excepciones a esta regla. Por ejemplo, una vez a la semana tuve que sentarme con odf-report, que no quería funcionar correctamente, y luego escupir y escribir mi clase. Además, es algo molesto que con la conexión de cada gema, el tiempo de formación de la página aumenta inevitablemente. En algunas gemas ahs muy ligeramente. Y no algunos ... Intenta experimentar sobre este tema con el pony ya mencionado; compruébalo por ti mismo.
La eterna pregunta
Y que hacer Por un lado, el desarrollo en un lenguaje "puro" definitivamente no es una opción, pero por otro lado, ¿las herramientas existentes no se satisfacen por varias razones? La salida se ve en la creación de una herramienta que optimizaría las funciones más utilizadas y al mismo tiempo no obstaculizaría al programador, y no le impondría un estilo de programación que el autor de esta herramienta considera el único correcto. En la práctica, esto significa que la herramienta debería:
- contiene un conjunto mínimo de funciones estándar, máximas optimizadas
- la herramienta no debería obligar al programador a aprender algo como un nuevo "lenguaje" de programación que inhabilita completamente el cerebro
- y todo esto, idealmente, debería convertirse en una biblioteca ligera que no intente competir en términos de la cantidad de código con el sistema operativo.
Tal vez me equivoque, pero hasta ahora, nadie ha podido convencerme de lo contrario. Listo para escuchar cualquier opinión.