DEV Community: Robert Basic

Being a Tech Lead

Robert Basic — Wed, 08 Dec 2021 14:44:30 +0000

I’ve been the tech lead of my team at Trikoder for just over a year now (380 days, but who’s counting?) I think this is a good time to look back at what this role means to me, the things I’ve learned, and mistakes I made.

My background

Ever since I started programming back in 2005, I sort of have known that “writing code and solving problems with software” is the thing I’ll do. As I grew older and more experienced, I’ve slowly come to realize that, well, writing software is only one part of the equation and there’s a bit more to it. Turns out the “people stuff” is quite important and necessary, even when dealing with computers all day.

Joining Trikoder

In the summer of 2018, I joined Trikoder as an external contributor on the Njuskalo.hr platform.
As part of the Common Base Technology (CBT) team, I’ve took part in work that enabled us to internationalize the Njuskalo.hr platform and launch bolha.com on the same code, as well as undertook some bigger refactors and rewrites to lessen the burden of technical debt and legacy code on other teams. We still have a lot of work ahead of us as 10 plus years of shipping fast tends to leave a lot of “baggage” behind.

What do I do as a tech lead?

I’ve been the tech lead of this small team for the past year and, mostly through trail and error, I’ve been figuring out what does this role expect from me. I have good support both from my team, my team lead, and from the company in general, so it’s been a great learning experience so far.
A thing I learned over the years is that one of the reasons “legacy code” happens is due to a communication breakdown between the business people that need the software to solve a particular problem, and the software people that write the software. This is why I believe the position of a tech lead is a unique one. We can help the business understand why delivering new features takes as long as it takes, or why is it necessary to do some seemingly unrelated code maintenance. But, communication is a two way street, so we also need to ensure that the developers can understand the business side of things, how it’s not financially viable to halt producing new features for several months to rewrite that ugly piece of code someone else wrote, or how this project might not be the best place to try out the latest and shiniest new technology. I see my main role as a tech lead to be a bridge in the communication between business and development.
Through regular communication with the other teams, I try to understand what parts of the platform should we focus on next when it comes to dealing with technical debt and legacy code. Then, together with the leader of my team, we try to come up with a strategy and goals that will get us buy-in from the business.
Within the team itself, I do my best to guide the team towards good technical and technological choices. To make sure the code we write (and don’t write!) is the best it can be under the current circumstances, that it’s aligned with both the needs of the business as well as with the overall architecture.
While I love nothing more than getting “into the zone” and delivering code, I’ve come to realize that that part of the job is gone. I’ve seen this mistake made by other tech leads, and then, sadly, made it myself. As a tech lead I can’t let myself focus too much on any single problem, because then I don’t see what else is going on in my team. I might miss out on an important decision being made, or someone might decide to not reach out to me for advice as they don’t want to disturb me.
I see myself now as an enabler — my work is to enable the other programmers on my team to shine. Enable them to learn, to grow, to get into the zone, to make an impact. Even enable them to fail.
And this is where I think I’ve come full circle as a programmer. When I was starting out I was always volunteering for the tasks that no one else wanted, the boring tasks, the non important but still have to be done tasks. I’ve started to pick up those tasks again, so that my team can focus on the important things.

Self-retrospectives are weird

Am I doing it right? I think so. It feels right. I’ll probably make a few more mistakes along the way, but that’s how we learn. I’ve been fighting this direction of my career for a long time, as I didn’t want to bother with “management”. Now that I see and understand what the position of a tech lead brings to the table, I’m going all in.

Until next time, take care my friend.

Naming things

Robert Basic — Tue, 18 May 2021 08:38:56 +0000

When we develop software, we name things. Things like variables, functions, methods, classes, interfaces, exceptions. Also database, database tables, columns in those tables. We name files our software uses or creates: configuration files, log files, lock files, temporary files… The list goes on.

And yet, how much thought do we put in in naming these “things”? Why should we care?

Why is naming important?

When we develop software, we make approximations of problems from the real world. We take those problems and we model them in software. These models help us solve the problems, but they are never perfect. They can’t be, because we lose information in the process of “translating” the real world problem into code. That’s why it’s important for us to preserve, as much as we can, the names of the concepts we are translating into code.

Good naming is important for the future programmer who will read the code. That future programmer can be anybody, with experiences ranging from none to over 20 years. It can as well be us, the authors of the original code.

Context matters

A big problem with naming things is that, when we are naming, we have all the context around that name built up. At that moment, we know why we are choosing that specific name. We’re also writing other code around that name, which gives us additional information and, well, justification, for why we think it is a good name.

But if we give that code to another programmer, or even if we ourselves revisit it after some time, most of the context that we had when we were writing that code is gone. The name might not be as good anymore like when we were coming up with it.

For that reason we have to consider what information will be available when reading the code, how the lack of the context we take for granted when writing, will affect the meaning of the name we chose.

When we’re coming up with names for things in our code base, it’s helpful to “switch” our mindset from writing code to reading code. Take a look at the names with this “reader” mindset and consider is the name giving answers to the whys, whats, and hows, or is it just creating an even longer list of questions?

Where will we use it?

It is also important to consider where in our code base will we use the thing we are naming?

Imagine we’re writing a repository to find a list of products from the database. We create an interface like this for it:

/** [@return](http://twitter.com/return) Product[] */ 
ProductRepository::find($filter): array

Looks okay, makes sense at the moment of writing this code. Later on we, our someone else, writes some other code that uses our repository of products:

$products = $this->repository->find($filter);

Still when we write this code, we know what it does. But lets switch our mindset to “reading” code. There’s at least three different questions that stand out: what repository are we working with, what are we finding, and by what criteria? The $products variable can give us a hint, a suggestion, but we need to double check to be sure.

A better line would be:

$activeProductsInTimePeriod = $this->productRepository->find($filterActiveProductsInTimePeriod);

Now we don’t have to guess and look at other code that we’re finding active products in a given time period. Someone will argue that the names are too long, or that the InTimePeriod appears twice in one line. Yes, but it appears twice only in this one line, we don’t know where else will be the $filterActiveProductsInTimePeriod or the $activeProductsInTimePeriod variables be used. In every other line they appear, these “long” names will carry enough context and information to the reader of the code that they will have no, or very little, questions about our code.

Make the names searchable

When naming things, we also have to consider that at some point we will want to search for that name across the code base. How unique is the name, how easy it is to find it among other similarly named things? Going back to our product repository example:

$products = $this->repository->find($filter);

All four names are hard to search for: products, repository, find, filter. They are not unique in any way.

If we look at the example with the improved namings:

$activeProductsInTimePeriod = $this->productRepository->find($filterActiveProductsInTimePeriod);

Here only the find method sticks out as not unique enough, so we should maybe look for a name that is a easier to search for.

There’s much more to naming things, and to naming them well. For the end I want to leave you with a good presentation on naming things by Peter Hilton: https://www.youtube.com/watch?v=SctS56YQ6fg

What’s your biggest challenge in naming things?

Test doubles

Robert Basic — Thu, 18 Mar 2021 07:46:20 +0000

Photo by Antoine Peltier on Unsplash

It is easy to be the proponent of the classical TDD or mockist TDD when we are starting to develop a new application, but what should we do when we inherit an application where the code is already written and the tests are no where to be found? My career as a software consultant gave me the opportunity to work on applications where design patterns, best practices, dependency injection, and everything else that makes a code base easy to work with are wishful thinking. The “easy” answer in those cases would be, of course, let’s rewrite the entire application from scratch. If an application enables a business to earn a living, has users using it daily, then a complete rewrite is rarely the correct answer, easy or not.

After a thorough investigation of the existing code base one of the first things we should do is to try and cover the existing functionality we need to work on with tests. Integration tests, unit tests, end-to-end tests, the more type of tests we can write, the better. For integration and end-to-end tests we should mostly focus on having a test database and a good set of fixture files, while for unit tests we’ll probably need to create test doubles for the dependencies. These tests should be a support for us while we are trying to learn, understand, and improve the existing code base, and those tests should change over time along with the code that we are improving.

Test Doubles

But what are these test doubles? They are objects that, in testing, can replace the real objects that would otherwise be created and used during the real execution of the application. Using test doubles in our tests we can ensure the isolation of the dependencies from the unit under test, to mimic classes that we didn’t even write yet, to allow us to discover the APIs of our classes by exploring how would they interact without worrying about their implementation detail, as well as keep the test suite fast as calls to databases or HTTP endpoints are replaced with these test doubles.

The process of creating a test double is called “mocking” and there are cases when the term “mock object”, or “mock”, is used instead of the term “test double”, whereas the truth is that a mock object is only one type of a test double. The types of test doubles we can create are:

Dummies
Fakes
Stubs
Mocks
Spies

They all have their place in the world of unit testing, regardless if we are working on a green-field project applying the classical or the mockist TDD process, or if we are working on a legacy application that is difficult to test.

Dummy is a type of test double that is created only to be passed around, but its methods are never actually called by any of the code that we are testing. It can be created manually or with a mocking framework. It’s most often used to fulfill the argument list for a method call.

Fake is a test double that is always manually created and it’s a simplified implementation of the same API as the real “thing”. An example of a fake would be an in memory database.

Stub is a test double that is used in the place of a real object, when we only need the test double to return a predefined result so that the code under test can be brought into a working state. It can be created manually, but a mocking framework should be used to help speed up the process.

Mock is the “big brother” test double of a stub. Besides setting a predefined return value, we can also set up expectations how the methods on the mock object should be called, with what arguments, and in what order. Mocks are most often used in the mockist style of TDD, and whenever we are interested in how the unit we are testing interacts with its (mocked out) dependencies.

Spy is a type of test double that records the interactions between it and the unit that we are testing and allows us to verify the method calls we’re interested in at the end. This approach makes it possible for the unit test to follow more closely the Arrange-Act-Assert style of writing unit tests.

Libraries for test doubles in PHP

In PHP we have several libraries to help us create test doubles.

PHPUnit, the most popular and most used testing framework in PHP, has its own built in support for test doubles.

Prophecy is a framework for creating test doubles that was initially built for the requirements of phpspec, but it can be used with any other PHP testing framework. Since PHPUnit 4.5 it bundles Prophecy within PHPUnit itself, but as of PHPUnit 9.x this bundling is deprecated and set to be removed in PHPUnit 10.

Mockery is another framework for creating test doubles. It can be used with PHPUnit, phpspec, Behat, or any other testing framework. I find it especially powerful when working with legacy code, due to its support for creating partial mocks or mocking hard dependencies.

It is also possible to test without mocking frameworks, but still use some types of test doubles.

Even though test doubles are helpful when writing unit tests, we need to use them sparingly. Test doubles require additional maintenance, and if we overuse them the quality of our tests can decrease.

What’s your take on test doubles? Love ’em or hate ’em? Let me know in the comments.

Test driven development

Robert Basic — Thu, 18 Feb 2021 08:14:11 +0000

As software developers, we should aim to write applications which deliver great business value to our clients, applications that solve real problems for the users, applications that are of high quality, and applications that are free of any defects. We should aim to write bug-free software.

Due to errors in communication between us and the clients, or in our teams, unforeseen circumstances in which our applications can and will be used by the end users, negligence, or purely due to lack of knowledge and skills, hardly any software we write is 100% free of any issues.

An industry standard in increasing the quality of software we write is the use of unit testing, a method of testing software that focuses on a single unit of our application and verifies that the unit is working correctly under different circumstances. These circumstances can vary from verifying that the output of these units are correct after providing them with different inputs, or making sure that the units can handle different scenarios during their actual production use, like missing database records, or unreachable 3rd party HTTP APIs.

A number of studies have been conducted and published on the positive effects of automated unit testing on software quality:

These unit tests, when automated, are the basis of a software development process called Test Driven Development (TDD). With TDD we first write the tests for our software, then we run the complete test suite to make sure that the new tests fail, followed by writing just enough code to make those tests pass. Then we repeat this entire process until the feature we’re implementing is complete. This approach to software development has the advantage that the development cycle is shortened and the bugs that come from misunderstanding requirements or from programmer errors are caught early. TDD also tends to drive the programmer towards cleaner code and the usage of design patterns, because code that is made easy to test is also easy to understand by other programmers and maintain in the future.

What the actual units of these tests are is usually up for debate, but in the case of Object Oriented Programming (OOP) the unit is most often a single class in our code base. Other units could be methods in our classes, or even a group of classes that form a single module. For the sake of this article, we will assume that when we are talking about a “unit”, we mean a single class.

Schools of TDD

When developing applications using the TDD process there are two schools, two approaches, we can take when it comes to writing our code. The first school, the older one, is the school of classical TDD, or the Chicago style TDD. The other one, the newer one, is the school of mockist TDD, or the London style TDD. Both of these schools have their advantages and disadvantages and which one is used is pretty much up to the developer, or to the team to decide. They can also be mixed; it is not unheard of to use one style in developing one part of the application and the other one in other parts. We should always use the right tool for the right job, after all.

When going with the classical TDD approach the code is usually developed from the inside out. These tests are good when we know in advance what are the classes and their methods and how they integrate with each other. It allows us to focus on one thing at a time, on the actual unit that is being developed. The tests verify the state of the unit after the tests were run and not on the communication between different objects that are used within the unit. The usage of mock objects in the classical TDD approach is usually frowned upon and when the unit being tested requires a dependency, the actual implementation of that dependency is being used in the test. This requires from us to write the innermost dependency first and then branching out from there, hence the “inside out” approach.

The mockist TDD approach allows us to develop our code from the outside in. These tests are good when we want to take a “discovery” path down our code base. The dependencies of the unit being tested are “mocked out” — -mock objects are created that mimic the behavior of the real dependency. The actual implementation of these dependencies that we are mocking can be written at a later time. This leaves us with the opportunity to start developing from the outermost layer and work our way in, discovering the API of our dependencies, hence the “outside in” approach.

Both classical TDD and mockist TDD have their place in the software development process and their strengths and weaknesses must be considered when we choose what approach are we going to take when working a particular piece of the application.