Se encuentra usted aquí
Otra manera de desarrollar en Drupal (I)
De por qué me siento un extraño
En el último año me he estado introduciendo bastante en la comunidad Drupal y he podido aprender muchísimo de mis compañeros, aportar mi granito de arena y compartir multitud de experiencias con los demás. Pero cuando acudo a los eventos y me encuentro con auténticos maestros de Views, Panels, Features o Rules me siento tan extraño como un mono en el zoo de la ciudad. Porque todas esas herramientas, por mucho que intento entenderlas, ni me motivan ni me interesan, ni tienen visos de llegarme a interesar.
No uso Views porque me gusta controlar las queries que escribo. Porque cuando busco en el mysql-slow.log quiero poder optimizar las más lentas con facilidad. No uso Panels porque tengo un compañero y maquetador excelente, al que le gustan los detalles y no quiere HTML ni CSS de más. No uso Features ni Rules porque odio tanto el código autogenerado como que la lógica de negocio esté en la base de datos. No uso todo eso porque todo lo que me ofrecen ya lo puedo hacer con estas dos manos y un teclado.
De todas esas herramientas no entiendo ni papa y en cambio me gusta hablar de encapsulamiento, de complejidad ciclomática, de semántica y abstracción, de testing y refactoring. Y cuando hablo de todo esto muchos abren los ojos como platos y me miran raro, y a mí me entra el complejo y pienso que a lo mejor es que he dicho algo mal.
Y no es eso. Es que parece que lleve escafandra y acabe de aterrizar en una nave espacial. Pero no soy yo, ¡no soy yo!, es la comunidad Drupal la que está mal. Todo lo que digo no es más que el ABC de nuestra profesión, no pretendo erigirme como el Michael Feathers valenciano, pero cuando destapo el código fuente de algún módulo o del core me entran náuseas y mareos y pienso que voy a vomitar.
Del testing en Drupal
Si eres desarrollador Drupal es posible que esto del testing solo te venga de oídas, o lo practiques ocasionalmente y seguramente lo harás al final. Si no es así, si piensas que el testing es la raíz de todo desarrollo, la herramienta que nos permite diseñar correctamente nuestro código, nuestra documentación y nuestra red de seguridad, entonces eres de los míos.
De todos los desarrolladores Drupal que conozco, tal vez menos del 20% se tomen el testing en serio. Y de ese 20%, tal vez todos lo estemos haciendo mal. En parte es por nuestra culpa y en parte es por culpa de Drupal.
Drupal ha sido escrito a voleo, a salto de mata, como mandan los cánones en la cultura de PHP. Para bien o para mal, los desarrolladores solemos hacer como los niños y mimetizamos lo que vemos. Si a nuestro alrededor hay oro, creamos oro. Si a nuestro alrededor hay mierda, producimos mierda. Y en Drupal no hay mucho oro que encontrar.
¿Habéis intentado hacer unit testing en Drupal? Si no lo habéis hecho, os animo a que lo intentéis. Y ya me contáis cuánto tardáis en encontraros con un acceso inesperado a la base de datos, con un drupal_goto(), con una función t(), con recogida de argumentos con arg(0), arg(1) o $_GET. Y os daréis cuenta de que por doquier el código está acoplado a la base de datos, a las URLs, al core, a otros módulos, a sí mismo... veréis la cantidad de funciones que devuelven HTML, que hacen muchas cosas a la vez y tienen muchos distintos propósitos. Veréis plantillas con lógica de negocio y preprocess omnipotentes de 350 líneas. Os daréis de bruces con la programación procedural y desearéis poder inyectar dependencias, pero no podréis.
Todos estos inconvenientes os obligarán a llevar la carga del testing a los tests de integración, desesperadamente lentos y frágiles, y al final terminaréis probando absolutamente todo desde la interfaz con clickLink(), drupalGet() y drupalPost(). Y un día cambiaréis unas cuantas cosas de la interfaz y os explotarán 7 test de 75 líneas cada uno y os estiraréis de los pelos y os preguntaréis qué carajo se ha roto esta vez.
De por qué y cómo sigo con Drupal
De todo esto me dí cuenta poco a poco, cuando después de leer a varios grandes autores llegué a la conclusión de que eso del TDD era algo que valía la pena intentar. Y así empezó mi historia de TDD con Drupal, que vino a ser muy parecida a aquella historia sobre la paciencia y la fatiga, el elefante y la hormiga. Y tras más de un año de colisiones y muchas ganas de abandonar Drupal, llegué a la conclusión de que Drupal es un excelente gestor de contenidos y vale la pena seguir usándolo en muchas de nuestras webs, pero si quiero utilizarlo como framework va a ser con mis propias reglas; orientación a objetos, MVC y BDD.
Los detalles de cómo apliqué todo esto en la segunda parte.
Comentarios
Estoy empezando en esto del
Estoy empezando en esto del desarrollo, y me he encontrado con este post. Por suerte/desgracia me están inculcando metodologías Ágiles en las prácticas de DAI. Antes de conocer el mundo del desarrollo y sin saber por qué, siempre tuve un cariño especial a Drupal, y me acabas de dar una bofetada teórica jeje. Espero con muchas ganas ese futuro post.
Welcome to Symfony
Carles, te entiendo perfectamente. Vengo de Symfony y Ruby on Rails y a mí también me chocaron muchas cosas de Drupal al principio. Aprendí a convivir con todo esto que comentas gracias a la comunidad y la velocidad de desarrollo que se obtiene.
Drupal tiene 10 años y se ha ido tejiendo como mejor ha podido cada contribuyente. Tiene mucha deuda técnica. Te habría encantado oír a Larry Garfield en las charlas de la comunidad de la Drupalcon echar mil y una pestes de todos los gazapos que tiene Drupal, y sin embargo es él quien ahora lidera la WISCII Initiative.
Symfony está ahí esperando que juegues con él. Lo mejor de todo es que es además un pase preferente a contribuír en core y cambiar todo eso que no te gusta en Drupal 8.
¡Adelante!
Por cierto, tengo curiosidad por tu próximo post.
y por que sigues con el?
Por que lo intentas cambiar? Hacer todo lo que pides con Drupal no tiene mucho sentido y demanda demasiado esfuerzo. Todo lo que ganas con el lo pierdes cambiandolo, teniendo en cuenta frameworks como Symfony 2 o ZF2. No veo Drupal como un framework, por que no lo es. Es un CMS, muy bueno pero un CMS. Y como dice Juampy, ahora mismo D8 prácticamente será un CMS basado en Symfony con lo que ya se podrá desarrollar como corresponde.
Saludos y ánimo!
Esto se merece unas pintas en la próxima camp.
Este comentario es desde la más sincera humildad y respeto.
<cite>“Ahora vamos a dar caña”</cite>.
Carles, comprendo completamente tu punto de vista, aunque no lo comparto totalmente.
Empecemos por el principio, lo primero de todo es entender que es Drupal, no voy a irme muy lejos para entender Drupal, creo que la mejor explicación de Drupal la dio <a href=https://twitter.com/#!/luisortizramos>@luisortizramos</a> en su charla de Display Suit @luisortizramos comenta lo que ha sido este tiempo la vía de Drupal, ser una herramienta para construir herramientas webs en las que sobre los programadores, por eso existen módulos com Views, DS, Panels, etc… Para que en los comentarios te digan, esto es necesario porque no se programar….
Y ya sabemos lo que ocurre con las herramientas que construyen código, lo hacen más o menos bien, y la calidad del código queda supeditada muchas veces al flexibilidad, a mayor flexibilidad un código menos óptimo. Pero esto no quita que se puedan contribuir parches para mejorarlas ;)
El tema de Features es diferente, aunque Features genera código, no deja de ser una representación en código de una configuración de uno o varios módulos. El hecho de usar Features es siempre doble.
Mejora del rendimiento al suprimir consultas en la base de datos y tener parte de la configuración en php con cache de APC.
Introducir en el repositorio parte de las configuraciones de la herramienta, para tener un mayor control de las mismas y facilitar el despliegue en otros entornos.
En muchos casos, sino en todos, estos módulos ayudan a ejecutar un proyecto en un proyecto mayor a tener que programar desde cero todas las partes del proyecto. Y aquí es cuando hablamos de ámbitos de trabajo, y puede que me caigan piedras por ello.
Por mi breve experiencia he estado en dos tipos de proyectos, los que son de larga duración, proyectos con una vida de desarrollo larga, con 1 año o más, proyectos grandes en los que si se puede plantear la programación de todo, vistas, páginas con sus correspondientes tpls, formularios con sus correspondientes tpls, etc... En este tipo de proyectos estoy en parte de acuerdo contigo en que se debería picar más de lo que se suele picar, e intentar llevar a código todo lo posible, obviando módulos como panels, views, etc…. Aunque como siempre, todo depende muchas veces de si se quiere calidad o rapidez.
Luego tenemos los proyectos de corto desarrollo, son proyectos para clientes más bien pequeños y con precios muy ajustados, en los que views, contexts, DS, etc…. Sin ser una maravilla de código, dan un producto de calidad, con sus ventajas y desventajas, pero que gracias a los módulos/características de rendimiento de Drupal algunas de las deficiencias se superan sin problemas
No estoy defendiendo la mala calidad por encima de la buena calidad, estoy diciendo que tenemos que adaptar las herramientas a dos varemos claros tiempo y dinero, sin los cuales no se puede definir qué se debe usar o no.
En tercer lugar el uso de esta cosmología de módulos permite una metodología de trabajo bien definida, que consigue que un proyecto sea más mantenible que un proyecto programado desde cero muchas de sus partes, no podemos dejar de reconocer que es más sencillo y rápido actualizar una vista, un contexto que tener que actualizar/duplicar un nuevo módulo.
Así y todo, usando estos módulos yo siempre he defendido (features mediante) que se puede (intentar) seguir el modelo MVC.
Usar Hook_menu o Context como Controlador es una buena clave, y pasar a plantillas tanto los paneles, vistas, DS, formularios, etc… mediante features es otra buena opción, de hecho en la charla de Codemotion lo remarqué. Es un punto de partida para que nuestros proyectos salgan mejor, sin la necesidad de programar el 100% del proyecto.
Y aunque mi preferencia es back-end siempre insisto en la buena formación de los desarrolladores de front-end para mejorar la calidad, porque creo que muchas veces es por donde fallan proyectos de Drupal, a partir del hook_theme, tpls, y los preprocesamientos de elementos.
Por otro lado hay que hablar también si producto o herramienta.
En este caso yo siempre he pensado (perdonad por la vulgarización del ejemplo) en Drupal como una tienda de ropa, en la que el cliente compra lo que mejor le queda, sin ser perfecto, y que le sobra por un lado y por otro normalmente, en este caso eso sería Drupal, por otro lado nos vamos a las Modistas, que nos toman medidas y nos hacen un traje a medida, y estaríamos pensando en los frameworks puros.
El gran problema de Drupal, es que ni termina de ser un producto, ni termina de ser un framework, y lo que parece que se ha decidido para d8 responde más a las necesidades de una empresa que al planteamiento de la comunidad, porque drupal tiene un serio problema de obesidad mórbida que lo esta alejando de la idea de framework por muchas Apis que tenga, y lo esta acercando cada vez más a la idea de worpdress.
¿Es bueno o es malo esto? No lo se, pero lo cierto es que un proyecto personal que estoy llevando a cabo en d7, que se aleja mucho de una web convencional es un claro ejemplo de que Drupal puede usarse para construirlo todo, pero no les lo mejor para todo ello.
Esta claro que cuando pasas de Drupal a herramientas como Yii, Cake, etc… te das cuenta que tienes más libertad para hacer cosas, para construir tu herramienta, y que se adaptan mejor a tus necesidades, pero también tienen un mayor coste de mantenimiento, desarrollo, mejoras, etc….
<cite>Drupal no es ni bueno ni malo, es lo que es, y en la medida de lo bien/mal que lo conozcas harás mejor/peor el trabajo.</cite>
Gracias a todos por vuestros
Gracias a todos por vuestros comentarios. Sobre todo a Oskar, que menudo curro te has pegado.
Oskar, este blog está hecho en Drupal y no tiene ni una sola línea de código picada a mano. Desde luego que cada proyecto tiene sus necesidades. Pero en mi trabajo considero que todos mis desarrollos son a largo plazo, porque parto de la idea de que los voy a tener que mantener y, seguramente, terminen por crecer.
No digo que el site building sea malo. Respeto mucho a los que ofrecen sites de calidad a base de site building. Aquí solo estoy expresando mis preferencias personales y mi manera de entender el software, mi manera de entender mi profesión. No quiero que de aquí se entienda que me estoy colocando por encima de los que trabajan a base de site building.
Eduardo, si no abandono Drupal es porque en la gestión de contenidos no tiene rival. Y porque tiene una buena base para poder trabajar sobre él como si fuese un framework. Solo le falta un poco de orden y buen hacer para que sea una plataforma perfecta tanto para editores como para desarrolladores.
Software libre
Debo dar mi opinión honesta con respecto a este post, no voy a hablar de TDD, solo faltaría con el maestro en la sala.
De lo que si creo que merece la pena hablar es de este tipo de comentarios con respecto a la calidad del código de algunas partes de drupal, core o contribuciones.
No me parece mal la visión crítica, hay cientos de aspectos mejorables en Drupal, tanto core, contribuciones, documentación, comunidad...
Pero trabajando con un sistema tan abierto a las contribuciones, es también correcto intentar aportar una solución. Me ha parecido bastante fuera de lugar que hayas descrito como "vomitivo" un código que alguien ha desarrollado utilizando su tiempo y sus recursos y después lo haya contribuido de forma totalmente altruista. Sinceramente yo lo veo como una falta de respeto.
Talk is silver, code is gold.
Me pierden las formas
Tienes razón, Pedro. Me pierden las formas.
El hecho de que sea software libre no debería justificar el mal código. Al contrario, siendo un trabajo vocacional y sin las presiones a las que suelen estar sometidos los desarrolladores en las empresas, debería ser mejor que el código propietario.
En este artículo hablo de código, no de personas. Vaya todo mi respeto al desarrollador por su vocación y por su altruismo, pero si con su tiempo libre contribuye mal código flaco favor hace a la comunidad (que lo ha de sufrir). Quien contribuye expone su trabajo y lamentablemente o por fortuna se somete a juicio de los demás. Igual que hago yo escribiendo en este blog o yendo a dar la murga sobre agilismo.
"Talk is silver, code is gold" dependerá de qué talk y de qué code. Que cada uno haga con su tiempo libre lo que considere oportuno. Personalmente pienso que soy más útil ordenando mis ideas y explicándolas a los demás. Pero qué sé yo, son los demás los que han de juzgar.
<cite>Pero en mi trabajo
<cite>Pero en mi trabajo considero que todos mis desarrollos son a largo plazo, porque parto de la idea de que los voy a tener que mantener y, seguramente, terminen por crecer.</cite>
Carles, quizás no me he explicado bien, no por realizar proyectos con un ciclo de desarrollo corto no lo plateamos como proyectos que haya que actualizar, tener un mantenimiento evolutivo, etc...
En general siempre buscamos el desarrollar los proyectos bien, y dejarlos perfectamente configurados para que sea mantenibles.
Y es en este apartado, donde la utilización de la metodología de "site building" ayuda para la definición de la construcción del proyecto, y su posterior mantenimiento y evolución. Así y todo, aunque la gente piense que construir sitios con Drupal puede ser sencillo, total es arrastrar y pinchar en cuatro botones tienes un sitio construido.
Creo que para nada, un ejemplo claro. Durante la #dnightval2012 Estuvimos hablando Agustin y yo sobre el impacto que tiene el módulo context en el rendimiento de la carga de proyectos, y Agustín opina que Panels al estar basado en “urls” y poder generar reglas dentro de esas urls puede tener mejor rendimiento cuando hablamos de 50-100 contextos o más configurados.
Con esto quiero decir que tanto una forma de trabajar u otra tiene su complejidad, y puede ser igualmente frustrante y a la vez igualmente entretenida.
Y ojo que yo soy de los que opinan que por mucho “site building” que se haga en Drupal la diferencia real entre un proyecto “amateur” y un proyecto “profesional” es simplemente unas pocas líneas de código que se han podido tirar.
Creo que saber en cada caso cual de las dos es la mejor para llevar a cabo el proyecto, y no lanzarse a por una de cabeza.
Un saludo y genial debate.
Oskar