mfbmina.dev

As the software we work on grows, the code tends to undergo various changes and refactorings. During this process, we might simply forget pieces of code that were once used but no longer make sense in the project, the infamous dead code. A very common example is when an API is deactivated, and only the handler is removed, but all the business logic remains, unused.

Dead code can be defined as a function that exists within your codebase, is syntactically valid, but is not used by any other part of your code. In other words, it’s an unreachable function. Dead code brings indirect problems to a project, such as outdated libraries, legacy code, code bloat, security vulnerabilities, and so on. If it’s still not clear what dead code is, see the example below:

At my Circuit Breaker post, I mentioned that nowadays it is common that the application has to communicate with other ones, and with that, traffic control strategies become essential. Recently I’ve discovered the Token Bucket, a strategy based on tokens used to control the traffic.

Imagine that you have 5 tickets to a ride, and every new hour you get a new ticket, but you can never exceed the limit of 5. Every time you ride, a ticket is used. So, if you use all your tickets, you can’t ride anymore until you get a new one. It is a very interesting algorithm, used by the PIX (a Brazilian instant payment method), for not allowing an attacker to scrape all users’ data.

Hey guys, editing the post to say that after talking to some people, I noticed that I whole misunderstood how Go dependencies work, and I was expecting some feature that already kind of exists, since just what is used from the code is at the final binary! A special thanks to Laurent Demailly, from Gophers Slack, and to some Reddit users!

After many years working with Ruby, I migrate to Go without much experience with the language. My first friction was with dependency management because I always find it bad, with fuzzy commands and, the worst, without distinction between development and production dependencies, since both of them are included in the binary. Let’s take a look at a go.mod from a PoC:

One of my favorite features in Go is the possibility of writing benchmark tests. At Go 1.24, this feature has a new look, making it easier to use.

To demonstrate these changes, let’s suppose a function that calculates the factorial recursively and one that calculates it through loops.

func FatorialRecursive(n int) int {
  if n == 0 {
    return 1
  }

  return n * FatorialRecursive(n-1)
}

func FatorialLoop(n int) int {
  aux := 1
  for i := 1; i <= n; i++ {
    aux *= i
  }

  return aux
}

Previously, to write a benchmark, it was necessary to write down the whole execution loop of the test. When done, we need to run the command $ go test -bench .

After reading the book the Goal , I went after the next reading, and I was recommended to read The Mythical Man-Month, from Fred Brooks. This book is a computer science class, which I didn’t know yet, that describes the software development life cycle in the 70s.

The book’s main subject is told at the title: the mythical man-month. Man-month is a productivity metric like the ones that are used today, such as points, t-shirts size or whatever that is being used. The argument is the metric is failed and number of tasks, line of codes or features developed by someone aren’t constant between projects.

Nowadays, a huge part of a developer’s work consists in calling APIs, sometimes to integrate with a team within the company, sometimes to build an integration with a supplier.

The other big role in daily work is to write tests. Tests ensure (or should guarantee :D) that all the code written by us works on how it is expected and, therefore, it will not happen any surprises when the feature is running at production environment.

At the developing world, it is necessary to know how the application that you’re working on is behaving, and the most known way of doing that is by metrics. They can be of several types, such as performance, product, or health. Nowadays, Prometheus is the market way for collecting metrics.

It is an open-source service maintained by CNCF , the Cloud Native Computing Foundation. It works like the following: an endpoint is exposed, and it responds with a desired body format. Then Prometheus calls this endpoint time to time, collecting all the information from there.

At the end of 2023, my squad started its most important project. I assumed the project leadership role, organizing the project, coordinating the meetings, the release process, etc. At the first months, the project went well, as we took some hard decisions, proved a couple of concepts, and started the rollout for the first phase.

However, I always felt that I was holding the team back and being a bottleneck in the whole team. At a 1x1 with the head of the area, I told him about my frustration and got this answer back:

The first time I heard about RPC, I was in a distributed systems class while completing my bachelor’s in computer science. I like it but didn’t fully understand why I should use it instead of REST. Time passed, and I started working at a company where the legacy services use SOAP. I remember thinking: “hm, that’s cool! It is like RPC but using XML instead! Years later, I heard for the first time about gRPC, but I’ve never fully understood it until now!

When I chose to pursue a career in computer science when I was 15 years old, it was basically on liking math and physics. I want to distance myself from writing posts, essays, etc. Time goes by, and now, one of the things that I value at a mature company or team is the existence of technical documentation.

Docs help us to gain historical knowledge of our company, reevaluate decisions, and comprehend the trade-offs between all the decisions. It is also beneficial for the newcomers because it tells them a story. The richer in detail it is, the better it is.