DEV Community: Guilherme Froes

TDD: Act-First to Drive Design

Guilherme Froes — Fri, 14 Aug 2020 00:32:22 +0000

I know tests should drive the design, but I never really understood how to do it. And I don’t feel like asking so people don’t think I’m anti-TDD.

One of my students

Over the years being a tech lead, I saw this is a common challenge. And that having tests driving the design is difficult because we have to think differently.

I know a trick for that: you have to write the tests in a different way.

I’ll show you.

How a good test looks like

A good test follows Act, Arrange, Assert, the famous AAA format.

Arrange is where you set up the test. You create objects, data, configurations. Everything necessary for the test to run.

Act is where you execute the code to be tested.

Assert is where you check if the result is correct. You compare it with what you expected.

Example:

test('10H 10C 10S 10D 2H is a four of a kind', () => {
  // arrange
  var hand = new PokerHand('10H 10C 10S 10D 2H');

  // act
  const handName = hand.name();

  //assert
  expect(handName).toEqual('Four of a kind');
});

You read the test in the chronological order in which things happen: first arrange, then act and finally assert.

How to write tests

But that’s not the order you should write the test.

Kent Beck, the person who “rediscovered” TDD, recommends writing the test in reverse, beginning with the assert, followed by the act and then arrange.

Check it out:

When I test assert-first, I find it has a powerful simplifying effect. When you are writing a test, you are solving several problems at once, even if you no longer have to think about the implementation.

Where does the functionality belong? Is it a modification of an existing method, a new method on an existing class, an existing method name implemented in a new place, or a new class?

What should the names be called?

How are you going to check for the right answers?

What is the right answer?

What other tests does this test suggest?

Pea-sized brains like mine can’t possibly do a good job of solving all of these problems at once. The two problems from the list that can be easily separated from the rest are: “What is the right answer?” And “How am I going to check?

Kent Beck, on Test Driven Development: By Example (page 128, Assert First)

Kent argues that by writing the assert first, you’ll have the answers for these questions right away and then work backwards to answer the other ones.

I agree, but only if your main purpose for testing is making sure the result is correct.

Test Driven Development Design

When we’re designing, we’re creating how the object interacts with the world. When we’re designing, more important than the operation’s results, is the operation in itself: its name, its dependencies, parameters format and name, result type and so on.

What matters is not the answers to those questions, but to these ones:

Where does the functionality belong? Is it a modification of an existing method, a new method on an existing class, an existing method name implemented in a new place, or a new class?

What should the names be called?

And if this is the most important, the executed code should be the focus of the test. The result is secondary.

If you want to use tests to drive the design, test act-first.

Do it this way and see how your mind will flow from “test mode” to “design mode”.

(Header photo by Rod Long on Unsplash)

Learn how to fix the most common software design mistake people make. Subscribe to my newsletter and get the FREE email course.

The post TDD: Act-First to Drive Design appeared first on gui froes.

Solving Real World Bad Design by Applying the Tell, don’t Ask Principle

Guilherme Froes — Thu, 28 Feb 2019 18:02:00 +0000

Can you spot bad design when you see it? Can you tell what’s wrong here?

if (!response.getStatusCode().is2xxSuccessful()) {
    logError(response.getBody()); 
    throwException(response.getStatusCode()); 
}

The snippet above is an example of a pattern we often see in the wild:

if(someObject.getSomeAttribute()) { 
    doSomethingWith(someObject); 
} else { 
    doSomethingElse(someObject); 
}

Why should I care?

For us to understand what are the issues and why this is bad design, let’s take a look at the full picture. This is where that snippet came from:

public class PaymentProcessorClient { 
// some code removed for brevity's sake 
    public Sale processPayment(Payment payment) {
        ResponseEntity<Sale> response = rest.postForEntity("https://payment.com/payment", payment, Sale.class);

        if (!response.getStatusCode().is2xxSuccessful()) {
            logError(response.getBody()); 
            throwException(response.getStatusCode()); 
        } 
        logSuccessfulPayment(payment, response.getBody()); 
        return response.getBody(); 
    } 
}

This class is what is usually called a client, its purpose is to talk to some external service. In this particular case, it is responsible for creating a payment on the fictional payment.com web service.

(By the way, this is real code from a real product that my team is working on right now. I just made some minor changes to preserve our client’s identity and not to expose them to any risk. I also removed some code to save space. These changes should not interfere with the understanding of the concept I’m trying to explain here.)

Let’s take a closer look on the processPayment method. The first line is where the main functionality is: it makes the call to the service and saves the response in the response variable.

ResponseEntity<Sale> response = rest.postForEntity("https://payment.com/payment", payment, Sale.class);

Next, it looks into response and, if the payment creation was not successful, it logs an error and throws an exception:

if (!response.getStatusCode().is2xxSuccessful()) { 
    logError(response.getBody()); 
    throwException(response.getStatusCode()); 
}

If the payment creation went fine, it logs the result and returns the response body.

logSuccessfulPayment(payment, response.getBody()); 
return response.getBody();

This code works, but as I said, it could be better designed. I’m going to show why and how.

It leads to duplication

In our example, every time you make a call to the external service, you have to check the response and do something based on what that response looks like. If you have 3 operations like “make a payment”, “void a payment” and “do a refund”, you would have this structure repeated 3 times.

Code duplication is bad on itself, but the real problem is the duplication of an idea, or concept – based on what the response looks like, do something with it. This concept is expressed in multiple places in your code and, because of that, if it changes, or the implementation changes, you need to change in all the places it is expressed, which is very inefficient and error prone.

The duplication also makes it harder to reuse the code since the concept is not isolated and expressed in one unique way and place.

It increases coupling

When we have something like:

response.getStatusCode().is2xxSuccessful()

The PaymentProcessorClient class needs to know how the response and the statusCode objects are implemented. It needs to know that response object has a getStatusCode method and that the statusCode object has a is2xxSuccessful method. This knowledge about how other objects are implemented is a form of coupling.

What happens if one of these object’s implementation change? What if the is2xxSuccessful method gets deprecated and replaced by is201Created or something similar? You would have to go into your PaymentProcessorClient code and change it. You would have to change one class for other reason than a change in the main logic or responsibility of the class.

This excessive and unnecessary coupling (plus the duplication issue I talked above) have cascading effects, making one change to one class trigger a wave of changes throughout your code base. It shouldn’t be hard to see why this is dangerous and highly undesirable.

It clutters the code

Let’s remember what the PaymentProcessorClient and processPayment method are supposed to do: talk to external payment service and make a payment.

Now, notice all the code that’s not strictly making a payment on the service.

public Sale processPayment(Payment payment) { 
    ResponseEntity<Sale> response = rest.postForEntity("https://payment.com/payment", payment, Sale.class); 

    if (!response.getStatusCode().is2xxSuccessful()) { 
        logError(response.getBody()); 
        throwException(response.getStatusCode()); 
    } 

    logSuccessfulPayment(payment, response.getBody()); 
    return response.getBody(); 
}

We have code looking into the response, code logging information and code throwing exceptions. All of this needs to happen, but they’re more surrounding or supporting the main idea of this class. Their presence also makes it harder to read and understand the idea of PaymentProcessorClient.processPayment, making it harder and more expensive to maintain this code.

How can you make this better?

The solution here is to separate the two concepts that are tangled up:

Concept 1: making the call to the external service;

Concept 2: act based on the response from the service.

The first concept is implemented by PaymentProcessorClient‘s processPayment method, we still need to find a home for the second one. Since it involves looking into the response and based on that doing something with the response, having this concept implemented by the response object – or something similar, sounds reasonable. Let’s see what it could look like.

The solution

The first thing we need to do is to rename the Sale object to SaleDTO. So far, what we’ve been calling sale is just what the external service sends back to us after we make a payment. It’s just a data structure, so it makes sense to rename it SaleDTO.

public SaleDTO processPayment(Payment payment) {
    ResponseEntity<SaleDTO> response = rest.postForEntity("https://payment.com/payment", payment, SaleDTO.class); 

    if (!response.getStatusCode().is2xxSuccessful()) { 
        logError(response.getBody()); 
        throwException(response.getStatusCode()); 
    } 

    logSuccessfulPayment(payment, response.getBody()); 
    return response.getBody(); 
}

SaleDTO just holds the data we get back from the service. We need a real object that implements the concept of a sale and will have the behaviour we want – that was previously done by PaymentProcessorClient. Let’s create a new class Sale, and it will be what we return from processPayment method. Sale will be built with a ResponseEntity object and the Payment object.

public Sale processPayment(Payment payment) { 
    ResponseEntity<SaleDTO> response = rest.postForEntity("https://payment.com/payment", payment, SaleDTO.class); 

    if (!response.getStatusCode().is2xxSuccessful()) { 
        logError(response.getBody()); 
        throwException(response.getStatusCode()); 
    } 

    logSuccessfulPayment(payment, response.getBody()); 
    return new Sale(payment, response); 
}

Next, we move the behaviour that was previously on PaymentProcessorClient to Sale.

public class Sale { 

    public Sale(Payment payment, ResponseEntity<SaleDTO> saleResponse) { 
        this.saleResponse = saleResponse; 

        if (isResponseUnsuccessful()) { 
            logError(saleResponseBody()); 
            throw new Exception(saleResponseStatusCode()); 
        } 

        logSuccessfulPayment(payment, saleResponseBody()); 
    } 

    private SaleDTO saleResponseBody() { 
        return this.saleResponse.getBody(); 
    } 

    private HttpStatusCode saleResponseStatusCode() { 
        return this.saleResponse.getStatusCode(); 
    } 

    private boolean isResponseUnsuccessful() { 
        return !saleResponseStatusCode().is2xxSuccessful(); 
    } 
}

The last step is to clean PaymentProcessorClient‘s processPayment method:

public Sale processPayment(Payment payment) { 
    ResponseEntity<SaleDTO> response = rest.postForEntity("https://payment.com/payment", payment, SaleDTO.class); 
    return new Sale(response, payment); 
}

We applied here the Tell, don’t ask principle. Instead of asking an object something about it and then doing something with the object or asking it to do something, we just tell the object what we want, and it should take care of it. In our case we just tell the object to exist!

Now we have a clean PaymentProcessorClient and a smart _ Sale _ object that knows what to do when something goes wrong. Let’s see how this design solves the problems we described.

Is the design better now?

The need for duplication of the concept – reacting to a bad response – is gone. It is implemented by the Sale class that is created to capture the response of all operations on the external service, like refund and void payments.

Coupling between PaymentProcessorClient and the Response and StatusCode classes is gone. Those are now coupled to the Sale class, which feels better to me because they are more related to each other.

We made those classes a little less coupled, isolating the dependency on private methods by using the SelfEncapsulation technique. Check out saleResponseBody, saleResponseStatusCode and isResponseUnsuccessful methods.

Some coupling will always exist since objects need to know something about each other in order to collaborate and work together.

The code also looks cleaner and more understandable since we moved it to more appropriate locations.

Easy to spot, simple to fix, big impact

Every time you see this pattern:

if(someObject.getSomeAttribute()) { 
    doSomethingWith(someObject); 
} else { 
    doSomethingElse(someObject); 
}

There’s a very good chance that there’s an opportunity for design improvement.

This design leads to duplication, unnecessary coupling and cluttered code.

Identifying some underlying concept and moving it to its proper object will get you code that’s easier, cheaper and more pleasurable to write and maintain.

The post Solving Real World Bad Design by Applying the Tell, don’t Ask Principle appeared first on Gui Froes.

Build people, not tech

Guilherme Froes — Mon, 04 Feb 2019 23:53:49 +0000

Retrospectives, build-measure-learn and continuous improvement are all activities and practices that companies and their agile teams do to support project delivery and product development.

I think this is wrong.

These things are way too important to be only supporting the business.

Not long ago, businesses used technology to accelerate, to automate, to improve themselves somehow. Teams would form, the technological product would be built, and the business would cary on with its life.

It is different now. The business is the technology. The very existence of the business depends on the continuous production and operation of technology.

Because of that, companies should focus not on producing technology but on continuously cultivating people’s capabilities.

Retrospectives, build-measure-learn and continuous improvement must abandon the position of supporting activities and occupy business’ center of attention. Teams and their learning capabilities – not their products – are business’ competitive advantage. And this should reflect on investments, recruiting and promotions.

Technology companies must transform into knowledge and skills companies.

The post Build people, not tech appeared first on Gui Froes.

Clever code is bad. Don’t write clever code.

Guilherme Froes — Tue, 25 Sep 2018 01:27:44 +0000

Wait! Isn’t code supposed to be smart? Programming IS hard! We have to be smart!

Nope.

Code is supposed to be simple. And programming is no place for being a smart-ass. Let me explain.

What is clever code

Clever code is code that when you read it your face goes like this:

“Interesting..”

Or like this:

“Oh! I get it..”

Or like this:

“Riiight..”

Clever code is code that should be instantly and effortlessly understood – but it’s not.

It can exist in many forms. It can be that one liner that does too much.

return i > 0 ? i << 2 : ~(i << 2) + 1;

“WTF?” (Apparently, this multiplies it by 4 and makes it positive – who knows. Got it from here.)

It can also be that super over designed set of classes that is so abstract that you spend an hour navigating the inheritance hierarchy and still have no idea what’s going on.

“See? It’s THAT simple!”

“But that code looks pretty simple to me! What’s the problem?”

Yes, code cleverness is subjective, a matter of opinion. What is hard for me to understand might be easy to you. And that’s my point with this article:

We don’t write code for ourselves, we write for others (and the other might be future-you)!

Programming Wisdom

@codewisdom

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler

12:37 PM - 06 Jun 2018

521 1468

Clever code is bad because if it’s not understandable it’s not maintainable.

It’s bad because debugging it will take energy that could be applied to higher value activities such as building new features, improving tests, automating tasks or trying new technologies and tools that will deliver value to your customer.

And it’s bad because it makes coding look harder than it is. It makes people feel that they don’t know stuff and causes friction where we should be making things easier, smoother.

Level up as a developer

Caring about the consequences of clever code and avoiding them is one of the things that makes you a senior developer, not the number of tricks or obscure language constructs, or your ability to write a whole program with one line of code.

It’s common for beginners to write clever code. Not the absolute beginners – they are still learning the language – but those who are already fluent and learning new tricks. Those folks are proud and want to show off all their skills.

We should learn new tricks but also learn when to use them. And more important: learn the fact that *being capable of doing something, doesn’t mean that we should. * The same way you don’t wear shorts to a wedding and you don’t wear a suit to the beach, there’s a time and a place for everything.

One sure way that I can spot a beginner is by the clever code one produces. It shows that the person doesn’t quite get that software development is a social activity and that there’s no place for ego.

A big part of the transition from beginner to senior dev is this understanding that our purpose is to build value to the organisation that employs us and that code is only a tool and should be treated as such.

So, if you want to become a senior dev or a technical leader, you must master and teach less experienced folks how to keep the codebase clever code free.

“Okay, got it. What should I do now?”

It’s hard not to let some clever code slip into the codebase every once in a while. After all, it’s not always evident that some code is clever – it might be simple to you, right?

That’s why we need to watch ourselves all the time. Here’s a few ideas that will help:

Use the common way of doing stuff

Usually, there is more than one way of doing something. Use the oldest, most boring, obvious way, that any beginner would understand. No magic, no frameworks, no anything that would require extra knowledge or brain cycles to understand. Instead of doing:

while (*d++ = *s++);

Do this:

strcpy(destination, source);

Don’t try to save space on your hard drive or screen

It doesn’t matter if you end up with more code and bigger files: storage is cheap, people’s effort and time are expensive.

Extract methods, use meaningful names – use as many words as you need to make your intent come across. Use spaces, line breaks, format accordingly. Turn this:

(people != null) && (people.get(name).getAge() >= 18) ? people2.add(people.get(name)) : people3.add(people.get(name));

Into this:

Person person = allPeople.personNamed(name); if (person.isAllowedToDrink()) { listOfDrinkingPeople.add(person); } else { listOfNotDrinkingPeople.add(person); }

Objects with behavior help a lot as well.

Get feedback

Pair programming is great for this. Ask your colleague: “Do you understand this?” “Or is it better this way?” Look if they are making one those faces.

Watch your own reaction for feedback: if you make a face reading some code you’ve written, change it!

Do code reviews – have the team reading the code and giving feedback to one another.

What’s next?

Now you know what clever code is, why it is bad and how not to write it. But what about the other people on your team? If you want to know how to talk them into writing clean code, checkout this article in my site.

The post Clever code is bad. Don’t write clever code. appeared first on Gui Froes.

3 books that will take you to the next level

Guilherme Froes — Fri, 23 Mar 2018 20:19:47 +0000

You can write code and make the computer do what you want – no problem. You can even do it in more than one language and you’re fluent in many frameworks. You know all your data structures and algorithms and can use databases and external APIs without breaking a sweat. And you’ve been doing it for some years now.

However, even with all this knowledge and skill and always getting the job done, sometimes you’re not sure if you’re doing it right.

Maybe your code starts pretty good, everything in place and working fine, but after a while, when new functionality is being added, it starts to become confusing and messy. Or bugs start to pop up and it becomes harder and harder to fix stuff without breaking something else.

You spend a lot of time chasing and killing bugs, and coding, which used to be fun, becomes frustrating.

You feel that there must be a better way to do things. And there is!

What you need is a new set of skills. You need to level up.

There are many ways to do it but here I’m going to recommend 3 books that will transform the way you think about and write code. Of course there are many more that are worth your time and money, but I think these 3 cover a lot of ground and will get you a great bang for you buck.

Practical Object-Oriented Design in Ruby: An Agile Primer – Sandi Metz

You probably think you know OOP but Sandi will show you there’s way more to it, and how proper OOP design allows you to write beautifully simple maintainable code. It doesn’t really matter that the examples are in Ruby, the concepts are universal and if you’re familiar with any OOP language you should be good.

By the way, Sandi is awesome and you should read all her books and watch all her talks. Seriously.

Test Driven Development: By Example – Kent Beck

TDD is a style of development where you write a tiny test, write the code to make the test pass, refactor the code and repeat this same short cycle for each new code behaviour. Those tests guide you to a better design while keeping a safety net for refactoring and fixing bugs. TDD by Example is the book where its creator (or “re-discoverer”) describes the classic technique that will, for sure, turn the way you write code upside down.

Growing Object-Oriented Software, Guided by Tests – Steve Freeman & Nat Pryce

This book covers a lot of ground combining OOP design, TDD and use of Mock Objects for growing complex codebases. It describes the building of a system from scratch with the decisions, tools and techniques, all shown with the evolution of the code. It’s one of my very favorites and probably the one I recommend the most.

As I said, there are many more excellent books I could recommend for someone aiming to acquire a more senior set of coding skills, but this short list should be enough to introduce you to a new world and bring you back the joy of programming.

What are you waiting for?

The post 3 books that will take you to the next level appeared first on Gui Froes.