BLDD, un DD para dominarlos a todos

Esta es una carta para tí, pequeño saltamontes programador, que ayer descubriste que un if es una instrucción muy molona que hace que puedas ejecutar un pequeño trozo de código según una condición predeterminada, y que mañana descubrirás muy probablemente qué es una función recursiva, qué es un objeto y que Singleton es un patrón de diseño, o al menos esto dicen por allí…

Esta es una carta para tí, para que te acuerdes de ella en los momentos duros de tu vida como programador y para que busques un punto de partida en esta maravillosa corriente profesional, llena de letras verdes fosforito con significado de victoria, de horas extras impagadas y desagradecidas y de bugs indescifrables, más escondidos que la dignidad de los votantes del PP.

Sonríele a la vida, afortunado. Alabado sea tu futuro!

Y es que hoy, aquí, te quiero contar algunas situaciones que, seguramente, tarde o temprano, y más temprano que tarde, vivirás en alguna de tus futuras hazañas. En estas situaciones hay monstruos, trampas mortales y hasta armas letales. Hay religiones inconexas, dobles morales y lo peor de todo, gilipolleces como para alimentar a medio Congo y sobrar para una cena de navidad donde toda Sierra Leona esté invitada. Barra libre de Moët incluida.

Empecemos con algunas frasecillas del gremio…

Esto está mal

Sí, amigo.

Aunque no lo creas, todo cuanto hagas en tu vida será una verdadera mierda para algunos. Da igual que lleves un día programando, o que tengas la muchas veces inevitable presión de aquellos que te pagan el sueldo, o simplemente que no lo sepas hacer mejor. No importa. Hagas lo que hagas, apestará a perro agusanado.

Y posiblemente lo esté. Posiblemente tu creación será pobre y con muchos fallos, pero tenemos la suerte de que rodeados como estamos rodeados de almas constructivas y caritativas, muy pocas veces un “Está mal” vendrá acompañado de un “Si quieres me siento a tu lado y miramos como puede estar mejor”.

No te ofusques, no estás solo.

Somos la sociedad del “Tu no sabes” y no la del “Creo que puede mejorarse”, y estamos tan acomplejados con nuestras mierdas, que necesitamos poner al principio de nuestras frases un “IMHO” porque sino, puede que se note demasiado que creemos que toda linea de código que no sale de nuestros muñones es basura ipso facto.

Los más educados han decidido enmascarar toda esta realidad con una palabreja de lo más interesante, y querido lector… grábatela en tu memoria desentrenada.

Legacy Code.

Estos de producto…

Otra de las frasecillas que corren por la autopista de lo insultante es “estos de producto, que pesaos con los píxeles” o parecidas, normalmente con tono burlesco y desafiante.

Sí, amigo, un clásico entre compañeros de departamento, muy habituales en cualquier empresa que se precie donde cuiden un poco sus ventas. No todas las empresas son tan modernas y liberales como para dejar a su libre albedrío métricas de ventas y ingresos…

Ah… estos de producto que quieren jodernos la vida con chorradas como píxeles para los frontales, con cambios en la web aparentemente inútiles, o con integraciones con métodos de pago o de transporte. Cuando veas a toda esta gentuza, escúpeles en la cara, porque no nos respetan, a nosotros, a los programadores, a los que hacemos los proyectos que nos piden con tecnologías que desconocemos porque son guasonas y molonas, a los que decidimos que el nuevo proyecto de la empresa se hará con 378 capas distintas, a cada cual más inútil, porque un tal Pepito de los Palotes con sombrero y cuyos fans llevaban el libro de Clean Code tatuado en sus suaves nalgas, dijo que era lo último en Hipsterismo, a pesar de no saber qué estamos haciendo y el porqué lo estamos haciendo. A nosotros que hacemos un formulario en 5 días porque queremos que sea compatible con la GameBoy advance, con la pantallita del microondas y con el termostato de nuestra estufa. A nosotros que nadie nos impide estar todo el día con la nariz enganchada a los grupos online con ciertos parecidos a bacanales.

A nosotros que somos tan responsables.

Te diré un secreto. En voz bajita, que no nos oiga nadie.

Si ellos supieran cada una de las cagadas que hacemos en el código que nos pagan por hacer, o si supieran cada una de las decisiones arquitecturales erróneas que tomamos por el mero hecho de querer molar cantidad, estaríamos todos despedidos. Todos.

Aunque supongo que preferimos decir “Estos de producto…”, aparentar que no tan solo sabemos hacer un foreach, sino que también sabemos hacer el trabajo de media compañía, y seguir con nuestras vidas con la cabeza bien alta, dejando un rastro de Legacy Code, cual rastro en nuestras espaldas.

En mi empresa hacemos…

Esta es perla brillante, el zafiro de las frases, aunque para encontrarla tendrás que esforzarte un poco y dejar que la luz del sol alumbre tu tersa tez para salir de casa y relacionarte con otras personas de otras empresas.

Ánimo.

Y es que descubrirás que todas las otras empresas utilizan lo last de lo last. Mierda de la buena en su stack de tecnologías y droga de la dura en sus últimas incorporaciones (cuando no tienen un auténtico máquina en su departamento de backend, tienen un exfacebook en su departamento de sistemas o un súper crack como CTO llegado de las montañas de los elfos).

Todas las empresas están tan bien dotadas tecnológicamente y con unas plantillas tan extremadamente potentes, que cuando entres en una empresa nueva, nunca, repito, nunca, jamás de los jamases, tendrás la impresión de haber empezado a trabajar en una escabechina llena de cadáveres, pudriéndose durante los últimos 10 años.

Nunca, en absoluto.

Y es que amigo, parece que entre que todo nuestro código es una mierda, y los de producto están todo el día que si ponme este píxel, y ponme este banner, resulta que no tenemos tiempo de hacerlo bien. Pero eh! no es porque seamos todos unos auténticos chapuzas en la mayoría de los casos, no no, es porque no hemos tenido tiempo.

Es que resulta que Uncle Bob dice que…

Rápido y preciso.

• ¿Está aquí Uncle Bob?
• ¿Conoce Uncle Bob el proyecto?
• No, ¿verdad?
• Pues me importa una mierda lo que diga el tío Bob.

Fin de la discusión.

La clave de todo, BLDD

Dicho esto, verás que el mundo es un lugar inhóspito, lleno de gente con pocas ganas de ayudarte y con muchas de joderte y hundirte, pero aún así tu tienes que hacer un switch porque dadas las circunstancias que sean no puedes o no sabes hacerlo mejor, o tienes que hacer un proyecto con pocos días y por desgracia no puedes hacerlo compatible con el manillar de tu bici.

Te presento, humildemente, el BLDD, abreviación de BullshitLess-Driven Development (otra cosa que tienes que aprender es que aquí escribimos todos con abreviaciones, en inglés aunque estén hablando dos de Albacete, y que debes poner entre frase y frase la palabra Trade-off. Si no haces esto, no serás aceptado por los grandes círculos).

El BLDD es una práctica muy sencilla, basada en el ignorar todas aquellas frecuencias que emitan gilipolleces en directo. Lo que vendría a ser el clásico mandar a esnifar plastidecor picado de toda la vida, pero con un nombre moderno y casual, de estos que nos hacen sentir a nosotros muy top.

Se recomienda primero hacer los tests, y luego implementar el BLDD. Si no lo haces así, eres un mierda.

Esta metodología contrarresta todas las demás que terminan en DD y es aplicable la mayor parte del tiempo útil de tu vida.

• Que alguien te dice que tu proyecto debería tener tests primero? BLDD.
• Que alguien te dice que estás muy acoplado a tu FW y solo quieres hacer tu currículum? BLDD
• Que alguien te dice que tu código es mierda y que él lo hace mejor en DDD? a este le rompes la boca BLDD

Ya ves, funciona cual navaja suiza. Lo bueno de esta práctica es que ten claro que nunca nadie va a decir como debes practicarla. Un sinfín de fórmulas, cada cual más original, pueden formar parte del elenco de posibilidades a la hora de ejecutar el BLDD.

Algunos consejos para terminar

Para finalizar mi cookbook del buen programador, un escueto listado de ideas y miniconsejos de jardinería para que vayas pensando.

• IMHO, si algún día haces una presentación en público, súbete el libro rojo de DDD contigo, y al que se ponga en la primera fila y se ponga a mirar el móvil o a dormirse, se lo tiras. Le va a doler. Mucho. Y si sigue durmiendo, recuerda que aún tienes de otros colores…
• IMHO, una conversación se acaba cuando alguien dice la palabra Annotation.
• IMHO, para tener amigos en Twitter solo tienes que decir “TDD is dead”. Para tener haters, también.
• IMHO, los tests en tus proyectos es como el paro en españa. Lo importante es el coverage, no la calidad de los cases.
• IMHO, en Barcelona, de media los developers solemos cambiar de trabajo una vez al año, con subida salarial de forma recurrente. A los 40 años estarás cobrando 120.000 euros y serás un fucking god en 20 lenguajes distintos. Seguirás sin poner bien el puto nombre a una variable y pondrás los comentarios en español.
• IMHO, a día de hoy, en enero de 2017 es mainstream el Event Sourcing. Si, si, está práctica tan jodidamente útil en todo nuestro sector. Así que calculo que aproximadamente en 2021, en alguna de las empresas en las que trabajes, te encontrarás un conjunto de código intratable, ilegible y profundamente indocumentado fruto de esta modilla. De nada.

Conclusiones

Finalmente decirte que mucha suerte, que aprendas mucho, que leas mucho, que preguntes y enseñes mucho, pero que nunca dejes que nadie te diga como tienes que hacer las cosas (menos si alguien te aconseja que no utilizes Prestashop. En este caso, hazle caso). Ten el suficiente criterio como para aceptar que muchas de las formas de trabajar que escucharás en conferencias, charlas de amiguetes o en hilos de Twitter ni tan solo sirven para tu proyecto.

Trabaja duro, persigue tus objetivos y acuérdate de comprarte muchos libros técnicos, de sacar una foto cada vez que te compres uno y publicar en Twitter algo como “Ya tengo plan para este fin de semana”.

Para todo lo demás, BLDD.