Posts

  • La historia que cuentan nuestros tests

    Nos han contado que nuestros tests pueden llegar a ser la mejor documentación de nuestro proyecto. Qué hace, cómo se usa. Pero, ¿cómo podemos plasmar esto en nuestro código? ¿qué debería documentar exactamente? Continuando con la serie de "los tests también son código" os intentaré contar cómo lo hago yo.

    -- seguir leyendo --

  • Reduciendo boilerplate en los mocks

    En esta nueva entrega de la saga "Los test también son código", me gustaría hablar acerca de cómo planteo yo la configuración de mis dobles de prueba. Al igual, que con la creación de las entidades de dominio, es una tarea aparentemente sencilla, pero en la práctica acapara gran cantidad de líneas de código en nuestros tests.

    -- seguir leyendo --

  • Reduciendo boilerplate al crear nuestras entidades de dominio

    Siguiendo con la serie "Los test también son código", me gustaría contaros cómo consigo yo instancias de mis objetos para poder probar. Es una tarea aparentemente sencilla, pero en la práctica acapara gran cantidad de líneas de código en nuestros tests.

    -- seguir leyendo --

  • Las principales familias de frameworks de testing

    En este segundo post de la serie "Los tests también son código" quiero contaros como funcionan típicamente las familias de frameworks de tests más comunes para ver cuales son los mecanismos que nos ofrecen a la hora de escribir nuestros test y cómo poder sacarle provecho a dichos mecanismos.

    -- seguir leyendo --

  • Los tests también son código

    A pesar de lo evidente que pueda parecer esta afirmación, me he decidido a escribir este post porque llevo muchos años con la sensación de que no somos del todo conscientes de esto. ¿En qué me baso para hacer esta afirmación? Pues tanto en conversaciones como en revisiones de código veo.

    -- seguir leyendo --

  • Nuestros tests como un usuario más del sistema

    No os engaño, quiero hablaros del código testable. No de tests, sino del código de producción fácilmente testable. Pero intentaré darle un enfoque diferente. ¿Por qué? Creo que, en función de cómo vemos un problema, así buscamos una solución acorde al mismo. Por lo tanto, plantearnos el problema de manera que nos atraiga puede hacernos más llevadero intentar resolverlo.

    -- seguir leyendo --

  • Programar pa'na'. Programar pa'nadie

    Antes de que sigas leyendo te hago 3 avisos fundamentales para entender este post.

    1. Este post no lo ha escrito Sergio, autor de este blog. Lo ha escrito un programador anónimo que por motivos laborales no puede publicar este contenido en su propio blog puesto que le gustaría conservar su empleo. Sergio sólo me presta su blog para que vosotros podáis leer mis reflexiones y yo le estoy enormemente agradecido por ello.
    2. Las reflexiones que aquí vais a encontrar no pretenden ni encontrar soluciones ni encontrar la raíz de problema alguno. Son sólo eso, reflexiones. Si cuando leas el post te sientes identificado, al menos verás que no estás sólo. Pero no busques soluciones aquí porque no las tengo.
    3. La historia no acaba bien...pero podría ser peor.

    -- seguir leyendo --

  • El Model View Controller no es malo, es la sociedad, que lo corrompe

    Tenía en el tintero escribir sobre este patrón, porque es muy común verlo fracasar en muchos proyectos y quería aportar una visón que a mi me ha funcionado bastante tiempo (me sigue funcionando, de hecho) y que creo que es coherente y compatible con otras tendencias en el mundo del desarrollo como la arquitectura hexagonal. Sin embargo, siempre lo voy posponiendo, porque pienso que son cosas muy trilladas y que ya no aportan nada nuevo.

    ¿Qué me ha hecho cambiar de opinión? Pues el otro día vi un video de los amigos de Codely en el que hablaban sobre la inconveniencia de seguir usando este patrón. En él dan una explicación que no termina de encajar con lo que yo aprendí en su día así que me gustaría poder aportar mi visión por si os sirve de ayuda.

    -- seguir leyendo --

  • La cajita en la que metemos todas las cosas buenas

    Hace unos meses estaba yo de cháchara con una de esas personas cracks y didácticas donde las haya y, por qué no, punta de lanza de la programación funcional en España :P. En un momento de la noche tuvimos la siguiente conversación:

    (yo) - ya, pero a mi la programación funcional no me resuelve cómo comunicarme con mi cliente. Ni cómo proveer la semántica que yo quiero a mi código, ni los malos entendidos, ni cómo hacer la build de mi sistema de manera automática...

    - claro que sí. Eso es programación funcional. "Tú eres un funciopata y ni lo sabías"...

    Entonces lo vi claro. "Para ti, la programación funcional es como para mi el _muchero_". Me explico...

    -- seguir leyendo --

  • Property Based Testing desde la perspectiva de la generación de datos

    Los test basados en propiedades utilizan un input generado "aleatoriamente" para ejecutar nuestros test. Para ello hace uso de un generador de datos. Pero, ¿se comportará nuestro código siempre de la misma forma con cualquier dato aleatorio? ¿Debemos tratar todos los posibles casos en nuestro test?

    -- seguir leyendo --

  • Introducción a Property Based Testing

    Este post va a ser una, no tan, breve introducción a la estrategia de test basados en propiedades. No voy a entrar en definiciones rigurosas ni en los ejemplos clásicos ya que en internet hay muchísimos otros artículos mucho más detallados y, seguramente, más interesantes que este. Este post, lo escribo como introducción a una serie en la que trataré de detallar cómo implemento, en mi día a día, mi suite de test apoyándome en esta estrategia. Como siempre que escribo, trataré de contar mis impresiones tras su implantación varios proyectos durante los últimos años, qué me ha funcionado y qué no.

    -- seguir leyendo --

  • El impacto de nuestras decisiones

    Por nuestro trabajo, tomamos una gran cantidad de decisiones a diario. La mayoría de las veces lo hacemos de manera inconsciente lo cual no es necesariamente malo. Pero creo que adquirir consciencia de este hecho puede tener dos beneficios fundamentales:

    • Saber comunicar las decisiones que hemos tomado al resto de las personas interesadas.
    • Al adquirir consciencia del impacto de nuestras decisiones inconscientes, a lo mejor nos da menos miedo tomar otras decisiones que antes no nos atrevíamos a tomar.

    -- seguir leyendo --

  • ¿Reescribir desde cero? Yo me lo pensaría dos veces

    A lo largo de mi carrera me han pedido reescribir desde 0 todo el proyecto en el que trabajaba al menos 4 o 5 veces. Voy a intentar contaros mi experiencia por si os puede resultar útil. Os adelanto las conclusiones por si no os apetece leer toda la retahíla. Para mi lo más importante de todo es que aprender a refactorizar y lidiar con código que nos da asco, nos aporta unos skills mucho más valiosos como desarrolladores que ser el hecho de ser la repera limonera escribiendo código nuevo.

    -- seguir leyendo --

  • Mi experiencia con las reescrituras de varios proyectos

    Os dejo aquí unas cuantas historias de abuelo cebolleta como parte de de mi reflexión sobre las reescrituras desde cero.

    -- seguir leyendo --

  • La epistemología ágil

    Se ha hablado mucho de las metodologías ágiles, de las dinámicas que pueden hacer que los equipos funcionen mejor. Se ha hablado también, aunque quizás con menos frecuencia, de los valores se predican desde el manifiesto ágil.

    En este post me gustaría hacer una reflexión sobre dos de las, en mi opinión, principales causas de frustración al intentar aplicar las metodologías ágiles.

    -- seguir leyendo --

  • Lo puedo hacer rápido o lo puedo hacer bien

    De todas las creencias del ideario informático, una de las que más me duele cuando la escucho es la archiconocida Lo puedo hacer rápido o lo puedo hacer bien. En este post intentaré explicar que no es bueno maximizar una cualidad (bien) en detrimento de las demás (rápido). O viceversa...

    -- seguir leyendo --

  • KISS y YAGNI en contexto

    Tras hablar de la importancia del contexto es el momento de ver cómo de útil es esto de la epistemología para decidir cuándo aplica y cuándo no.

    Así que quiero aprovechar este post para darle contexto a los principios KISS y YAGNI y así no acabar leyéndolos mal y jodiéndolos.

    -- seguir leyendo --

  • La importancia del contexto

    Cada cierto tiempo me entran muchas ganas de poner en orden mis pensamientos, recapitular sobre las situaciones que me encuentro en el día a día en mi trabajo y esta vez he pensado, ¿por qué no? voy a intentar plasmarlo en un post.
    De lo que quiero escribir hoy es de la importancia de contextualizar lo que aprendemos. Ya lo fui adelantando con posts como de leer libros mal y de joderlos o malos hábitos en un equipo de desarrollo software. Pero creo que por fin he encontrado una forma de expresarme mejor.
    Mi objetivo con este post es intentar transmitir unos conceptos básicos que nos permitan pensar y cuestionar muchas de las citas de autoridad que asumimos como ciertas en todo momento y que a veces podrían no aplicar.

    -- seguir leyendo --

  • Malos hábitos en un equipo de desarrollo software

    Pues después de un montón de tiempo sin escribir (y sin saber sobre que tema hacerlo) el otro día publiqué el que hasta el momento ha sido mi tweet más popular.
    Se habla mucho de la deuda técnica en el código. Sin embargo las mayores ñapas (y más costosas) yo las he visto en los hábitos.

    -- seguir leyendo --

  • Los singletons no son malos, es la sociedad que los corrompe

    Que levante la mano quien haya implementado en algún momento el patron singleton.
    Ahora que levante la mano quien no se haya arrepentido de esa decisión.
    Finalmente que levante la mano quien no vaya diciendo por ahí que el singleton es [evil|crap|el mal|un antipatron|…].
    Bien, si llevas un rato con la mano levantada es posible que seas parte de esa sociedad que corrompe a los pobres singletons.

    -- seguir leyendo --

  • De leer libros mal y de joderlos

    ¿Quién por aquí se ha leído el manifiesto ágil? ¿dónde pone que documentar es malo? ¿o que no se planifica nada? ¿por qué usamos la excusa de “somos ágiles” para saltaros la gran mayoría de las buenas prácticas que se han ido recopilando durante años?
    Y no solo quiero entrar en los aspectos y perfiles técnicos. Vamos a hablar también del Lean. Con su buque insignia Lean Startup. ¿Quién ha oído hablar de este libro/blog/web (no sé si llamarlo escuela directamente)?. ¿Alguno de vosotros lo ha leído? ¿Os suena el concepto de MVP?
    Llevo varias startups quebradas a mis espaldas. No demasiadas, pero si las suficientes como para acomplejarme un poquito y preguntarme, ¿tendré algo que ver yo en que la mitad de las empresas en las que he trabajado hayan quebrado?
    Bueno, pues en todas ellas he visto un montón de cosas en común y casi todas tienen bastante relación con libros mal leídos.

    -- seguir leyendo --

  • Lo fecal del desarrollo software

    No suelo escribir mucho y cuando lo hago trato de que sea algo útil para quien me lea. Algo que responda alguna duda, que ayude con algún problema… Esta vez escribo para desahogarme, para cuestionarme algunos temas que consideraba más que zanjados y para ver si escribiendo un poco pongo en orden mis ideas.
    Tampoco es que sea un perro viejo en este mundillo, mi vida laboral se remonta a unos 6 años y pico. Pero en este tiempo he tenido la suerte de pasar por al menos 7 empresas. He trabajado en un montón de proyectos, algunos los he empezado yo, otros he tenido el placer de continuarlos y otros la mala suerte de conocerlos.
    Voy a hablar de este último grupo de proyectos. Esos proyectos horrendos de esos que harían vomitar a una cabra. Me gustaría hablar de como se llega a esa situación y quien la promueve, quien la permite…

    -- seguir leyendo --

  • Tipos de Prueba

    Siguiendo con el hilo del anterior Post y en un intento por aclarar mis ideas intentaré resumir los tipos de pruebas. Seguramente haya tantas clasificaciones diferentes como Post sobre el tema podáis encontrar, no obstante creo que las ideas básicas coinciden.

    -- seguir leyendo --

  • ¿De verdad tanta gente hace TDD?

    Me quiero estrenar con esta entrada porque es una idea que me ronda la cabeza últimamente. No hago más que escuchar a compañeros hablar de TDD. Mucha gente que hace un mes no sabía lo que era la inyección de dependencias ahora predica, y hasta mira por encima del hombro asegurando que “yo no escribo ni una línea de código sin haber hecho un test antes”. Sinceramente me cuesta creerlo y lo que veo yo aquí es mucho “hipsterismo” y mucho “gafapastismo” y me suena un poco antinatural.

    -- seguir leyendo --