After almost 15 years in this profession, I have accumulated quite a few books that have influenced my thinking and approach to software development, as well as how I interact with others. I believe they're worth sharing.

There is now a new page on this site showcasing all the books I consider valuable enough to recommend (note: this is not an exhaustive list but rather a curated selection). To make it easier to browse, I've categorized them based on how they've shaped my thinking or how I've incorporated their ideas into my daily work.

Without further ado, the library!

Okay, so you are working on a new feature. Because your team operates using a pull request-based workflow, someone needs to review your code before it lands in the main branch and is released to all users. In the last retrospective, there was a lot of frustration among peers because code reviews usually take hours or even days to complete, and still, there is a lot of rubber-stamping or minor comments about code style (things that could be easily automated with better linters).

This time, you will try to approach it a bit differently and optimize for reviewing rather than your own immediate productivity (which gets hurt in the long term anyway due to delays in code review). Based on your experience as a reviewer, code reviews start to get complicated not when they involve many file changes but when they change multiple behaviors at the same time. For example, a pull request with 300 file changes where you're simply renaming a constant is much easier to review than a pull request with 4 file changes that modify four different system behaviors.

This time, you plan to slice your work in a way that you can create more than one single pull request, ensuring each pull request only introduces one new behavior into the system (a variable rename, a change to existing logic). The only problem with this approach is that no one on the team operates this way, and you are unsure whether it is possible to merge incomplete feature code into the main branch or if there is a way to hold off on all the changes but still allow for incremental reviews.

A few months ago, someone from the billing team shared a recent experiment using feature flags to turn on and off certain logic in production based on a configuration that’s easily accessed by a UI. Leveraging feature flags sounds like a sensible approach. That way, you could wrap all the new code under a feature flag that’s deactivated by default and only enabled once all pull requests have been merged into the main branch and the feature is code complete. But it seems the feature flag infrastructure is a bit experimental in the company, and you’re unsure whether it will be safe for your team to start relying on them.

But wait, there might be ways to achieve a similar code reviewing experience (note from the author: yeah, deploying code behind feature flags offers many more benefits than just facilitating code review, but that’s part of another series) by stacking pull requests. For example, you can create a first branch for your initial set of changes and then branch off again with the new set of changes. This second pull request will be based on the first branch instead of the main branch, so the diff is clear and only shows the new set of incremental changes.

Although stacking pull requests may become a bit tricky with large feature developments, it offers a good compromise for small to medium developments. You just need to make sure each new set of changes branches off from the previous branch. Then, each pull request will use the previous branch as the base branch for comparison. You don't need to merge each pull request independently; they are there just to facilitate the code review process. Once each step has been approved by your team, you can create a final pull request containing all the changes and use that to release the code. It's true the process accounts for some minimal duplication, but the benefits of having small, reviewable units persuade you to give it a try.

The only problem: you have never worked this way before, and typically, your feature development is a bit chaotic. Although you know the end goal, you’re usually figuring out the way to get there as you experiment with the codebase. This time, however, you may need a clearer plan to slice your work correctly for reviewing, following the principles you stated before (each pull request will only contain one change in behavior).

All your teammates have small differences in the way they approach feature development. Thinking about it for a second, you realize Sara uses something she calls an “Implementation Plan” and regularly posts it as a comment on the issue even before writing a single line of code. Reflecting a bit more, each step in Sara’s implementation plan typically matches the principles you’ve stated before: each pull request introduces only one new behavior into the system.

Deciding to follow Sara’s approach, you take a few hours to design a possible solution for the problem. There might be a few surprises along the way, but the implementation plan looks solid and has already given you some hints about how you may slice the problem. You have already identified a little refactoring you need to accomplish in the first instance that is better encapsulated in its own pull request so Jose, one of the experts on that part of the system, can take a look. Actually, now that you look at the plan, you realize it might be a good moment to ask Sofia, the tech lead for your team, to chime in so she can give you a thumbs-up now that you haven’t invested too much time in development. Working in smaller batches has already proven to be helpful even before creating the first pull request.

--

So, the little story above is just an example of how we may approach software development in a way that favors creating many small pull requests instead of a single one. Obviously, your mileage may vary, as may the experience around your team, but regularly incorporating this notion of 1 pull request = 1 behavior should facilitate both your development (because you’ll be working with less complexity at every step) and your code review process.

Implementation plans are just a technique that may help you divide your work in a way that makes sense and follows the principle we’ve stated before. They may also contribute to other benefits such as discovering potential blockers, incorporating feedback from your colleagues early in the process, or offering you some guidance as you move forward with the development.

We have already covered how stacking pull requests may work at a high level. Some tools support this kind of process by default (e.g., Phabricator via stacked diffs), but a similar workflow can be easily replicated in tools such as GitHub or GitLab (although the developer experience could be much better).

But as with almost everything in software, there isn’t a silver bullet. One drawback of slicing your work this way is that reviewers may find it more complex to see the whole picture of your changes. While this can be minimized by offering links to previous pull requests, having all your changes in a single pull request can make it easier for them to understand the context and scope. On the other hand, a large pull request with dozens of changes can also be overwhelming and, as we have discussed before, delay the overall reviewing process because reviewers need to deal with more complexity.

If you're looking for cost-effective ways to improve the code review process on your team, give stacked pull requests a try or, at the very least, aim to conform to the rule of one behavior change = one pull request.

Many companies use pull requests as a critical part of their software development process to achieve goals such as automated testing (via continuous integration services) and conducting code reviews.

In many cases, pull requests also serve as gatekeepers to production: someone from the organization (likely from the same team) needs to approve the changes for development to move forward. This process is often a source of frustration in software teams, where it is common to hear complaints about how long it takes for a pull request to be reviewed or the lack of constructive feedback received during code reviews.

On the other hand, reviewers often express frustration because pull requests are usually very large, making them difficult to review and thus more time-consuming. Still, many developers write code with a focus on their own productivity instead of optimizing for the later, required step of code reviewing.

In this series, I'd like to explore ways to make code reviews more productive for everyone: developers who want to receive constructive feedback while releasing software on time, and code reviewers who want to set a high-quality standard and use code reviews as a tool to leverage collective learning and knowledge sharing.

But first...

Pull requests, or pull request-based workflows, are just one option for collaborative work. I'm aware that other teams use more lightweight approaches, such as trunk-based development, where all commits are made directly to the main branch. This method relies on a highly sophisticated continuous integration infrastructure to validate each commit before it gets released.

There are also companies that focus heavily on pair or ensemble programming sessions, thereby reducing the need for asynchronous work. Still, highly distributed companies or teams that prefer a more asynchronous approach may choose pull requests to review code.

Ultimately, this series is not advocating for a pull request workflow but rather highlighting ways to make it more productive.

Read the full series

1. Many small pull requests
2. ...more coming soon!

Don’t make everybody busy from day one. Use the first stages of a software project to facilitate mob programming sessions and create a shared understanding.

Embrace some early duplication. Use the first few weeks to explore the problem space and try different approaches. Removing duplication is often easier than dealing with flawed architectures.

Optimize for short feedback loops. Trunk-based development, test-driven development, or continuous deployment are techniques that guide the team toward this objective.

For your initial test suite, optimize for confidence rather than speed (you can always fix performance later). That usually means creating more acceptance/integration tests than unitary ones. Also, tests of higher granularity levels help to develop test-friendly software systems.

When writing documentation, use how-to guides (how to execute a background job, how to log analytics events) and architecture decision records (so everybody can understand the WHY of certain design decisions).

Tackle the tasks with the most uncertainty first.

Simple !== Easy, but beware, they are often confused (perhaps because simple solutions are harder to design and implement).

Good software design always pays off.

Slice the work wisely. Rather than slicing by technical layers (for example, creating one task for front-end work and another for back-end work), use slices that make business sense and provide value (i.e., the minimum viable feature). Vertical slices enable shorter feedback loops and reduce integration problems.

If using a pull-requests-based workflow, avoid the notion of one feature = one pull request. Use stacked pull requests to generate smaller reviewable units.

Keep your options open, especially at the beginning. Use the Last Responsible Moment technique to drive your decision-making process.

Using component props to pass data (or JSX elements directly) that will later populate internal UI pieces has been a prevalent pattern in the React community, trying (probably) to emulate the better-designed slot approach adopted by Vue.

For example, imagine we are coding a new Nav component for our site. It will render a collection of nav items, the page title, and a call to action link. Each page might customize any of these elements.

Not surprisingly, I think either of these two would be the most popular examples we might find out there (or a combination of both):

// Passing simple data structures with the desired data
<Nav
  cta={{ text: "Buy the book!", href: "https://url.to/buy-my-book" }}
  menuItems={[
    { text: "Home", href: "/home" },
    { text: "About", href: "/about" },
    { text: "Contact", href: "/contact" },
  ]}
  title="My Site"
/>

// Passing JSX elements directly
<Nav
  cta={<a href="https://url.to/buy-my-book">Buy the book!</a>}
  menuItems={
    <>
      <li>
        <a href="/home">Home</a>
      </li>

      <li>
        <a href="/about">About</a>
      </li>

      <li>
        <a href="/contact">Contact</a>
      </li>
    </>
  }
  title={<h1>My Site</h1>}
/>

Even in such as simple example, we can start seeing some of the problems with this approach: it creeps the component API with render props, it is not very idiomatic, and it can quickly get worse as we continue adding some more customization for each element. For example, we may later add specific props to styling each of the items, title, and call-to-action components: menuItemStyle, titleStyle, ctaStyle, and so on:

<Nav
  cta={{ text: "Buy the book!", href: "https://url.to/buy-my-book" }}
  ctaStyle={{ color: "red" }}
  ctaOnClick={() => alert("Thanks for buying the book!")}
  menuItems={[
    { text: "Home", href: "/home" },
    { text: "About", href: "/about" },
    { text: "Contact", href: "/contact" },
  ]}
  menuItemStyle={{ color: "blue" }}
  onMenuItemClick={(href) => alert(`Navigating to ${href}`)}
  title="My Site"
  titleStyle={{ color: "green" }}
/>

Let’s try a different approach. One that resembles how HTML works and that is supported out-of-the-box by React.

Using children and dedicated components

<Nav>
  <Nav.Title>My Site</Nav.Title>

  <Nav.Menu>
    <Nav.Menu.Item href="/">Home</Nav.Menu.Item>
    <Nav.Menu.Item href="/about">About</Nav.Menu.Item>
    <Nav.Menu.Item href="/contact">Contact</Nav.Menu.Item>
  </Nav.Menu>

  <Nav.CallToAction href="https://url.to/buy-my-book">
    Buy the book!
  </Nav.CallToAction>
</Nav>

If you have done some React development, you probably know the children prop is how React passes content down to components (for example <p>Hola</p>, where p is the component, and Hola is the value of the children prop).

The example above uses children and composition extensively to render the desired UI. Instead of passing multiple props to the Nav component, we create many small, dedicated components which may of course receive their own props.

As a result, this approach gives us a much more flexible and idiomatic API. If we later need to add additional elements to the Nav component, we can do so without changing the Nav component at all (following the Open-Closed design principle).

On the other hand, using this technique comes with some drawbacks worth mentioning:

• We have to make it clear that these dedicated components are only meant to be used as children of the Nav component. We can do this by using the Nav namespace, for example: Nav.Title, Nav.Menu, and Nav.CallToAction.
• We must ensure the Nav component is flexible enough to handle the different cases we might want to render. For example, if we want to make it possible to render the Nav.Menu component either after or before the Nav.CallToAction component, the styles should be sufficiently sophisticated to handle both cases.

Possible implementation

Pay attention to how we export the Nav component and its dedicated components. That’s the secret sauce to namespace them and make it clear they are only meant to be used as children of the Nav component.

const Nav = ({ children }) => {
  return <nav>{children}</nav>;
};

const CallToAction = ({ children, href }) => {
  return <a href={href}>{children}</a>;
};

const Menu = ({ children }) => {
  return <ul>{children}</ul>;
};

const MenuItem = ({ children, href }) => {
  return (
    <li>
      <a href={href}>{children}</a>
    </li>
  );
};

const Title = ({ children }) => {
  return <h1>{children}</h1>;
};

Menu.Item = MenuItem;

Nav.CallToAction = CallToAction;
Nav.Menu = Menu;
Nav.Title = Title;

export { Nav };

Notes

• A few weeks after starting to write this post, I received a newsletter from Kent C. Dodds featuring a React article. Coincidentally, the content of the post covered precisely this! So, digging a little more, I found this pattern had been documented since a few years ago (watch out this video talk from Ryan Florence at Phoenix ReactJS Conf in 2017), and it is called Compound components.
• Radix UI uses this pattern extensively.
• If you’re curious, I used this pattern to build the whole landing page for my tddworkshop.com page. You can check the source code here.

Happy hacking!

If you have yet to hear about [software] design patterns, you may think of them as reusable solutions for everyday problems that work for different contexts. Of course, new design patterns appear now and then, but there is a well-documented core of patterns that are popular and can be seen in many object-oriented code bases. The Builder pattern is one of them.

Although this pattern may come in handy in multiple situations, it is especially helpful when creating test data. Tests for any medium-large-sized applications often require us to create various objects, put them in a particular state, and have relationships with other entities. That can be hard to do, especially if the objects are complex and we need to create many of them. The Builder pattern offers a solution to use a more semantic, domain-specific interface that makes the process easier.

For example, imagine we are coding a software system to help manage an automobile repair shop. Not surprisingly, we may find mechanics and cars. Mechanics can be responsible for multiple vehicles, be on holiday, and have different hourly salaries. The following tests verify that we cannot assign a car to a mechanic under certain circumstances.

import { Car, Mechanic } from "@domain";

describe("POST /mechanics/{id}/cars", () => {
  it("does not add a new car if the mechanic is on holiday", async () => {
    const mechanic = new Mechanic({
      id: 1,
      name: "Alice",
    });

    const today = new Date();

    const pto = new Pto({
      mechanic,
      startDate: startOfDay(today),
      endDate: endOfDay(today),
    });

    mechanic.ptos = [pto];

    await mechanicRepository.save(mechanic);

    const car = new Car({
      id: 1,
      make: "Mazda",
      model: "Mazda 3",
      year: 2021,
    });

    await carRepository.save(car);

    const response = await request(app)
      .post(`/mechanics/${mechanic.id}/cars`)
      .send({ carId: car.id });

    expect(response.status).toBe(400);
  });

  it("does not add a new car if the mechanic is working on five cars already", async () => {
    const mechanic = new Mechanic({ id: 1, name: "Alice" });

    mechanic.cars = [
      new Car({
        id: 1,
        make: "Mazda",
        model: "Mazda 2",
        year: 2021,
      }),
      new Car({
        id: 2,
        make: "Mazda",
        model: "Mazda 3",
        year: 2021,
      }),
      new Car({
        id: 3,
        make: "Mazda",
        model: "CX-30",
        year: 2021,
      }),
      new Car({
        id: 4,
        make: "Mazda",
        model: "MX-5",
        year: 2021,
      }),
      new Car({
        id: 5,
        make: "Mazda",
        model: "CX-60",
        year: 2021,
      }),
    ];

    await mechanicRepository.save(mechanic);

    const car = new Car({
      id: 6,
      make: "Mazda",
      model: "CX-9",
      year: 2021,
    });

    await carRepository.save(car);

    const response = await request(app)
      .post(`/mechanics/${mechanic.id}/cars`)
      .send({ carId: car.id });

    expect(response.status).toBe(400);
  });
});

As you may see in the code block above, creating all these objects by hand is expensive and makes the whole test hard to read. Let’s try instead to use a MechanicBuilder that makes the process easier while producing the same result.

import { MechanicBuilder, CarBuilder } from "@test/builders";

describe("POST /mechanics/{id}/cars", () => {
  it("does not add a new car if the mechanic is on holiday", async () => {
    const mechanic = await new MechanicBuilder()
      .onHoliday()
      .save(mechanicRepository);

    const car = await new CarBuilder().save(carRepository);

    const response = await request(app)
      .post(`/mechanics/${mechanic.id}/cars`)
      .send({ carId: car.id });

    expect(response.status).toBe(400);
  });

  it("does not add a new car if the mechanic is working on five cars already", async () => {
    const mechanic = await new MechanicBuilder()
      .withCars(5)
      .save(mechanicRepository);

    const car = await new CarBuilder().save(carRepository);

    const response = await request(app)
      .post(`/mechanics/${mechanic.id}/cars`)
      .send({ carId: car.id });

    expect(response.status).toBe(400);
  });
});

Reading the code above, we can clearly see the scenario we are creating for the test. The builder reduces verbosity and makes the code more expressive while favoring reusability for other test cases. Of course, we may keep adding methods to the MechanicBuilder as new requirements appear, so we always have an up-to-date, semantic interface to create Mechanic objects (and the same applies for Car instances).

Example of a Builder implementation using TypeScript

Wondering how you can create that fancy builder above using TypeScript? 😏 As with many things in software development, different paths may lead to the same result, but this approach worked very well for me in the past.

The Builder pattern is considered a creational pattern since it helps us create objects by removing all the complexity to instantiate them. So let’s start by creating a generic Builder<T> interface that defines the two methods all builders should implement: build (to return the object) and save (to persist the object in the database). I usually add a third method, with, that would allow us to pass an object with the properties we want to override. Still, for the sake of simplicity, I will skip it in this example.

export interface Builder<T> {
  build(): T;
  save(repository: Repository<T>): Promise<T>;
}

Then, we may create a BaseBuilder<T> abstract class that implements the Builder<T> interface and provides a default implementation for both methods. The build method will return the object, while the save method will return the object and persist it in the database. Here, we use inheritance just for code reusability.

import { Builder } from "@test/builders";

export abstract class BaseBuilder<T> implements Builder<T> {
  protected abstract entity: T;

  public build(): T {
    return this.entity;
  }

  public save(repository: Repository<T>): Promise<T> {
    return repository.save(this.entity);
  }
}

Finally, we can create the MechanicBuilder simply by extending BaseBuilder<Mechanic> and providing all the additional methods.

import { Mechanic } from "@domain";
import { BaseBuilder, CarBuilder, PtoBuilder } from "@test/builders";

export class MechanicBuilder extends BaseBuilder<Mechanic> {
  protected entity: Mechanic;

  constructor() {
    super();

    this.entity = new Mechanic({ id: 1, name: "Alice" });
  }

  public onHoliday(): this {
    this.entity.ptos = [
      new PtoBuilder().for(this.entity).on(new Date()).build(),
    ];

    return this;
  }

  public withCars(count: number): this {
    this.entity.cars = new Array(count)
      .fill(null)
      .map(() => new CarBuilder().build());

    return this;
  }
}

Note how we return this in the onHoliday and withCars methods. That is the secret sauce to making the Builder provide a fluent interface so that we can use it in the following way:

const mechanic = await new MechanicBuilder()
  .onHoliday()
  .withCars(5)
  .save(mechanicRepository);

Happy hacking!

Really Simple Syndication (RSS) has been a pretty popular format for syndicating and publishing content on the web. Still, platforms don’t usually provide an out-of-the-box solution to adopt it.

For Next.js projects, specifically, I’m sure there are probably thousands of articles explaining how to do it (and probably a handful of npm packages, too!), but in this post, I will try to outline my own approach to this problem to add RSS capabilities for this very same blog.

How to build the RSS feed

The only thing I didn’t want to do was study the RSS or Atom spec myself to know how to create a valid document. For that reason, I browsed the web looking for a well-maintained npm package that could help me externalize part of the work.

jpmonette/feed ticked all the boxes (some recent commits, a good amount of stars, and TypeScript support), so I installed the package and started coding the RssFeedGenerator class.

The RssFeedGenerator is a simple TypeScript class that receives an array of paths and gets all the posts that live there. Then, it makes minor adjustments (flat the collection of posts, order by date) and uses the jpmonette/feed package to return a valid atom feed string. Since this blog is open-sourced, you may see the actual code for this class in codecoolture/codecoolture.com.

export class RssFeedGenerator {
  constructor(private paths: string[]) {}

  public async generate(): Promise<string> {
    const feed = new Feed({
      /* Add some feed configuration */
    });

    const allArticles = await Promise.all(
      this.paths.map(async (path) => {
        const repository = await MarkdownRepository.fromDirectory(path);

        return repository.all({ drafts: false });
      }),
    );

    const articlesFromNewestToOldest = orderBy(allArticles.flat(), "date", [
      "desc",
    ]);

    for (const article of articlesFromNewestToOldest) {
      feed.addItem({
        /* Add properties for each item */
      });
    }

    return feed.atom1();
  }
}

The RssFeedGenerator does not know by itself what the paths are, so it expects them to be injected during initialization. This decision was driven by my approach using test-driven development since I wanted to create different fixtures to test different scenarios without relying on the actual production data (posts may change title, date, or even get deleted!).

Design-wise, injecting the RSS feed generator would also be desirable, so we could rely on our own abstractions rather than having this code coupled to a third-party library. Still, the use case is so simple that I decided to skip the extra work (I hope it does not bite me in the future!).

How to integrate RssFeedGenerator with Next.js

At this point, this site uses next export to build a static website. Therefore, I couldn’t rely on some of the more advanced Next.js features such as API Routes or even middlewares. So instead, I decided to integrate the RSS feed generation within the Next.js build by adding a new npm script that executes bin/rss/index.ts (a TypeScript script) and creates a RssFeedGenerator instance with the right content paths, using its output to save a file inside the Next.js public/ folder. This is what the script and the new build command look like.

-    "build": "next build",
+    "build": "yarn build:rss && next build",
+    "build:rss": "NODE_ENV=development yarn ts:exec ./bin/rss/index.ts",

import { writeFile } from "node:fs/promises";
import { join } from "node:path";
import { getConfig } from "../../config";
import { RssFeedGenerator } from "./RssFeedGenerator";

(async function run() {
  const generator = new RssFeedGenerator([
    getConfig().writing.articles,
    getConfig().writing.notes,
  ]);

  const feed = await generator.generate();

  await writeFile(join(__dirname, "../../public/feed.xml"), feed);
})();

With all these pieces now working together, new deployments of this site will always create a valid RSS feed that can be found at /feed.xml, keeping the static nature of the website and leveraging a more sophisticated build process.

What do you think if we make good use of this new feature and subscribe to the RSS feed? 😃

Career Framework

Una buena parte de este tercer trimestre la dediqué a diseñar una primera iteración del career framework para el equipo de ingeniería de PrivacyCloud. Muchas empresas tecnológicas tienen públicos estos documentos así que, como no podía ser de otra manera, aproveché la oportunidad para leer un montón de ellos, aprender y tratar de implementar uno que recogiese con acierto nuestras expectativas de cada rol (siempre, claro, adaptadas al propio contexto y cultura del equipo y la empresa).

Además de un índice muy útil como progression.fyi, os dejo por aquí los cinco ejemplos que más me han gustado (tanto por su filosofía, como por su explicación y diseño de cada camino y nivel).

• Career Ladders by Sarah Drasner: es un punto de partida fantástico para diseñar un career ladder para un equipo de ingeniería: define cada rol con 4-5 puntos que ejemplifican los comportamientos y expectativas, huye de la trampa de un checklist y explica con bastante acierto cómo encaja el rol de Tech Lead (en mi experiencia, muy ambiguo) en todo esto.
• Engineering levels at Carta: lo más interesante son las partes donde explican el razonamiento y filosofía detrás de su framework (fairness, compensation, career progression).
• Dropbox Engineering Career Framework: su definición de impacto y cómo articulan todo el framework alrededor de este concepto.
• Engineering Levels at SoundCloud: es bastante conciso y me ha ayudado a no irme por las ramas (keep it simple).
• CircleCI Engineering Competency Matrix: es, de los cinco, el que mayor exhaustividad muestra a la hora de definir las compentencias en diferentes niveles. Personalmente, no he seguido su enfoque, pero me ha ayudado a perfilar algunas ideas.

Si quieres echar un vistazo al Career Framework de PrivacyCloud, escríbeme, cuéntame un poco sobre ti y estaré encantado de enviarte una copia!

🛠 Código

• searls/todo_or_die: no sé si sería buena idea utilizarlo en una proyecto real pero me ha encantado la idea: ¿qué te parece si esos TODO que NUNCA resuelves empiezan a lanzar excepciones pasados N días? 😄

class UsersController < ApiController
  TodoOrDie("delete after JS app has propagated", by: "2019-02-04")
  def show
    redirect_to root_path
  end
end

• radix-ui/colors: me gusta crear interfaces usables, accesibles y bonitas a pesar de no tener conocimientos de diseño (más allá de los adquiridos con la experiencia), así que recursos como este siempre me parecen oro. Radix UI tiene un módulo de colores que puedes instalar de manera independiente y que, más allá de tener unas escalas muy bonitas, tiene una documentación ❤️ que te ayuda a decidir qué tonos tienes que utilizar en cada momento (como fondo cuando el elemento tiene el :hover, como borde cuando el elemento no es interactivo, como color de texto, etc.). Simplemente funciona.

🎱 Bola extra: Love, Death & Robots

Netflix produce esta pequeña joya de animación. Son 2 temporadas con capítulos muy cortos (algunos no duran más que unos pocos minutos) que muestran diferentes distopías donde, cada vez más, los humanos tienen que compartir su vida con avances tecnológicos de todo tipo.

Qué mejor manera de arrancar el verano que con una buena colección de enlaces y recursos interesantes 😃

💻 Blogposts

• An incomplete list of skills senior engineers need, beyond coding: típico ejemplo de post cortito pero con mucho contenido para reflexionar. Y es que medir el seniority únicamente por las habilidades técnicas es simplificar demasiado el impacto que podemos debemos tener.
• About Derek Sivers: bueno, no es exactamente un blogpost pero... esta página en la web de Derek Sivers me ha gustado mucho, especialmente después de haber leído su libro (Anything You Want -como comenté en el anterior Quarterlinks). Sin duda, Derek es una persona con las ideas muy claras y una manera de entender el trabajo (y la vida) muy interesantes. Revisando también su lista de libros favoritos, me he encontrado con varios libros que he leído también en los últimos meses: The Obstacle Is the Way de Ryan Holiday, Mindfulness in Plain English de Bhante Gunaratana o Meditations de Marco Aurelio.
• I could build this during the weekend: ¡culpable! Sirva este post como recordatorio de todas las complejidades subyacentes a la hora de desarrollar un negocio y un producto digital.
• My thoughts about the Principal role: es un rol que aparece en empresas de gran tamaño y del que no había leído (aún) demasiado.
• JWT should not be your default for sessions: food for thought! Y es que a veces las opciones que asumimos por defecto pueden tener trade-offs de los que no estamos al tanto.
• Defining the Value Proposition on a co-creative dynamic with Sales & Product: me ha gustado este post de Álvar Montes explicando las dinámicas que facilitó en un offsite de los equipos de ventas y producto en OnTruck.

🛠 Código

• google/zx: este proyecto open source de Google me ha parecido súper interesante. Últimamente, todos mis scripts ya los escribía con Node y zx propociona abstracciones amigables para lidiar con funciones habituales de más bajo nivel.

📚 Libros

• An Elegant Puzzle: Systems of Engineering Management: en este libro, Will Larson (Digg, Stripe, Uber) condensa mucha de su experiencia liderando equipos de ingeniería en forma de anécdotas, fórmulas, estrategias, prácticas y consejos. Es un libro de múltiples lecturas. De momento, he terminado una primera de principio a fin, pero voy a tenerlo bien cerquita para consultarlo cuando me enfrente a próximos retos.

🎱 Bola extra: El método Kominsky

22 capítulos de menos de 30 minutos cada uno (¡se ven como nada!), repartidos en 3 temporadas. Está disponible en Netflix, y está protagonizada por Michael Douglas en el papel de un profesor de interpretación que otrora tuvo poco éxito como actor. La verdad es que me he reído mucho con El método Kominsky. En cierto modo ha sido como ver a Hank Moody, de Californication, 30 y pico años más viejo (y con un punto menos canalla).

Como de costumbre, vamos allá con algunos enlaces interesantes del pasado trimestre.

💻 Blogposts

• Basal Cost of Software: Edu Ferro nos habla del coste que tiene para el sistema el acumulado de funcionalidad a medida que avanza la vida de un producto.
• Small batches for the win / Continuous Delivery: uno de los conceptos clave para entender (e implementar) continuous delivery: trabajar en pasos pequeñitos, pero de manera continua (de esa manera, podemos obtener feedback más rápido a la vez que minimizamos los riesgos).
• No Meetings, No Deadlines, No Full-Time Employees: muy interesante conocer la filosofía de trabajo en Gumroad, contada en primera persona por su CEO: Sahil Lavingia.
• What Makes A Strong Product Culture?: empoderar equipos de producto... si llevas siguiendo esta sección durante los últimos meses, habrás visto que siempre cae una pieza sobre este tema.
• 10 bad TypeScript habits to break this year: soy culpable de alguno de los malos hábitos que se detallan en el artículo. Desde hace meses estoy luchando activamente por evitar al máximo los puntos 4 y 5.
• Your engineering team is (probably) too big: quizás (?) el enlace más controvertido. Siempre es interesante recordar que es posible conseguir muchas cosas con equipos relativamente pequeños (en el artículo se cita a Notion, con más de 1 millón de usuarios, siendo una empresa de 10 personas).

📚 Libros

Os dejo un par de libros que me han parecido muy interesantes y que se leen rápidamente:

• Measure What Matters: John Doerr, que trabajó durante buena parte de su carrera junto a Andy Grove, nos explica OKRs a través de la experiencia de múltiples empresas que lo han adoptado de manera exitosa (Google, YouTube, Gates Foundation).
• Anything You Want: Derek Sivers nos cuenta, en primera persona, su aventura creando CD Baby, una empresa que en el año 1997 empezó a vender música por Internet de artistas independientes (cuando sólo se podía acceder al circuito a través de las grandes distribuidoras). Una ejecución brillante y una manera poco convencional de entender la empresa y el trabajo.

🎱 Bola extra: Leftovers

Tenía en el radar esta serie de HBO desde hace tiempo, pero no fue hasta finales de 2020 cuando me lancé a empezarla. De digestión lenta, quizás el final es un tanto acelerado para el ritmo habitual de la serie, pero yo la disfruté tanto que terminé por votarla con un 9 en FilmAffinity.

Imagine you are coding a new React component to upload a file. The component will receive a callback to notify the app if the upload has been or has not been successful. You may end with something similar to:

/**
 * We will use the `executor` function to simulate different
 * scenarios from our tests.
 */
function UploadButton({ executor, onSuccess }) {
  return (
    <button
      type="button"
      onClick={async () => {
        await executor();

        onSuccess();
      }}
    >
      Upload
    </button>
  );
}

To test the most simple scenario, that the <UploadButton /> component uses the callback once the upload is completed, we can rely on the standard approach:

it("uses the callback to notify that the upload completed", async () => {
  const spy = jest.fn();

  render(<UploadButton executor={success} onSuccess={spy} />);

  user.click(screen.getByText("Upload"));

  await waitFor(() => {
    expect(spy).toHaveBeenCalledTimes(1);
  });
});

But things are more complicated if we want to ensure that the onSuccess callback is not executed if something unexpected happens and the process fails. The initial and most naive implementation might be to assure that the spy is never called when using the failing executor:

it("does not use the callback if something goes wrong", async () => {
  const spy = jest.fn();

  render(<UploadButton executor={fail} onSuccess={spy} />);

  user.click(screen.getByText("Upload"));

  await waitFor(() => {
    expect(spy).toHaveBeenCalledTimes(0);
  });
});

Even if it passes, the test is not checking that the spy never gets called. Since the executor is an asynchronous process, and the spy starts with zero calls, the expectation is valid immediately. You can spot this by replacing executor={fail} with executor={success} --that’s the kind of change that should make the test have a different result, but it continues passing!

To test this scenario, we need to come up with a different approach:

it("does not use the callback if something goes wrong", async () => {
  const asyncRender = new Promise<undefined>((resolve, reject) => {
    render(<UploadButton executor={fail} onSuccess={reject} />);

    user.click(screen.getByText("Upload"));

    setTimeout(resolve, 0);
  });

  await expect(asyncRender).resolves.toBeUndefined();
});

By embracing the asynchronous nature of this problem, we can wrap the rendering within a promise and use its reject function as the onSuccess callback. Remember that promises execute immediately but return a delayed response. To give some room for the component to fail, I use the setTimeout trick to force the process to complete pending tasks from the queue.

Now, asyncRender should always resolve (with an undefined value). If it does not, our component is having issues handling the onSuccess callback and calling it even when the upload fails (since it is what the failing executor does). If you change executor={fail} to executor={success}, you may see the result keeps consistent, and the test fails.

Vamos con la colección de recursos interesantes leídos durante octubre, noviembre y diciembre del pasado (¡por fin!) 2020.

💻 Blogposts

• Forms best practice: esta guía escrita por Geri Reid se ha convertido en mi sitio de referencia a la hora de construir formularios en aplicaciones web. Hay dos cosas que me gustan especialmente: 1) que está repleta de opiniones 2) que todas las opiniones están contrastadas con diversos estudios y ejemplos del mundo real.
• Packlink engineering vision for 2021: quienes sigáis esta serie de posts de manera habitual sabréis que me gusta mucho leer artículos donde empresas tecnológicas publican datos de su día a día, tecnologías que utilizan, objetivos, estrategia, etc. Pues este artículo escrito por Packlink tiene un poco de todo lo anterior.
• Write five, then synthesize: good engineering strategy is boring: muy relacionado con el artículo anterior, aquí se reflexiona sobre cómo escribir una buena estrategia, por qué es importante y qué primeros pasos podemos dar para arrancar con todo ello (en forma de heurístico).
• How to Write Well: 4 Steps to Improve Your Writing: y como la cosa va de escribir... lo suyo es hacerlo lo mejor posible, ¿no?
• Dual-Track Agile: no es el artículo más completo para explicar dual-track pero sí es una buena introducción (además de ser, posiblemente, la primera referencia escrita). Sin ser perfecto, es un marco de trabajo que puede funcionar a la hora de construir un equipo de producto donde las diferenes patas de la organización (product management, product design, engineering) se sientan representadas y con libertad para moverse entre tareas de diferentes naturalezas.

🎙 Podcasts

• Producto desde el minuto 0, con Javier Escribano: me ha gustado mucho escuchar a Javier Escribano explicar el proceso de desarrollo de producto en OnTruck. Además, con algún ejemplo concreto de cómo es el proceso de conceptualización de una funcionalidad.
• Product Teams con Edu Ferro: siempre es un gusto escuchar a Edu Ferro hablar de tecnología y desarrollo de software. ¿Que os podéis encontrar? Entrega continua de software, desarrollo de producto, excelencia técnica... en definitiva, 1 hora y 40 minutos muy bien invertidos 🙂

🃏 Comodín

• How Notion Uses Notion. Vale. Lo reconozco. Este artículo NO lo leí durante el último trimestre de 2020 pero se me olvidó compartirlo en su momento 🤦‍♂️ Es un artículo muy meta donde Notion explica qué uso hace de su plataforma y cómo organizan la información. Yo me he cogido unos cuantos trucos. Especialmente sobre su gestión de la documentación.

Aunque ya he escrito en otras ocasiones sobre feature flags y como su uso nos puede ayudar a alcanzar un flujo de entrega continua, en este artículo me gustaría compartir una implementación sencilla en React utilizando TypeScript.

En esencia, una feature flag es un interruptor que nos permite activar o desactivar una funcionalidad concreta bajo una serie de condiciones. Los tipos de condiciones pueden ser muy variados: entorno de ejecución de la aplicación, tipo de usuaria, porcentaje de tráfico, etc. Además, el cálculo de esa condición puede realizarse dentro de la propia aplicación, o bien delegarse en otro sistema.

Este concepto posibilita, entre otras cosas, desacoplar nuestro repositorio del proceso de entrega de software. Siempre y cuando nuestras funcionalidades incompletas estén protegidas bajo una feature flag, podremos integrar continuamente nuestros cambios en la rama principal (aunque eso implique su despliegue a producción o cualquier otro entorno).

Publicando feature flags

El primer paso para comenzar a utilizar feature flags es definirlas en algún sitio. Aunque existan servicios específicamente creados para trabajar con ellas (que, además, ofrecen flujos y procesos mucho más refinados), yo siempre recomiendo comenzar con un enfoque humilde, gestionando las feature flags directamente en la aplicación. En este caso, vamos a crear un módulo que exporte las diferentes feature flags y una función para obtener su estado:

export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};

La única razón de asociar una función a la feature flag en lugar de directamente un booleano es dotarle de cierta flexibilidad (realmente, sería incluso más interesante hacer que la función devolviese una promesa -de esa manera, estaríamos cubriendo el caso en el que, para calcular el valor de una feature flag, tuviésemos que realizar una petición a un servicio externo).

Integrando la aplicación React con las feature flags

Ahora que ya tenemos un módulo encargado de publicar las feature flags de la aplicación, es hora de hacerlo accesible desde los componentes React.

El enfoque más directo, sería importar el módulo desde las diferentes páginas o componentes que lo utilicen y realizar después las operaciones para mostrar/ocultar alguna parte de la interfaz. Aunque este enfoque funcionaría estaríamos creando una dependencia no explícita entre nuestros diferentes componentes y un elemento global (el módulo de Features) lo que hará que probar nuestros componentes en cada uno de los estados sea más complejo.

Vamos a verlo con un ejemplo:

import { Features } from "../lib/Features";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {Features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}

En esta implementación, Menu utiliza directamente el módulo de Features para saber si tiene que mostrar o no la opción de ajustes. A la hora de probar este componente, tenemos que tener en cuenta esta dependencia y utilizar un stub para poder ajustarlo a ambos escenarios:

/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Features } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    jest.spyOn(Features, "newSettingsPage").mockImplementationOnce(() => true);

    render(<Menu />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});

Los stubs (o test doubles en general) son recursos muy útiles pero me gusta reservar su uso para situaciones donde no tengo ninguna otra opción más idiomática para probar el sujeto bajo test. En este caso, lo ideal sería convertir esa dependencia no explícita en algo que pudiésemos controlar desde el exterior, utilizando inyección de dependencias. En React, tendríamos varias opciones para conseguirlo. Veamos un par de ellas.

Obtener las feature flags a través de una prop

Por ejemplo, utilizando una prop features para poder recibir el objeto completo de feature flags. El problema con este enfoque es que podría haber muchos componentes intermedios que necesiten propagar esta prop sin necesidad de utilizarla. Este fenómeno se denomina Prop Drilling y, aunque no es malo per se, puede convertirse en algo difícil de gestionar cuando nuestra aplicación crezca en número de componentes.

import { Features } from "../lib/Features";

export function Menu({ features }: { features: typeof Features }) {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}

Ahora que el componente Menu obtiene la información de las feature flags a través de una prop, podemos ajustar los diferentes escenarios para las pruebas sin necesidad de utilizar test doubles:

/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu features={{ newSettingsPage: () => false }} />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(<Menu features={{ newSettingsPage: () => true }} />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});

Obtener las feature flags a través de la API de contextos

Bien utilizada, la API de contextos de React puede servir como un contenedor de inyección de dependencias que permita aislar a los componentes padre de las dependencias concretas de sus componentes hijo. En este caso, vamos a crear un nuevo contexto que publique las feature flags disponibles dentro de la aplicación y que permita acceder a ellas a través de un hook concreto, useFeatures.

Lo primero, es definir el propio contexto encargado de devolver las feature flags existentes. Junto a él, también definiremos el hook que se utilizará después desde nuestros componentes. Este último es una simple capa de abstracción que centraliza la lógica común de acceso.

import { createContext, useContext } from "react";

export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};

export const FeaturesContext = createContext(Features);

export function useFeatures() {
  return useContext(FeaturesContext);
}

Los contextos en React se crean con un valor por defecto. En caso de que no exista ningún proveedor que sobrescriba el valor para el contexto, nuestros componentes recibirán ese valor al acceder a él. En este caso, hemos creado el contexto utilizando como valor por defecto el propio objeto exportado por Features.

import { useFeatures } from "../lib/Features";

export function Menu() {
  const features = useFeatures();

  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}

Ahora que nuestro componente Menu utiliza el nuevo contexto, sólo necesitamos envolver el componente en diferentes proveedores cuando queramos probar distintos escenarios:

/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { FeaturesContext } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => false }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => true }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});

<FeatureFlag />, un componente para abstraernos por completo

Si utilizamos la API de contextos, podemos ir todavía un paso más allá y abstraernos por completo de la gestión de funcionalidades disponibles. En este caso, vamos a crear un componente FeatureFlag que recibirá la flag sobre la que queremos trabajar y los nodos que queremos ocultar en caso de no estar disponible:

import { ReactNode } from "react";
import { Features, useFeatures } from "../lib/Features";

type FeatureFlagProps = { children: ReactNode; flag: keyof typeof Features };

export function FeatureFlag({ children, flag }: FeatureFlagProps) {
  const features = useFeatures();

  if (features[flag]()) {
    return <>{children}</>;
  }

  return null;
}

Al definir la prop de flag como keyof typeof Features estamos tomando ventaja de la ayuda del compilador de TypeScript, que nos dirá automáticamente que funcionalidades existen y evitará que utilicemos flags que no se encuentran en el objeto global de Features.

import { FeatureFlag } from "./FeatureFlag";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        <FeatureFlag flag="newSettingsPage">
          <li>
            <a href="/settings">Settings</a>
          </li>
        </FeatureFlag>
      </ul>
    </nav>
  );
}

Con este último enfoque, nuestras pruebas anteriores utilizando el proveedor del contexto de feature flags seguirán funcionando (ya que es el mecanismo sobre el que se construye todo) a la vez que tomamos ventaja de un diseño mucho más idiomático, encapsulando la gestión de feature flags en su propio componente React.

Reflexionando sobre mi trabajo los últimos años, donde he tenido que cumplir con ese rol dual de liderazgo técnico (tech lead, lead engineer) y manager de equipos (engineering manager, vp of engineering) en startups con equipos de producto e ingeniería pequeños (máximo 10-12 personas), me doy cuenta de que lo más valioso que he conseguido ha sido facilitar espacios de reflexión, discusión y aprendizaje continuo.

¿A qué me refiero cuando hablo de espacios? Realmente, a nada físico o temporal, sino a una manera de entender el trabajo del equipo y sus actividades en el día a día. En muchas ocasiones, especialmente en los contextos en los que yo me he desarrollado, nos vemos atrapados en un ritmo frenético de trabajo (con el objetivo de demostrar la viabilidad de la empresa, buscar su product market fit, conseguir una nuevo cliente, etc.) y ese rodillo puede sepultar las capacidades del equipo para abstraerse y ganar la perspectiva necesaria para servir como motor de cambio y mejora continua. Aunque seguro que no únicamente en startups se vive con prisa, ¿verdad? 🙂

Mis iniciativas en este ámbito han orbitado siempre en torno a los siguientes 3 puntos:

• Utilizar cada tarea (story, feature) como una oportunidad única para aprender: como desarrollador, no hay curso o taller que me haya enseñado más que el propio día a día escribiendo código y desafiando mi propia manera de hacer las cosas una y otra vez en búsqueda de soluciones alternativas que sean mejores (más sostenibles, escalables). Introducir en el equipo el mindset de que cada nueva tarea es una oportunidad para aprender y experimentar requiere tiempo, y constancia (y, especialmente, ¡no desdecirte a las primeras de cambio!), pero estás contribuyendo a crear un espacio de aprendizaje continuo en el día a día.
• Utilizar cada code review como un espacio de discusión: este espacio viene casi de gratis, ya que no son pocos los equipos que tienen integrado en su día a día la revisión de código a través de pull/merge requests. Me gusta fomentar un entorno donde las revisiones de código no sean únicamente un trabajo de revisión (valga la redundancia) sino que se utilicen como un instrumento de aprendizaje y conversación. Evidentemente, con matices, ya que no todas las merge requests contienen cambios tan interesantes como para generar un debate a su alrededor. Del mismo modo, no todos los debates merecen bloquear una merge request, por lo que debería ser natural continuar una discusión incluso habiendo fusionado ya los cambios propuestos (¡o incluso arrancar la discusión con la merge request ya cerrada!).
• Crear eventos recurrentes PARA el equipo: y aquí hablo únicamente de mi experiencia trabajando en empresas de producto. Hay pocas cosas que generen más inercia que un compromiso explícito por parte de la empresa en desarrollar una cultura de aprendizaje continuo. Sin necesidad de negociar cosas (tan importantes) como presupuestos de formación, es posible realizar pequeñas inversiones a través de actividades como clubs de lectura (una hora a la semana -¡en PrivacyCloud lleva funcionando desde 2017!), meetups internos donde integrantes del equipo puedan compartir hitos, realizar presentaciones sobre aprendizajes de las últimas semanas, ver alguna charla juntas, practicar una kata...

Y de manera tangencial...

• En mi experiencia, invertir tiempo en tener ciclos de feedback (muy) cortos fomenta sin lugar a dudas espacios de experimentación dentro del equipo. A todos los niveles. Si poner cambios en producción se puede hacer de manera autónoma, rápida y confiable, me animaré seguro a validar diferentes hipótesis lo antes posible. Si se cuenta con rituales como retrospectivas (en un contexto donde se puedan realizar de manera honesta) cada 1-2 semanas, abrazaré el cambio con mayor seguridad, ya que podré ir revisándolo cada poco.
• Las pull requests son un compromiso en el camino por alcanzar un trabajo 100% colaborativo (a través de pair o mob programming -dinámicas que aún no he conseguido interiorizar completamente ni ver aplicadas de manera recurrente en ningún equipo en los que he trabajado, pero que me encantaría). Razón de más para aprovechar esos tiempos de revisión para crear nuevos espacios de discusión.

Este artículo fue publicado originalmente en la edición de 2020 de Octuweb.

En la edición de 2018 Cristina Ponce publicó Testing en el front, una guía sobre los diferentes tipos de pruebas que podemos realizar en aplicaciones front-end. Apoyándonos en ese artículo, vamos a hablar aquí de cómo aprovechar la nueva generación de herramientas para alcanzar flujos de desarrollo que, hasta hace solo unos años, no eran (tan) fácilmente aplicables en este contexto: Test-Driven Development (o TDD).

Pero primero, ¿qué es TDD?

Test-Driven Development es una metodología que se basa en aplicar pequeños ciclos de desarrollo con el objetivo de resolver casos de prueba. De manera más concreta, lo podemos definir en 3 pasos:

1. Codificar una prueba que defina el nuevo comportamiento que queremos añadir a nuestro sistema
2. Escribir la menor cantidad de código posible que nos permita hacer pasar el test anterior
3. Mejorar el código anterior utilizando las pruebas como red de seguridad (a.k.a refactoring)

En TDD clásico, lo habitual es comenzar por las entidades más internas de nuestro sistema para ir construyendo capas una encima de otra hasta terminar de implementar la funcionalidad. En front-end sin embargo, y con las herramientas actuales, lo más natural es utilizar una variación denominada ATDD (inspirada en Outside-in, un enfoque de TDD que se originó en la comunidad de eXtreme Programming de Londres), donde se empieza creando un primer test en la capa más externa del sistema (en este caso, la interfaz o un componente) para ir construyendo desde ahí el resto de la funcionalidad.

Escribiendo nuestro primer test

En su sentido más estricto, TDD es una herramienta de desarrollo (un flujo de trabajo, una metodología) y no tiene que verse como un instrumento de calidad (entendiendo esta como la disciplina para el control de defectos). Por tanto, su objetivo es ayudar a las programadoras a entregar valor lo antes posible, con confianza. En ATDD, por ejemplo, el primer test nos tiene que permitir poner el foco en el problema que vamos a resolver y servirnos como guía durante el desarrollo de la funcionalidad. Lo habitual es intentar reflejar en este primer test los criterios de aceptación que perseguimos cumplir con la historia de usuario en curso.

Por ejemplo, supongamos que estamos trabajando en el front-end para la web de una editorial de libros y queremos añadir una página de contacto:

Es posible acceder a una página de contacto para, indicando email, asunto y mensaje, ponerse en contacto con la editorial. Una vez completada la operación, se realizará una redirección a una página de éxito con un mensaje que indique que todo ha ido bien.

Hay disponible un endpoint /api/contact que completa la operación en el back-end.

Utilizando Cypress, podemos trasladar esta descripción a una prueba de alto nivel como la siguiente:

// Location: cypress/integration/sendContactMessage.test.ts

context("sendContactMessage", () => {
  specify("A user can send a contact message", () => {
    // Setup
    cy.server();
    cy.route2("/api/contact", { statusCode: 200 });

    // Act
    cy.visit("/contact");
    cy.findByLabelText(/tu email/i).type("hola@codecoolture.com");
    cy.findByLabelText(/asunto/i).type("Información sobre próximos libros");
    cy.findByLabelText(/mensaje/i).type(
      "Hola, me gustaría obtener más información sobre próximos libros.",
    );
    cy.findByText(/enviar/i).click();

    // Assert
    cy.url().should("eql", Cypress.config().baseUrl + "/contact/success");
    cy.findByText(/tu mensaje ha sido enviado con éxito/i).should("exist");
  });
});

La prueba anterior codifica el escenario de aceptación básico: primero, hacemos que Cypress simule la respuesta al endpoint /api/contact para indicar que todo ha ido bien (devolverá un código 200), y después interactuamos con la aplicación para ir a la página de contacto y completar el formulario. Por último, validamos que se ha llevado al usuario a la página de éxito tras enviar el formulario.

Ahora que hemos visto un ejemplo, seguramente nos sea más sencillo explicar qué es Cypress: un framework de testing para construir pruebas de aceptación sobre un navegador, utilizando JavaScript.

En el ejemplo anterior, la prueba se ejecutará sobre nuestra propia aplicación. En este caso, como todavía no hemos escrito código de producción, lo que esperamos es que el test falle. Es ahora cuando tenemos que escribir la mínima cantidad posible de código para que este test pueda pasar.

// Location: pages/contact.tsx

export default function Contact() {
  return (
    <main>
      <Formik
        initialValues={{ email: "", subject: "", message: "" }}
        onSubmit={async ({ email, subject, message }) => {
          const response = await fetch("/api/contact", {
            body: JSON.stringify({ email, subject, message }),
            headers: { "content-type": "application/json" },
            method: "post",
          });

          if (response.ok) {
            window.location.href = "/contact/success";
          }
        }}
      >
        {() => {
          return (
            <Form>
              <label>
                Tu email <Field id="email" name="email" />
              </label>

              <label>
                Asunto <Field name="subject" />
              </label>

              <label>
                Mensaje <Field name="message" />
              </label>

              <button type="submit">Enviar</button>
            </Form>
          );
        }}
      </Formik>
    </main>
  );
}

// Location: pages/contact/success.tsx

export default function ContactSuccess() {
  return <p>¡Enhorabuena! Tu mensaje ha sido enviado con éxito</p>;
}

Obviando algunos detalles de implementación (como el uso de Formik para el formulario), los dos fragmentos de código anteriores muestran una posible implementación (básica pero funcional) que sirve para hacer pasar nuestro primer test de aceptación. En este punto, podemos añadir CSS a nuestra nueva página o extraer comportamientos a otro tipo de entidades (por ejemplo, mover la operación de onSubmit a un servicio). Si nuestro test sigue en verde al completar los cambios, tendremos la certeza de que no hemos roto nada ✅

Aplicando ciclos de desarrollo más pequeños

Aunque Cypress es un magnífico framework de testing, las pruebas de tan alto nivel suelen venir con algunos compromisos: es difícil poder ejercitar todos los caminos de ejecución posibles y son lentas. Recordad que con TDD estamos buscando mejorar nuestra productividad por lo que necesitamos que los ciclos de feedback sean lo más cortos posibles. Para ello, mi consejo es utilizar pruebas de aceptación para cubrir el happy path de la funcionalidad (y quizás algún escenario de error clave) y después iterar en ciclos de desarrollo más pequeños facilitados por pruebas de una granularidad más baja (en front-end, podríamos entenderlas como híbridos de integración + unitaria, centradas en componentes).

Si volvemos al ejemplo anterior, seguramente hay ciertas reglas de experiencia de usuario que queramos validar sobre el formulario de contacto: que no se pueda completar la operación sin un email de remite o sin el cuerpo del mensaje, que aparezcan correctamente los mensajes de error, que los campos permitan únicamente ciertos patrones, etc. Aunque estas pruebas se podrían hacer también utilizando Cypress, su latencia es a menudo lo suficientemente grande como para preferir moverlos a tests de más bajo nivel (por lo general, más rápidos).

Para hacer pruebas de componentes (en React, aunque las mismas herramientas están disponibles en otros frameworks como Vue o Angular) mi consejo es utilizar Testing Library en conjunción con Jest. Por ejemplo, vamos a añadir un nuevo comportamiento a nuestra página de Contacto, aunque esta vez iterando en un nivel de abstracción más bajo:

El formulario sólo debe enviarse si contiene un email de remite y un mensaje.

// Location: components/ContactForm.test.tsx

describe("ContactForm", () => {
  it("does not submit the form if some required fields are missing", async () => {
    // Setup
    const spy = jest.fn();
    render(<ContactForm onSubmit={spy} />);

    // Act
    await user.type(
      screen.getByLabelText(/asunto/i),
      "Información próximos libros",
    );

    user.click(screen.getByText(/enviar/i));

    // Assert
    await expect(
      screen.findAllByText("Este campo es obligatorio."),
    ).resolves.toHaveLength(2);

    await waitFor(() => expect(spy).not.toHaveBeenCalled());
  });
});

El test anterior codifica el nuevo comportamiento que queremos validar. Veréis que, en un primer vistazo, la apariencia del test es similar al primero que creamos utilizando Cypress. La única diferencia es que aquí se prueba el componente de manera aislada en lugar de simular a un usuario real utilizando la aplicación. En Testing Library, no hay ningún navegador ejecutándose en paralelo, como sí ocurre con Cypress; así, mientras el último que hemos escrito podemos ejecutarlo en ~2 segundos, el primero necesita de ~22 segundos.

Cuando trabajamos a un nivel de granularidad más bajo, nuestros tests pueden afectar al diseño de nuestros componentes (por lo general, haciéndolos más sencillos de probar). En este caso, he decidido inyectar la función que gestiona el envío del formulario para poder reemplazarla por un espía que me permita validar que no se ha invocado cuando no debía (aunque también podríamos haber espiado el módulo HTTP con nock). Este es otro de los beneficios clave de TDD, ser capaces de ir definiendo el diseño de nuestras interfaces a medida que escribimos las pruebas.

Como todos estos cambios no están repercutiendo en cambios de comportamiento a nivel de aceptación, nuestro test de Cypress debería seguir pasando después de cada modificación, ayudándonos de nuevo a garantizar que no hemos roto nada ✅.

Ahora, al igual que en el ejercicio anterior, tendríamos que escribir la menor cantidad de código que sirva para hacer pasar este test.

Pss! Podéis ver el ejemplo completo en este repositorio de GitHub 👀

Conclusión

¿Que conseguiremos aplicando un flujo similar al anterior? En la literatura de TDD, estaríamos aplicando lo que se conoce como Outside-In development with Double Loop TDD o el proceso descrito en el libro Growing Object-Oriented Software, Guided by Tests.

Primero, arrancamos con un test de aceptación (o del nivel de granularidad más alto que podamos) que nos ayudará a mantener el foco en la funcionalidad que queremos resolver. En ocasiones, este test puede estar fallando durante varias horas porque necesite de otros ciclos complementarios más pequeños que nos ayuden avanzar (el ejemplo anterior era tan sencillo que no lo hemos necesitado). Para esos ciclos complementarios es donde podemos hacer uso de flujos como TDD clásico (útil para avanzar en piezas de bajo nivel como funciones, clases, servicios) y herramientas como Testing Library (para probar los diversos componentes que construyan la interfaz) o simplemente Jest (para lógica de negocio como controladores, funciones de utilidad, etc.).

Otras referencias

• Además de los enlaces contenidos en el artículo, podéis encontrar más referencias a TDD en esta página.
• Cypress tiene una sección de mejores prácticas con algunos consejos muy útiles sobre cómo escribir pruebas de aceptación.
• Kent C. Dodds (creador de Testing Library) tiene bastantes artículos relacionados con testing de aplicaciones front-end (desde TDD hasta diferentes estrategias de testing). Podéis encontrarlos en su blog.

Vamos con la colección de recursos interesantes leídos durante julio, agosto y septiembre de este 2020.

💻 Blogposts

• Writing system software: code comments: al igual que me pasó con A Philosophy of Software Design, disfruto un montón con los textos que hablan sobre cómo escribir buenos comentarios (reflexionando, creo que viene de haber sufrido en equipos donde se malinterpretaban algunos principios de Clean Code y el código autodocumentado). En este caso, el artículo va un poco más allá y realiza una clasificación con los diferentes tipos de comentarios que nos podemos encontrar, a la vez que muestra ejemplos concretos sobre el código fuente de Redis. Tengo sentimientos encontrados con lo que el autor denomina Guide comments pero me encantaría conocer vuestra opinión!
• You’ve only added two lines - why did that take two days!: creo que este artículo recoge muy bien el heurístico que la mayoría utilizamos al resolver bugs y que no siempre se consigue entender por personas que están fuera del proceso de escritura de software (empezando por ese all lines of code are NOT equal).
• Why are CEOs failing software engineers?: lectura interesante para personas que se encuentren en áreas de gestión/liderazgo técnico en organizaciones de software (¿queda alguna que no lo sea? 😉).
• Don’t Compare Averages: aquí, Martin Fowler sale un poco de su temática habitual sobre ingeniería de software para hablar de diferentes visualizaciones que nos ayuden a comunicar información de manera más efectiva (es decir, escapando de las habituales gráficas de barras mostrando medias aritméticas).
• The Cabify engineering stack, 2020 edition: mola mucho conocer las tripas tecnológicas de grandes organizaciones de software y, en este caso, Cabify nos enseña parte de su stack y cómo gestionar una arquitectura web de alta disponibilidad y mucho, mucho tráfico 🙂.

🎥 Vídeos

• Tidy First?: un vídeo muy cortito donde Kent Beck introduce el concepto de dividir en diferentes pull requests los cambios de comportamiento y los cambios de estructura. Sin llegar a la clarividencia de Beck, creo que esta nota sobre revisiones de código efectivas y cómo aplicar ahí el principio de responsabilidad única puede ayudar a empezar a andar ese mismo camino.

Con unos días de retraso pero ahí va el conjunto de links con contenido interesante consumido durante el segundo trimestre de 2020.

Como curiosidad, ha sido un trimestre movidito (¡COVID aparte!) y he vuelto a unirme al equipo de PrivacyCloud para tratar de ayudar al equipo a alcanzar nuevos objetivos.

💻 Blogposts

• When should I write an Architecture Decision Record?: Cómo y cuándo se escriben ADRs en Spotify. Este artículo ha servido de empuje para que empecemos a utilizar este tipo de documentación dentro del equipo.
• Empowered Engineers FAQ: En general, todos los artículos del Silicon Valley Product Group sobre cómo construir equipos de producto son muy recomendables pero este, que es uno de sus últimos artículos al respecto, responde a varias preguntas enviadas por personas con dudas sobre cómo implementar esta manera de trabajar en sus equipos.
• Ana Asuero, Aplazame CPO, on how to do product when there are limitations you can’t control: Pues poco más que añadir; insights muy interesantes que nos llegan desde Aplazame sobre desarrollo de producto.
• Case study: Analyzing Notion app performance: Artículo mastodóntico sobre cómo se podría mejorar el rendimiento de la aplicación web de Notion. Más allá del caso de estudio concreto, para mí el valor del artículo se centra en conocer qué estrategias existen para mejorar el rendimiento de aplicaciones web (al final, todas sufren de más o menos los mismos problemas, aunque a diferente escala).

🎥 Webinars

• Technology at the Core of Product Discovery: En este webinar, Eduardo Ferro presenta la importancia de la tecnología subyacente como enabler para implementar una cultura de product discovery en equipos de producto.

📚 Libros

• Creativity, Inc.: Ed Catmull (director en Pixar Animation y Disney Animation) nos sumerge en un viaje por la historia de Pixar y por su propia estructura organizativa (que les ha servido para revolucionar la industria de la animación desde la innovación tanto organizativa como tecnológica). Aunque pueda no parecerlo en primera instancia, todos los capítulos de este libro contienen píldoras muy interesantes para cualquier equipo de desarrollo de producto y yo, sin duda, me veré influenciado por su lectura de aquí en adelante.

🎱 Bola extra: DEVS

Esta serie de HBO es un thriller de ciencia ficción donde, en una empresa de alta tecnología, desaparece un ingeniero de software en circunstancias sospechosas... su pareja (también ingeniera de software) comienza una investigación para tratar de esclarecer los detalles alrededor del caso 🙂

En esta nota os quiero contar algún detalle sobre cómo construí este website utilizando NEXT.js, un framework desarrollado por Vercel que utiliza React como librería principal y que permite, de manera sencilla, servir una aplicación React desde el servidor utilizando server-side rendering (¡aunque quedarnos únicamente con esto sería simplificarlo demasiado!).

Mi intención aquí no es hacer un recorrido en profundidad de NEXT.js o cómo implementar un portfolio utilizándolo. Si os pica la curiosidad, el proyecto tiene una muy buena documentación, con multitud de ejemplos y tutoriales.

Iterando entre diferentes versiones de Next

El primer commit para desarrollar codecoolture.com es del 24 de agosto de 2018. Por aquel entonces las necesidades del proyecto eran tener un montón de ficheros estáticos que explicasen qué servicios tenía pensado ofrecer como freelance y, para ello, utilicé la funcionalidad de Next: next export, que genera un conjunto de ficheros HTML como resultado de aplicar server-side rendering a la aplicación y exportar su resultado.

Más adelante, me decidí por añadir un blog (y este apartado de notas) y en ese punto, las cosas empezaron a complicarse (sobre porqué decidí implementar mi blog in house en lugar de utilizar plataformas como Medium, las razones son muy parecidas a las expuestas por Marina Aisa cuando escribió sobre su experiencia trabajando con Nuxt). Para seguir manteniendo ese enfoque estático, tenía que añadir las diferentes entradas manualmente en alguna página tipo índice que sirviera para que el proceso de exportación supiese que existían y pudiese crear sus ficheros HTML relacionados (simplificándolo mucho, sería algo similar a lo que necesita un bot para hacer crawling de una web).

Para no depender de un proceso manual, me decidí por abandonar la exportación estática y desplegar Next en una instancia de AppEngine para hacer que las páginas del blog (junto con su índice) se comenzasen a pintar dinámicamente utilizando SSR. Veréis que aunque Vercel es una plataforma que le encaje como anillo al dedo a un proyecto que utilice Next, este se puede desplegar en cualquier servicio que admita ejecutar aplicaciones Node (aunque no todos son capaces de sacarle partido al potencial serverless del framework, pero eso sería un tema para otro momento).

Actualmente, y tras actualizar Next a su versión 9.3, pude recuperar la exportación estática gracias a la adición de una función getStaticPaths que permite indicarle a Next (de manera programática, en tiempo de compilación) qué paginas existen y cuáles tiene que exportar. En el mismo fichero que se utiliza para definir una entrada en el blog, se exporta un función cómo la siguiente:

export const getStaticPaths: GetStaticPaths = async () => {
  const repository = await MarkdownRepository.fromDirectory(
    getConfig().writing.articles,
  );

  const paths = (await repository.all()).map((article) => {
    const slug = article.metadata.slug;

    if (!slug) {
      throw new Error(
        `ERROR: Missing slug for article: ${JSON.stringify(article.metadata)}`,
      );
    }

    return { params: { slug } };
  });

  return { fallback: false, paths };
};

La función pide a un repositorio de artículos que devuelva todos los documentos que existen y utiliza esta información para indicar a Next cómo encontrarlos (a través de la propiedad slug de cada path). MardownRepository es una entidad de mi proyecto (y no algo que venga con Next), y es que el patrón Repository es una abstracción que utilizo muy habitualmente ya que encaja en un montón de escenarios (realmente, en casi cualquiera que tenga acceso a datos).

Como Cassidy Williams lo explica mejor que yo, podéis echar un vistazo a este blogpost donde explica en profundidad cómo crear un blog con Next.

MDX: escribiendo contenido de manera cómoda

No, la verdad que React + JSX no es la mejor manera para escribir contenido de manera ágil y cómoda... Para hacerlo, me decidí por un plugin de Next que permite generar páginas escribiendo directamente ficheros MDX (que, en resumen, son ficheros en formato Markdown pero que permiten integrar componentes React directamente en el cuerpo del documento). Este mismo esquema es el que utilicé para escribir los artículos del blog y las notas; todo junto, en resumen, hace que el 100% del contenido de la web se escriba en MDX y únicamente utilice React + JSX para definir los componentes.

Además, con MDX, podemos indicar qué componentes React queremos mapear con cada elemento HTML. Esto es especialmente útil para poder reutilizar los mismos componentes a través de toda la aplicación:

import { Blockquote } from "../../components/Blockquote";
import { Link } from "../../components/Link";
import { List } from "../../components/List";
import { Text } from "../../components/Text";
import { Title } from "../../components/Title";

/* ... */

<MDX
  components={{
    a: Link,
    blockquote: Blockquote,
    h1: Title,
    ul: List,
  }}
>
  {post.content}
</MDX>;

Otros detalles

• Para los estilos de la aplicación me decanté por utilizar CSS y no una solución CSS-in-JS, aunque seguramente mi decisión ahora hubiese sido distinta (después de utilizar emotion durante los últimos meses, la verdad es que me he sentido muy cómodo). Ambos enfoques se pueden utilizar sin mayores problemas en Next (siendo el uso de CSS soportado por defecto, sin necesidad de configurar nada).
• La web se sirve desde Firebase Hosting (tengo la mayoría de proyectos en Google Cloud y me era más cómodo mantener todo dentro de la misma nube que desplegar este site en Vercel o Netlify -opciones también muy válidas y con una developer experience muy bien ejecutada). Los despliegues están automatizados a través de GitLab CI/CD.

💻 Blogposts

• How GitHub’s CTO Architects Engineering Teams That Scale
• Production Oriented Development: Si solo tenéis tiempo para atender una recomendación, que sea esta 😁

[...] code in production is the only code that matters. Staging doesn’t matter, code on your laptop doesn’t matter, QA doesn’t matter, only production matters. Everything else is debt.

• Documenting Architecture Decisions: Este blogpost tiene ya algunos años (2011) pero su idea es perfectamente relevante. Documentar decisiones de arquitectura es la única manera de empoderar a las personas que se vayan a hacer cargo del proyecto en el futuro.

Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small, modular documents have at least a chance at being updated

🛠 Código

• zalando/tech-radar: Herramienta basada en el Tech Radar de ThoughtWorks y pensada para que equipos de ingeniería puedan documentar el estado de su stack tecnológico.

📚 Libros

• Object-Oriented Reengineering Patterns: Publiqué una pequeña nota sobre el libro aquí.

🎱 Bola extra: musicforprogramming

Seguramente sea ya todo un clásico, pero musicforprogramming contiene un montón de listas de reproducción para concentrarse programando (o haciendo cualquier otra actividad que requiera foco 😄).

Este libro es una magnífica colección de heurísticos y estrategias para ayudarnos a comprender un sistema de software complejo y ser eficaces a la hora de poder evolucionarlo y mantenerlo.

Los últimos capítulos están dedicados a estrategias de diseño de software que permitan extender un modelo ya existente, y son los únicos donde se hace referencia a orientación a objetos. Personalmente, también son los que menos valor me han aportado, quizás porque ya han sido desarrollados ampliamente en otro libros (Practical Object-Oriented Design, por poner un ejemplo).

Un libro muy interesante si te toca unirte a un proyecto ya en marcha o te enfrentas a un cambio de trabajo, ya que independientemente del objetivo final (reingeniería) sus consejos son muy útiles para poder entender bases de código relativamente grandes, utilizando las herramientas y actores adecuados (que se cubren en profundidad en la parte II: Reverse Engineering).

A culture of continuous reengineering is a prerequisite for achieving flexible and maintainable object-oriented systems.

• «It is easy to get seduced by focussing on the technical problems that interest you the most, rather than what is best for the project.»
• «Other engineering disciplines rely on the laws of nature to hide irrelevant details, but software engineering must build on less solid foundations. Consequently, it is essential to pay attention to the details. The only question is how to filter out those details that do not matter, because you cannot possible investigate everything.»
• «Documentation is almost always out of date with respect to the actual situation. [...] Consequently, avoid to make important decisions based on documentation only —first verify your findings by other means (in particular, Read all the Code in One Hour and Interview During Demo)»
• «As a rule of the thumb, assume that a single team can reengineer as much code as they can write from scratch.»
• «If you fail to deliver good initial results, you will learn a lot, but you risk losing credibility. It is therefore critical to choose carefully initial tasks which not only demonstrate value for the customer, but also have a high chance of success. Therefore, take great care in estimating the effort of the initial tasks.»
• «Nevertheless, even outdated information may be useful, because at least it tells you how the system was supposed to behave in the past. This is a good starting point to infer how it is used today.»

Single-responsibility principle es, sin duda, uno de los principios de diseño de software que más me gusta. Aplica muy bien a un montón de escenarios, tanto a escala "micro" (funciones, clases) como "macro" (arquitectura, microservicios). Si estáis lidiando en un escenario donde las pull requests son, habitualmente, más grandes de lo que os gustaría y por tanto, necesitan de mucho tiempo para ser revisadas (convirtiéndose casi accidentalmente en cuellos de botella) os ánimo a probar la aplicación de SRP.

¿Cómo encajaría en este contexto? A mí me gusta enunciarlo de la siguiente manera:

Una pull request debe contener cambios relacionados con una única responsabilidad.

Como veis, dentro del enunciado anterior, tendrían cabida code reviews con multitud de cambios pero (y este pero es importante) siempre y cuando estén relacionados con una única responsabilidad. Y es que, en la práctica, la complejidad a la hora de revisar una pull request no está tanto relacionada con el número de cambios, sino con el volumen de responsabilidades que están siendo cambiadas a la vez (es decir, un renaming por aquí junto a un cambio en el código de esta función por allá).

Como ejemplo, uno de los sospechoso habituales de generar un montón de cambios: renombrar un método, clase, etc. Si este cambio se traduce en una única pull request, estaremos facilitando mucho la vida de la compañera que tenga que revisar nuestro código ya que todos los cambios están relacionados con una única responsabilidad y sólo deberá poner el foco en garantizar que la acción se haya hecho correctamente (¡imaginad que, además, tuviera que validarlo junto a otro montón de cambios de diversa índole que acompañen a la pull request!).

La complejidad a la hora de revisar una pull request no está tanto relacionada con el número de cambios, sino con el volumen de responsabilidades que están siendo cambiadas a la vez.

Conseguir un flujo así implica que tengamos que quitar de nuestra cabeza la idea de que 1 feature equivale a 1 pull request y eso es algo que sólo podemos conseguir si desacoplamos nuestro repositorio de nuestra estrategia de entrega de software.

Por supuesto, todos los consejos habituales sobre cómo realizar buenas revisiones de código aplican también con este enfoque (y si queréis un repaso completo sobre cómo realizar la pull request perfecta, os recomiendo esta charla de Patricia Gao).

💻 Blogposts

• The Amazon Builders’ Library: Conjunto de artículos que reflejan como Amazon builds and operates software. Se explican desde sistemas distribuidos a gestión de pipelines de integración y entrega continua.
• Ruby, Where do We Go Now?: Es muy interesante ver la evoluación de Ruby para mantenerse como una alternativa interesante todavía en 2020. Pero más interesante es leer cómo Bozhidar Batsov (creador de Rubocop -el linter más popular en el ecosistema Ruby) da su particular visión sobre el estado actual del lenguaje en su versión 2.7, repasando algunas de sus decisiones de diseño más controvertidas.
• El role de un Engineering manager: Este es el primero de una serie de artículos escritos por Félix para hablar de las responsabilidades de un Engineering Manager y cómo utilizar varias de las herramientas de las que disponemos: one on ones, performance reviews, etc. Un contenido súper interesante y... ¡en español! 😉
• Experts aren’t good at building shared understanding

📚 Libros

Este último trimestre lo he dedicado a picotear artículos y capítulos de varios libros pero, si tuviera que quedarme con uno, diría que Accelerate es el mejor recurso para entender (y defender) porqué aplicar una cultura de entrega continua es el camino a seguir para mejorar el rendimiento de un equipo de desarrollo (y de cualquier empresa de software en general).

🎱 Bola extra: Notion

Durante este último trimestre he pasado a darle mucho uso a Notion para administrar diferentes tareas, proyectos y conocimiento. Es multiplataforma y su plan gratuito es lo bastante amplio para poder utilizarlo (durante un tiempo largo) sin mucho problema.

Nota: en la literatura, ATDD suele ir acompañado de un conjunto de prácticas y herramientas más amplio que lo descrito en este artículo. Mi objetivo aquí es transmitir mi experiencia sobre cómo aplicar parte de sus principios para mejorar nuestra productividad a la hora de resolver determinados problemas, visto únicamente desde el plano de desarrollo de software.

Una de las situaciones más habituales que me he encontrado en los últimos años cuando facilito coding dojos o coderetreats (donde muchas personas se enfrentan por primera vez a resolver una kata aplicando metodologías como TDD) es observar cómo los participantes empiezan atacando el problema de una manera que no les ayuda a avanzar, sino más bien les obliga a perderse en pequeños detalles de implementación o incluso a sufrir de cierta parálisis por análisis.

Al principio, yo también pensaba que aplicar TDD debería ser suficiente por sí mismo para evitar esa fricción inicial y tener working software lo más rápido posible, pero tras observarlo (y sufrirlo) durante varios años, me he dado cuenta que no siempre es así. Cuando empezamos a trabajar con TDD es habitual que tratemos de solucionar el problema desde aquellos puntos donde nos es más sencillo poder aplicarlo (pequeñas piezas de bajo nivel, como una función sencilla), aunque no sean las partes que nos ayuden a llegar antes a resolver el problema (y por tanto, a entregar valor).

Como parte de la preparación para facilitar el GDCR19, estuve trabajando en resolver el Juego de la Vida utilizando un enfoque basado en ATDD (acceptance test-driven development), una aplicación de TDD que nos obliga a pensar en pruebas de muy alto nivel (aceptación) con la idea de tener una versión desplegable de nuestro sistema con cada iteración.

El síndrome de la página en blanco, o ese primer test

Una de las ventajas de aplicar ATDD es que esa primera crisis sobre cómo atacar el problema me vino resuelta casi de base. En este caso, sabía que el sistema debía ser un CLI que, a partir de un fichero de entrada, generase un fichero de salida con la siguiente evolución del tablero (aquí tenéis un enlace con las reglas del juego).

La primera porción de funcionalidad mínima (de alto nivel) que se me ocurrió implementar fue un CLI que, dadas las condiciones anteriores, supiera evolucionar un tablero con despoblación.

Seguramente, esta sea la diferencia más notable frente a tratar de resolver el problema utilizando (únicamente) TDD a nivel unitario (de ahora en adelante, UTDD -aunque no creo que este concepto esté definido en ningún sitio 😅). Con UTDD nos vemos obligados a detectar desde el principio una primera entidad sobre la que escribir los tests, lo que en muchas ocasiones me ha hecho perder el foco y caer en la trampa del Big Design Up Front.

const subject = join(__dirname, "../src/cli.ts");

it("supports underpopulation", () => {
  const inputFilename = join(__dirname, "./fixtures/underpopulation");
  const outputFilename = join(__dirname, "./results/underpopulation");

  play(`${subject} --input=${inputFilename} --output=${outputFilename}`);

  const result = getResult(outputFilename);

  expect(result).toEqual(["0 0 0", "0 0 0", "0 0 0"].join("\n"));
});

Pero vayamos paso a paso por el test anterior:

• La función play es un simple envoltorio que ejecuta en un shell la instrucción indicada. En este caso, nuestro ejecutable es el fichero src/cli.ts y se le pasan como parámetro ambos: el fichero de entrada con el tablero inicial y el fichero de salida donde guardar la evolución.
• Una vez ejecutado el script, recuperamos el resultado a partir del fichero de salida indicado y comprobamos que sea el resultado esperado.

ATDD sigue el mismo ciclo Red-Green-Refactor que TDD, por lo que en esta primera iteración hemos sentado las expectativas tanto de un primer comportamiento del sistema como de su propia interfaz para operar, sin tener aún nada de código de producción implementado. Si estáis acostumbradas a trabajar con UTDD, es posible que este primer test os parezca demasiado grande. Y es que con ATDD el ciclo de feedback es mucho más largo.

Añadiendo nuevos comportamientos

Con el test anterior en verde, ya dispondríamos de una versión 0.1.0 de nuestro Juego de la Vida 🙂 Un CLI que, a partir de un fichero de entrada, sería capaz de evolucionar el tablero detectando aquellas células que sufran de despoblación y guardando el resultado en el fichero de salida indicado.

Pero para implementar el Juego de la Vida de manera completa, hay que tener en cuenta también otros escenarios. El enfoque que apliqué para ello fue ir creando un nuevo test para cada nuevo comportamiento. Así pues, tras implementar el soporte para despoblación, el siguiente en la lista era el escenario de sobrepoblación.

Con esa prueba también en verde, tendríamos una nueva versión 0.2.0 del sistema lista para desplegar; esta vez, soportando ya un nuevo escenario. Este mismo flujo se utilizaría para implementar el resto de reglas.

Cada nuevo test define un nuevo comportamiento de alto nivel en el sistema. Al resolverlo, nuestro software debería estar listo para ser desplegado.

ATDD y productividad

Seguramente, aplicar ATDD tampoco me hubiese ayudado a terminar de implementar el Juego de la Vida en los 45 minutos que duran las sesiones de un coderetreat 🙃, pero sí creo que me habría permitido acercarme mucho más que si hubiese intentado solucionar el sistema siguiendo una estrategia bottom-up.

Trabajar con tests de aceptación me ayudó a ganar foco y programar rápidamente una solución que los pusiese en verde. Sentir que con cada prueba disfrutas de un sistema desplegable (aunque su implementación no sea perfecta a nivel de diseño) me parece un gran boost de productividad. Con 4 pruebas, tienes las reglas de negocio del Juego de la Vida cubiertas y puedes empezar a aplicar refactoring para extraer comportamientos a nuevas entidades de manera muy confiable (los test de aceptación te aseguran que el sistema funciona punto a punto -y esto, cuando sueles trabajar con muchos pequeños tests unitarios, está muy bien).

ATDD y UTDD

El Juego de la Vida es un problema sencillo, que prácticamente se resuelve con unas pocas líneas de código. En sistemas más sofisticados, donde estemos implementando funcionalidad más compleja, es muy habitual mezclar ambos ciclos para disfrutar de las ventajas de ambos enfoques (lo más habitual es que trabajemos con código legacy, donde aplicar UTDD es sencillo al tener muchas entidades de dominio ya modeladas en nuestro sistema).

Juntar ambas estrategias termina generando un ciclo de ciclos, donde el test de aceptación está en rojo mientras que vamos aplicando ciclos de UTDD para tratar de ponerlo en verde (y terminar de implementar ese nuevo comportamiento de alto nivel en el sistema).

Contenido relacionado

Si os habéis quedado con ganas de investigar un poco más, el libro Growing Object-Oriented Software, Guided by Tests cubre muy bien (y en profundidad) esta manera de trabajar y resolver los problemas. Además, he publicado en GitHub la implementación que utilicé para practicar con este enfoque mientras resolvía el Juego de la Vida.

La estrategias comentadas en este artículo también se representan en la literatura a través de los conceptos de Inside Out y Outside In (que se cubren en detalle en este artículo).

📚 Libros

Durante estos meses he tenido mucho viaje. Muchas horas de tren (a Madrid, cinco horitas por trayecto...) y alguna escapada en avión para disfrutar de las vacaciones de verano 🙂, así que el número de libros ha sido superior al que acostumbro (aunque bien es cierto que un par de ellos ya los había leído anteriormente).

Como veréis, esta vez son libros más cercanos a negocio que a la práctica de desarrollo de software en sí:

• Scrum and XP from the Trenches (2nd Edition): importante que sea la segunda edición, ya que contiene cortes del autor 8 años después de la primera edición. Me ha gustado el enfoque pragmático del libro. Con muchos accionables.
• The First 90 Days: si te encuentras en un momento de transición (cambio de puesto y/o empresa) estoy seguro de que podrás sacar algo positivo de este libro. Tienes 90 días para empezar a conseguir tus primeras victorias y encajar en el engranaje de la empresa, ¿por dónde empezarías?
• Extreme Programming Explained: Embrace Change: poco que decir... cualquier persona que haya trabajado en entornos Agile ha sido expuesta, de alguna manera, a las prácticas de Extreme Programming. Se lee muy bien y sigue aplicando 100% al contexto actual.
• Effective Workshops: siento mucho interés por la cultura de workshops (en general, pero especialmente aplicado en empresas) y es una habilidad que me gustaría entrenar. El libro está pensado para ayudarte en tu camino como host/facilitadora, desde los preámbulos del evento hasta qué hacer una vez ha terminado. Eso sí, ¡no esperes encontrar ejemplos de ejercicios concretos!

🎬 Charlas

• Deliveritis Aguda por @buenosvinos: en líneas generales, creo que la manera de entender el desarrollo de software por parte de Carlos está muy alineada con mi propia visión y, aunque es muy difícil condensar tanta información en tan pocos minutos, se exponen de manera clara los pain points más habituales en el proceso de entrega de software junto con estrategias eficaces para tratar de mitigarlos. Me quedo con ganas de conocer (más en profundidad) sus opiniones sobre cómo integrar los procesos de QA dentro del equipo de desarrollo.

💻 Blogposts

• No Software: No Agile, No Scrum
• The boring technology behind a one-person Internet company: siempre me parecen súper interesantes este tipo de artículos donde se desgranan parte de los internals de un proyecto. Me ayuda a coger perspectiva pudiendo comparar mi experiencia con la de otras personas.
• 17 Reasons not to be a Manager

🎱 Bola extra: Una serie de televisión

• Escape at Dannemora: la vi casi por casualidad (no recuerdo que se hablase demasiado de ella) pero la verdad es que me ha encantado; el trío protagonista está muy bien desarrollado y el ritmo de la serie a mí me ha tenido bastante atrapado (disclaimer: me gusta que se tomen su tiempo en contar la historia).

Como una extensión más de la ley de Conway, es muy habitual encontrarse con proyectos donde la estrategia de branching del sistema de control de versiones está fuertemente relacionada con la estrategia de entrega de software. Esta relación entre ambos mundos puede parecer conveniente (por ejemplo: utilizar una rama para representar el código vivo en producción o staging, congelar los cambios que van a desplegarse en una rama release/*, etc.) pero, con el paso del tiempo, puede traer consigo efectos contraproducentes:

• Viola el principio de responsabilidad única. Si algo nos queda claro sobre el Single Reponsability Principle es que cada abstracción sólo debe tener una única razón para cambiar (en palabras de Robert C. Martin). Si cambios en los procesos de entrega de software (flujos de resolución de hotfixes, nuevos entornos) implican cambios en la estructura de nuestro repositorio (o cambios en la manera de interactuar con él), los límites entre ambos contextos no están bien establecidos.
• Todo se vuelve innecesariamente complejo. Aún con flujos muy populares como git-flow (y herramientas muy sofisticadas a su alrededor, construidas como una capa de abstracción sobre git), se hackea el sistema de control de versiones para dejar de ser una herramienta de tracking y colaboración por un sistema de despliegue y configuración.
• Resta flexibilidad. Si es el sistema de control de versiones el encargado de determinar qué funcionalidades se van a liberar al final de una iteración, se pueden dar situaciones en las que una rama se quede congelada por contener funcionalidad defectuosa que inevitablemente contamina al resto de cambios de esa misma rama, bloqueando la entrega de nueva funcionalidad.

Para aliviar los problemas anteriores, una solución pasa por mover la responsabilidad de decidir qué funcionalidades están disponibles en cada entorno desde el sistema de control de versiones a la propia base de código. Es decir, decidir programáticamente si una funcionalidad está habilitada o no en función de en qué entorno se está ejecutando la aplicación.

Una representación habitual de este principio es a través del uso de Feature Flags, que no dejan de ser, conceptualmente, bloques condicionales que se sitúan en algún punto de nuestra base de código y deciden si un camino de ejecución debe evaluarse o no.

Con esta estrategia, únicamente necesitaríamos una rama master donde fusionar las feature branches de funcionalidades terminadas y una configuración de feature flags que defina los entornos en los que estarían disponibles. Por ejemplo: habilitar la funcionalidad únicamente en entornos de staging para realizar pruebas de rendimiento, labores de quality assurance, etc. La resolución de hotfixes, se podría realizar igualmente sobre la rama master, pues es esta la que siempre se despliega y define qué funcionalidades estarían disponibles en cada momento y para cada entorno.

Siguiendo esta dirección, también se obtendrían beneficios adicionales como, por ejemplo, poder realizar merges de manera mucho más recurrente (al estar el entorno de producción siempre protegido a través de feature flags). Esto podría derivar, a su vez, en procesos de code review con un número menor de cambios y ciclos de feedback más cortos, siempre que lo combinemos con técnicas como continuous integration y continuous delivery.

Otras lecturas relacionadas

• Decoupling Deployment from Release - ThoughtWorks’ Technology Radar

Muchas de las herramientas que utilizamos a diario almacenan su configuración utilizando ficheros denominados dotfiles, (llamados así por su esquema de nombrado, empezando habitualmente por un punto: .bashrc, .zshrc).

Al tratarse de ficheros en texto plano, es muy sencillo poder almacenarlos en un sistema de control de versiones y poder reutilizarlos (y sincronizarlos) desde diferentes equipos.

En Internet ya hay muchos ejemplos de dotfiles que pueden servir de referencia (los de Jess Frazelle son espectaculares) pero, al final, es normal que cada persona tenga su propia configuración con detalles que le hacen ser más productivo o productiva.

Alguna de las estrategias más populares para poder instalar dotfiles es hacer uso de symlinks y requerir el menor número de dependencias posible (precisamente, uno de los casos de uso más habituales es utilizarlos para replicar las dependencias y configuraciones existentes en otro sistema).

En mi caso, mis dotfiles tienen como únicas dependencias curl y make (disponibles tras una instalación limpia de macOS), que se utilizan para instalar homebrew y, a través de un fichero Brewfile, instalar automáticamente el software con el que trabajo habitualmente 🚀

Durante las últimas semanas he estado leyendo este maravilloso libro escrito por John Ousterhout y me gustaría compartir algunas conclusiones que he podido extraer tras su lectura.

Lo primero, es que el libro me ha parecido un contrapunto muy interesante a Clean Code. Básicamente, ambos presentan estrategias para reducir la complejidad en el diseño, desarrollo y mantenimiento de software (y la complejidad es un término sobre el que se discute largo y tendido en A Philosophy of Software Design) pero lo hacen, bajo mi punto de vista, desde dos ópticas diferentes.

Robert C. Martin (y mucha de la literatura que hay por ahí fuera) pone el foco especialmente en reglas y principios: tamaño de las entidades (¡funciones de menos de 10 líneas!), el número de responsabilidades de una abstracción, código sobre documentación, evitar duplicidades, etc. Sin embargo, en A Philosophy of Software Design nos encontramos un par de capítulos dedicados en exclusiva al “arte” de escribir buenos comentarios y a las ventajas de invertir tiempo en expresar, a través de los mismos, aspectos relacionados con el diseño de software que son prácticamente imposibles de describir utilizando únicamente código (por ejemplo, el conocimiento del dominio que nos lleva a aplicar ciertos patrones o arquitecturas, workarounds para lidiar con known issues, etc).

De todos, el capítulo 10: Define Errors Out Of Existence, me ha parecido una delicia, y creo que introduce conceptos muy interesantes para lidiar con los casos esquina y errores de cualquier aplicación.

Del mismo modo, algunos pasajes hablando sobre la ventaja de definir abstracciones “profundas” (deep) en lugar de “planas” (shallow) ilustran bastante bien los problemas de llevar técnicas de Clean Code al extremo, sin aplicar un buen criterio.

Creo que la lectura de este libro me ha servido para adoptar un enfoque más pragmático a la hora de escribir código, alejado de dogmatismos y poniendo el foco en lo que realmente importa, tratar de reducir al máximo la complejidad de nuestras soluciones (lo que implícitamente nos llevará también a la aplicación de buenas prácticas de diseño).

Los pasados días 4 y 5 de abril impartí mi primer taller de introducción a TDD en AsturiasHacking. Después de varios años (co-)organizando esta comunidad, tenía claro que el tema levantaba cierto interés entre los participantes, que siempre intentaban algún tipo de aproximación cuando realizamos actividades prácticas (como el Global Day of Coderetreat).

Mi objetivo para el taller era introducir test-driven development desde una perspetiva nada dogmática, basada en mi experiencia y donde quedara evidente que se trata de otra herramienta más, útil especialmente de cara a diseñar software y poco efectiva de cara a realizar labores exhaustivas de quality assurance.

La manera de organizar el taller se dividió en dos tardes, con dos horas de duración cada sesión. Durante el primer día realizamos una introducción teórica a la metodología: cuáles son sus "normas" y beneficios. Para después dedicar un rato a programar en parejas para poder aplicar los conceptos aprendidos.

El segundo día, sin embargo, lo aprovechamos para discutir diferentes estrategias para enfrentarnos a código legacy y cómo relacionar nuestro código con el resto de colaboradores de un sistema ya en producción. Para ello, introdujimos el concepto de test doubles, con sus diferentes tipos y propósitos, para terminar con una parte práctica donde los participantes debían enfrentarse a un código sin pruebas, con un diseño muy acoplado y sobre el que realizar una pequeña extensión de su funcionalidad.

El feedback sobre la sesión fue muy positivo. Por ejemplo, las siguientes citas ilustran bastante bien las conclusiones que salieron en el closing circle:

He aprendido, más bien descubierto, una nueva forma de afrontar o aproximarme a la creación de código nuevo.

Me ha sorprendido la forma real de usar TDD ya que sí creía que era únicamente [hacer] tests.

Me ha sorprendido como trabajar en pequeños pasos ayuda a centrarte en el problema.

En este enlace os dejo un documento con todos los recursos y bibliografía utilizados durante la sesión.

El síntoma más claro de este code smell es la aparición de varios métodos de instancia tipo render especializados en construir una parte de la UI de un componente React. Suele aparecer especialmente en componentes complejos (o de gran tamaño, como una página) cuando diferentes partes de la interfaz precisan de alguna comprobación o cálculo extra que afecte a su representación.

export class Blog extends React.Component<{ articles: Article[] }> {
  public render() {
    return (
      <>
        {this.renderHeader()}

        {this.renderArticles()}
      </>
    );
  }

  private renderHeader() {
    const {
      articles: { length: numberOfArticles },
    } = this.props;

    if (numberOfArticles === 0) {
      return (
        <header>
          <p>No articles 😯</p>
        </header>
      );
    }

    return (
      <header>
        <p>Yay! {numberOfArticles} articles 🎉</p>
      </header>
    );
  }

  private renderArticles() {
    return this.props.articles.map((article) => {
      return (
        <section>
          <h1>
            <a href={article.url}>{article.title}</a>
          </h1>
        </section>
      );
    });
  }
}

En el caso anterior, vemos que la representación de la cabecera de la página varía en función del número de artículos que se vayan a mostrar. Del mismo modo que la lógica para pintar la colección de artículos está encapsulada en su propio método de instancia.

Con echar un simple vistazo al método render, ya vemos con claridad cuáles son las verdaderas responsabilidades de nuestra página: definir un layout que muestre una cabecera y una colección de artículos.

¿Es, por tanto, responsabilidad de la página conocer los internals de la cabecera y la lógica necesaria para pintar la colección de artículos? No. Este componente contiene más de una responsabilidad y no cumple con el Principio de Responsabilidad Única.

Para mejorar nuestro diseño, bastaría con definir dos nuevos componentes que encapsulen la lógica necesaria para pintar ambas partes. Con este enfoque, ganaríamos cierta capacidad para reutilizar esos componentes en otros lugares de nuestra interfaz (aunque no es condición necesaria para crear un nuevo componente) a la vez que reducimos la complejidad del componente padre, que no necesita ya llevar consigo toda la lógica de las diferentes partes que la conforman.

Además, si seguís un enfoque de integración y entrega continua, veréis que es mucho más sencillo aplicar feature flags sobre estos pequeños componentes de vuestra interfaz en lugar de en mitad de componentes grandes y complejos, donde se estarían mezclando responsabilidades y requisitos de distintas partes de la aplicación.

import { Articles } from "./components/Articles";
import { Header } from "./components/Header";

export function Blog(props: { articles: Article[] }) {
  return (
    <>
      <Header {...props} />

      <Articles {...props} />
    </>
  );
}

Este code smell está relacionado con otros de propósito general (no relacionados directamente con React) como Large Class y técnicas de refactoring como Extract Class.

[...] If you’ve been involved in software development, you too have probably often felt that all this should be simple, but somehow it gets all complicated.

— Ron Jeffries

Llevaba unos cuantos meses con ganas de poder leer el libro The Nature of Software Development de Ron Jeffries y, por fin, este enero, he dedicado unas cuantas horas a poder estudiarlo, disfrutarlo y compartirlo con varias personas del equipo y colegas de profesión.

Para quien no le conozca, Ron Jeffries es uno de los creadores de Extreme Programming, firmante del manifiesto Agile y un profesional con dilatada experiencia en el desarrollo de software. Un breve vistazo al índice de contenidos o al resumen de la contraportarda ya es suficiente para entender que el libro, aunque no mencione explícitamente niguna metodología concreta (más allá del Natural Way del propio Jeffries), va a ofrecer una lectura amena y un tanto filosófica sobre el desarrollo de software desde una óptica Agile. En lo personal, encontré la visión del libro muy alineada con mi propio entendimiento sobre cómo se deberían desarrollar productos y proyectos digitales.

A través de sus páginas, Jeffries no sólo habla del proceso de implementación (del que, realmente, apenas menciona más que la búsqueda constante de la excelencia técnica y los beneficios de aplicar Refactoring de manera regular), sino que gran parte del libro está centrado en la própia definición de valor («lo que necesitas», en palabras del autor) y cómo se puede identificar y alcanzar lo más rápido posible a través de la construcción de equipos de alto rendimiento que tengan maestría en técnicas de entrega continua de valor, planning y slicing de funcionalidades y capacidad para ejecutar y entregar productos donde la calidad sea una máxima no negociable.

Como imagináis, construir un equipo de estas características requiere de perfiles multidisciplinares donde personas de negocio y desarrollo trabajen codo con codo compartiendo una filosofía común.

Sin duda, si trabajáis en una empresa de software (a cualquier nivel), este se trata de un libro imprescindible.

Código que se escribe y, por tanto se ejecuta, sin estar encapsulado en ningún bloque o procedimiento (como por ejemplo una función o una clase).

En JavaScript, sufrimos de una relación de amor-odio con el contexto de ejecución goblal. Hasta la aparición de los módulos en la especificación de ES6+ la manera más habitual de gestionar dependencias en nuestra aplicación era a través de la variable global window, accesible desde cualquier punto de nuestro programa.

Con los módulos, llegó una manera de gestionar esas dependencias de manera explícita y favorecer técnicas como tree shaking para mejorar el rendimiento de nuestras aplicaciones. Mientras que, a su vez, ganamos también cierta capacidad para encapsular nuestro código y evitar que se ejecutase en el contexto global de la aplicación, junto al resto de código de otros ficheros.

Sin embargo, sigue siendo habitual encontrar este tipo de code smell gracias a lo sencillo de codificar directamente en el cuerpo de módulos ECMAScript:

const repository = {};

export function addTodo(todo) {
  if (repository[todo.id]) {
    return;
  }

  repository[todo.id] = todo;
}

Aunque escribir código directamente en el cuerpo de un módulo tiene sus casos de uso, tiene efectos laterales que pueden ser no evidentes:

• El código del módulo (sin encapsular) es ejecutado por el intérprete la primera vez que se importa, por lo que perdemos la habilidad de controlar cuándo evaluar un fragmento de código para, por ejemplo, establecer un escenario de ejecución determinado en nuestras pruebas.
• En el ejemplo anterior, la variable repository es un objeto global (aunque únicamente accesible desde el propio cuerpo del módulo) que dificulta enormemente la capacidad de probar el código de manera unitaria, ya que hay que gestionar el estado de un variable sobre la que no tenemos acceso.
• Podemos incurrir en problemas de rendimiento (memory leaks), al disponer de una serie de variables globales sobre las que el recolector de basura no puede actuar en caso de no ser necesarias (siempre mantendrán -al menos- una referencia).

¿Cómo podríamos mejorar el caso anterior? Envolviendo el cuerpo del módulo en una función createRepository que nos devuelva el control sobre el contexto de ejecución del repositorio.

export function createRepository(todos = {}) {
  const repository = { ...todos };

  return {
    addTodo(todo) {
      if (repository[todo.id]) {
        return;
      }

      repository[todo.id] = todo;
    },
  };
}

A pesar de los problemas anteriores, existen escenarios donde realmente sí queramos ejecutar código en el cuerpo del módulo para poder beneficiarnos del hecho de ser una suerte de Singleton:

• Fichero index donde inicializar dependencias globales de la aplicación.

Cabe recordar que un code smell no significa que algo esté mal. Simplemente se refiere a un patrón que puede (esto es importante) conllevar consigo males de diseño. En este caso, a no ser que sea plenamente consciente de los efectos laterales que conlleva, evito utilizar naked code en el cuerpo de mis módulos JavaScript.

En ocasiones, nos vemos en la situación de tener que actualizar varios componentes de nuestra interfaz de usuario para ajustarlos a nuevas directrices de diseño. Otras veces, necesitamos reemplazar su implementación para hacer frente a nuevos requisitos de negocio. Si el número de cambios es lo suficientemente alto, es posible que no se puedan realizar de manera atómica (o tengan que ser sincronizados con eventos fuera del control del equipo de desarrollo como, por ejemplo, la publicación de una nueva imagen de marca) a la vez que necesitamos continuar entregando valor en forma de nuevas funcionalidades, corrigiendo defectos o aplicando alguna que otra mejora.

En este artículo vamos a hablar sobre una estrategia que nos permita obtener un flujo de integración continua evitando, por tanto, mantener los cambios en nuestros componentes en una rama independiente en el sistema de control de versiones durante el transcurso de su desarrollo.

¿Cómo lo conseguiremos? Haciendo uso de dos técnicas muy habituales en equipos que trabajan con prácticas como continuous integration o continuous delivery: Feature Flags (o Feature Toggles si leéis a Martin Fowler) y Branch By Abstraction.

Ambas estrategias nos permitirán fusionar código de manera regular sobre la rama principal, aún con funcionalidades parcialmente terminadas, evitando así mantener ramas en paralelo que podrían estar días (o semanas) sin integrarse con el trabajo realizado por el resto del equipo.

Las feature flags son, conceptualmente, bloques condicionales que permiten habilitar o deshabilitar una funcionalidad (o un camino de ejecución) en base a un conjunto de condiciones (como pueden ser: el entorno de ejecución, el perfil del usuario o un porcentaje de tráfico)

Pongamos como ejemplo que, en nuestra aplicación, llevamos ya un tiempo utilizando <AwesomeCalendar /> (un componente de terceros) como widget de calendario. En los puntos donde es necesario mostrar un calendario, importamos el componente y lo insertamos en el layout de la página.

import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <AwesomeCalendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}

Debido a una serie de requisitos, tenemos que crear un nuevo componente para mostrar un calendario que sustituya a AwesomeCalendar y le añada un extra de funcionalidad para dar cabida a nuevas historias de usuario. El desarrollo del componente se extenderá durante varias semanas.

El primer paso para poder integrar nuestro componente de manera continua es asegurar que somos capaces de controlar cuándo y cómo se utiliza para poder aislar a los consumidores de AwesomeCalendar de los cambios en el mismo. Para ello, vamos a empezar creando una nueva abstracción Calendar que pasará a ser utilizada por el resto de componentes y mantendrá la misma interfaz que ofrecía AwesomeCalendar:

import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

export function Calendar({ date }: { date: Date }) {
  return <AwesomeCalendar date={date} />;
}

Como vemos, la manera de consumir este nuevo componente sería muy parecida a la versión anterior:

import React from "react";

import { Calendar } from "../components";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <Calendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}

En este punto, ya podríamos fusionar nuestros cambios con la rama de código principal para que el resto de trabajo en curso pueda ir haciendo uso de nuestro (no tan) nuevo componente.

A continuación, vamos a crear una implementación muy sencilla de nuestro propio calendario, que empezará apoyándose en una implementación nativa de datetime pero respetando la interfaz original del componente AwesomeCalendar:

import React from "react";

export function NewCalendar({ date }: { date: Date }) {
  const value = /* implementation details */;

  return <input type="datetime-local" value={value} />;
}

Una vez hemos eliminado la responsabilidad de elegir qué calendario utilizar de los consumidores del componente, podemos utilizar feature flags para determinar qué calendario mostrar en cada momento.

En este caso, vamos a permitir que cualquier entorno que no sea producción utilice siempre nuestro propio calendario, con el objetivo de obtener feedback sobre su experiencia de uso a medida que avanzamos en su desarrollo:

export function isNewCalendarEnabled() {
  return process.env.NODE_ENV !== "production";
}

Este caso, representamos la feature flag con una simple función que comprueba el entorno de ejecución actual, pero existen sistemas más sofisticados para gestionar el estado de los toggles en nuestra aplicación.

Ahora, nuestra nueva abstracción Calendar (que hace las veces de factoría) puede hacer uso de esta función para determinar qué componente de calendario utilizar, manteniendo al resto de consumidores aislados de toda complejidad:

import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

import { NewCalendar } from "./components";

import { isNewCalendarEnabled } from "../features";

export function Calendar(props: { date: Date }) {
  return isNewCalendarEnabled() ? (
    <NewCalendar {...props} />
  ) : (
    <AwesomeCalendar {...props} />
  );
}

A partir de este momento, todas las pantallas de nuestra interfaz de usuario que necesiten de un calendario, utilizarán la abstracción Calendar y será esta misma abstracción la que se encargará de utilizar la implementación concreta del calendario que corresponda en función del entorno de ejecución.

Como vemos, aplicar técnicas como branch by abstraction y feature flags nos permite alcanzar un flujo de integración (y entrega) continua en nuestros componentes aportándonos beneficios cómo:

• Minimizar la superficie de cambios a fusionar cuando integramos trabajo en curso
• Tomar el control sobre cuándo se ejercita un camino de ejecución y poder habilitarlo y deshabilitarlo en base a una serie de condiciones
• Dotar a los equipos de negocio de visibilidad sobre el trabajo en curso en tareas de larga duración (sin sacrificar ninguna de las premisas anteriores)