Dogmáticos a favor vs. radicales en contra

Las herramientas y las metodologías no fallan, son las personas al aplicarlas. Una llave inglesa no puede fallar, o es la herramienta adecuada para tu problema o no lo es. Si eliges una llave inglesa para un trabajo que no es el suyo, el error es tuyo. No existe el legacy code, sólo los legacy teams, o las legacy companies que generan el legacy code.

En los proyectos Web veo dos tipos de proyectos en función del estado en el que se encuentran: los que especulan para ver si funcionan (start-ups, etc.) y los que han conseguido consolidarse y tienen una proyección a largo plazo. La gran mayoría son unos terceros, que son los que no tiran y se han de cerrar.

En los que especulan, la gran mayoría de veces, tiene todo el sentido el “don’t worry be crappy” si te ayuda a ir más rápido para poder mostrar que el proyecto funciona, ganas usuarios, emites algunas facturas, puedes conseguir financiación y tirar adelante. Si todo va bien, curras mucho, consigues funding y después de algún tiempo, el proyecto se consolidará. ¡Felicidades! Ahora bien, todo lo rápido que has ido al principio tocará hacerlo bien hecho para reducir los costes de mantenimiento (lanzamiento de nuevas funcionalidad, bugs, etc.) ya que tu proyecto ya no especula sino que ha venido para quedarse. Seguro que habéis visto las típicas gráficas de la deuda técnica.

En los proyectos consolidados, cualquier herramienta que acelere la velocidad de desarrollo reduciendo costes de mantenimiento es un plus. Las metodologías de desarrollo ayudan este objetivo. Cada uno es libre de usarlas o no.

Sobre TDD

Si creéis que no la aplicaríais en vuestros proyectos, genial, super respetable, pero la realidad es que, ya no sólo TDD, sino hacer Unit Testing sobre la lógica de negocio con un Coverage del 100%, es posible si trabajas desacoplado y no es ningún disparate. El testing de tu infraestructura, si es sencilla (repositorios de doctrine, petis a redis, petis a WS, etc.) te la puedes ahorrar, no es relevante. Los beneficios son reducir la generación de bugs (coste de mantenimiento), lo que se traduce en $$.

Sobre Arquitectura Hexagonal y otras

Si no la queréis aplicar, bien, pero la realidad es que cualquier arquitectura basada en la inversión de dependencias, facilita que los componentes se puedan unit testear. Facilita estar desacoplado del método de entrega así es más sencillo que un caso de uso funcione para un App móvil, API, una web tradicional, una web single App por REST, etc. Si te puedes desacoplar del framework mejor. Se puede pensar que nunca migrarás de framework, yo lo pensaba cuando estaba en ZF1 y todo el mundo estaba en ZF1, pero luego apareció Symfony2 (+ velocidad de desarrollo). Aparecerán más cosas que acelerarán el proceso de desarrollo y reducirán los costes, por lo tanto, mi sugerencia es estar preparado para cambiar ese tipo de detalles de implementación. Es más de uno los proyectos en los que he visto que para añadir Web móvil y/o App móvil se tripicla el controlador o las vistas.

Sobre DDD

DDD tiene dos partes, la estratégica y la táctica.

La estratégica defiende, para equipos grandes y proyectos de envergadura, una arquitectura basada en servicios (algo super trillado y que no es nuevo) donde cada parte del sistema se comunica de forma síncrona por peticiones REST, principalmente, y de forma asíncrona por mensajería (sistemas de colas). Cada parte del sistema puede estar desarrollada con código espaguetti o super clean code, en paradigma funcional o orientado a objetos, en PHP o cualquier otro lenguaje. Cada mini aplicación que resuelve parte del problema global de la compañía se orienta desde el punto de vista de negocio. Muchas empresas siguen esta filosofía (Amazon, Airbnb, Twitter, etc.). El beneficio es la gestión de equipos grandes, autónomos, que tiran millas y no se pisan entre sí. De nuevo, velocidad de desarrollo para equipos grandes.

Respecto a la parte táctica, habla de estilos de arquitectura como el hexagonal y muchos otros, y de algunos patrones útiles como Repositories, Value Objects, Services, etc. para modelar el lenguaje de negocio en el código.

Como veis, son conceptos que existen hace mucho años, nada nuevo. Sólo que ahora se han agrupado bajo estas siglas. (Hay alguna cosa más pero es el resumen más sencillo que he podido hacer). Se puede aplicar cualquier parte una sin la otra.

Seguro que habéis visto más de un proyecto grande con una única BBDD con 1000 tablas donde todos escriben y todos leen. Donde todo el mundo pushea features que no se relacionan y en cambio hay conflictos, etc. Pues DDD intenta resolver este tipo de cosillas.

Conclusión

No hace falta que nadie defienda una herramienta o metodología, no tienen sentimientos. Se defienden solas por lo que aportan. Y aunque estoy de acuerdo que a veces hay dogmáticos a favor, también es cierto que hay radicales en contra. No entiendo ni una postura, ni la otra.

 

  • Carlos, gracias en primer lugar por publicar este artículo. Me parece una buena respuesta al artículo “PDD, Pragmatic Driven Development” publicado por Marc Morera.

    Me gustaría hacerte una pregunta: ¿de verdad querías escribir la primera línea del artículo tal y como está escrita? “Las herramientas y las metodologías no fallan, son las personas al aplicarlas.”

    No me puedo creer que TODAS las herramientas y metodologías sean buenas al menos en alguna circunstancia o ámbito. ¿De verdad no existe ninguna herramienta mala en el mundo? ¿Jamás se ha ideado una metodología mala? Me cuesta muchísimo creerlo.

    • Carlos Buenosvinos

      Javier, creo que a las herramientas les pasa lo mismo que a las especies, selección natural. Las que son malas realmente, acaban desapareciendo y nadie se acuerda de ellas. De las que son útiles en alguna situación, perduran.

      El approach de Marc, no me parece mal, la verdad. A mí también me gusta ser pragmático. Quizá me gustaría ver ejemplos de lo que no le convence para poder charlar más y tener un debate más constructivo :). Para mi gusto, a veces, hace comentarios dogmáticos, de lo que él mismo se queja, en contra de algunas tecnologías, metodologías y demás refiriéndose a “modas”. Yo intentaría ser más prudente.

      Sea como sea, “Una guitarra impresora” seguro que no es la mejor herramienta. Así que seguro que herramientas malas debe existir, pero por selección natural no las conocemos :)

      • Buenas!

        Respondiendo a la respuesta que le has hecho a Javier.

        Podría buscar algún ejemplo, claro está, pero que quede claro (otra vez) que en ningún momento he dicho que no sea útil o que no tenga sentido utilizarlo.

        ¿A veces hago comentarios dogmáticos? Es probable, estoy a disposición de aprender y de recibir puntos de vista sobre como enfoco ciertos problemas, siempre y cuanto sean constructivos (Un tweet abstracto lanzado al aire a expensas que el receptor se percate de su existencia no es constructivo, y me aplico el cuento, claro está), pues creo que en el momento en que uno se convierte en una persona más o menos pública, es la mejor forma para mejorar.

        La verdad, me gusta el discurso que tiene este post. Va muy en linea, a mi parecer, con la idea que pueda tener yo sobre el tema. Me encantaría que se tratara realmente el DDD o el TDD como una herramienta y no como un requerimiento.

        Saludos Carlos.

        • Carlos Buenosvinos

          Hey Marc! Qué bueno tenerte por aquí. Por mi parte y la de la gran mayoría de gente que estamos por aquí, DDD, TDD y muchas más cosas son una herramienta, 100% de acuerdo contigo. Me alegra que estemos de acuerdo.

          Mis únicas quejas es cuando se usan comentarios no constructivos tipo “moda”. Pero es una opinión también respetable.

          • Bueno, una moda puede ser algo útil igualmente. Una moda no es algo malo, para nada, y cuando en este caso me refiero a esto como moda es porque se ha construido una gran espectación a su alrededor de una forma muy rápida.

          • Carlos Buenosvinos Zamora

            Fair enough, entonces mis disculpas porque estaba entendiendo el uso de “moda” en forma negativa.

    • Keyvan Akbary

      Javier, a mi opinión, bueno o malo depende del contexto. Precisamente el mayor intríngulis del software es el análisis certero y objetivo de este problema aplicado a tu contexto. Este tipo de dudas existenciales solo las resuelve la experiencia.

      Pocas prácticas se han engendrado con el objetivo de implantar el mal o la confusión sobre sus consumidores, todo tiene un lugar. Al final eliges aquellas que te hacen la vida más fácil en tu entorno determinado.

      Por poner un ejemplo, yo a veces soy un poco inquisidor en la defensa de algunos argumentos como el de el patrón Data Mapper versus Active Record. Esto no es porque Active Record sea malo por definición, esto es porque en mi contexto, que es el de una empresa consolidada con un codebase complejo y con un equipo con recursos limitados, Active Record es un problema. Repito, en mi contexto concreto, que no tiene porque ser el de otros, Active Record es “malo”. Me encantaría hablar sobre ello en un futuro.

      Entiendo que a lo que Carlos se refiere es que hay contextos donde determinadas técnicas, patrones, procesos o mecanismos tienen una eficacia demostrada. Uno puede fiarse o no. Leer, experimentar y compartir ayuda enormemente a entender diferentes enfoques y optimizar para conseguir una serie de resultados. Al fin y al cabo nuestra responsabilidad como profesionales es la de ser críticos y aplicar de forma objetiva lo que mejor convenga al proyecto con el que trabajamos y al equipo que lo mantiene.

      También ocurre que, a veces, expresar esto a través de medios donde tienes una capacidad muy limitada de expresión, como Twitter (origen de todos los flames), recortar y sintetizar un pensamiento elimina cualquier posible contexto. Los lectores se quedan con el imperativo categórico, se sienten juzgados y al final algo que parte con buenas intenciones se convierte en un problema.

  • Xavier Vidal Piera

    Buen artículo !!

    Si me dieran un euro por cada vez que he recordado que hay una ‘deuda técnica’ que pagar, ahora probablemente tendría mi hipoteca pagada … ;)

    Dejando de lado las herramientas y las metodologías, el principal problema que se repite siempre es el no saber crecer, el no saber cambiar el chip de dejar de ser una startup para convertirse en una empresa grande con todo lo que eso conlleva.

    Usualmente cuando una empresa se hace grande de repente echa de menos esa “agilidad” que tenían en sus inicios, esa “magia” con la cual lanzaban nuevas features cada dos por tres, los bugs quasi inexistentes, … y al crecer se encuentran con la realidad de que no se han adaptado a tiempo, quizá si que lo han hecho comercialmente, pero técnicamente se enfrentan a que el paradigma ha cambiado: la complejidad se vuelve inmanejable y se hacen oidos sordos a que hay que invertir tiempo en pagar la deuda técnica.

    La introducción de metodologias en paralelo al crecimiento de la empresa debería ser innegociable. Cualquiera en su casa puede hacerse una barbacoa con cuatro tochos a su manera, pero amigo, si vas a construir una torrecita en tu solar más vale que tengas una ligera idea de lo que estás haciendo o a medianoche te caerán los tochos en tu cara mientras estás durmiendo.

    Es cuestión de probar cosas, prueba Kanban, Scrum, GTD, lo que sea para organizarte, a nivel técnico introduce buenas prácticas, y no hablo de este framework o el otro, sino de fijar un estándar de calidad, desarrollar con sentido común y con capacidad analítica para crear código que negocio necesita pero que no te cree un problema de mantenimiento posteriormente.

    Personalmente, yo me quedo con la metodología que mejor encaje con la idiosincrasia de la empresa donde esté trabajando, si es Scrum, Kanban o ITIL, pues bienvenido sea. No hay herramientas malas, sino piezas que encajan mejor que otras…