Link Dump #210

Friday is the perfect day for the reading mood:

Link Dump #207

What do you need to relax? How about something worth reading:

Link Dump #180

Friday, coffee, something to read - couldn't be better :)

Link Dump #162

Is there a perfect moment for reading? Definitely the "good enough" is the one you found something worth reading:

You can't stop degradation

There are a lot of patterns, techniques, and approaches that help to write understandable code and build an architecture possible to change. 

The difficult aspect of development is the fact that whatever you will do, the code and the architecture will degrade. 

The question is, why regardless of tries and efforts we cannot change that? 

Link Dump #43

It's hot. So how about ice coffee and something to read?

Refactoring Playground

Refactoring is one of the most essential activities developers must do to continuously improve the code they are working on. You can refactor on various levels: changing the implementation of methods, modifying how classes talk to each other, and redesigning the architecture.  

Today I want to share with you the repository I'm using to practice and teach others how to refactor the code.

Test-Driven Development - you are doing it wrong!

Test-Driven Development is one of those techniques that somehow is not as widely used as it should be. I know a lot of developers who can agree on the benefits it brings. Yet the same developers, when asked about practicing TDD, answer: “it does not work for me”.
When I tried to understand the “why” behind this statement, they start to struggle to find an explanation. They say they only add simple features. They say their application is not that complex. They have no time. Many of them tried, but it was “too time-consuming”, it cost too much effort.

I pair with some of them. On a couple of occasions I had long conversations with them to understand how they were doing it? What went wrong? What’s the conclusion? In many cases, the problem lies in the basics - they simply tried to apply TDD to every newly created object.

Just stop for a moment

I know there are deadlines in front of you that need to be met. They are the reason why you keep writing code. They are the cause of your lack of time - you are running from one deliverable to another, trying to deliver as fast as possible. Trying to deliver with the highest quality possible.

Refactoring vs. Redesign

It often happens that developers use words Refactoring and Redesign interchangeably. Why? I think that is because in both cases we are ending with the same result - code that is changed, but it does exactly the same thing as it was capable of doing at the beginning of the process.

Yet, in my opinion those words are not exact synonymous and before we will start to refactor the code it is good to know the difference.

For the sake of laziness!

I like well written code. I like to reach out for perfection. I like to look for the most suitable design and solution. I’m doing it not because I treat software development as a kind of art and myself as an artist. I never looked at this in this way. I’m doing it, because I know it pays off. And one of my greatest motivators is my own laziness.

Do you really need instanceof?

Using instanceof is a code smell. I think we may agree on that. Whenever I see a construction like that I’m sure that something went awry. Maybe someone just didn’t notice a problem when making a change? Maybe there was an idea, but it was so complex that it required so much effort or time that a developer made a decision not to do it? Maybe it was just laziness? Who knows. The fact remains that the code evolved into such state and we have to work with it.
Or maybe there is something that we can do about it? Something that will open our code for extensions?

First for test, second for implementation!

Test-Driven Development is a great technique, isn’t it? Today I want to propose you an experiment that may help you convince all of those struggling developers that writing code in such manner really improves your code and development.
What is the experiment about? It’s about only one, tiny commit which will force you to practice this technique for some time. Talk with your team/teams and propose a new way of doing pull requests. The first commit for test, the second for implementation. Easy, isn’t it?

Method’s name change a lot

A few days ago I tried to help you with making a decision when you should use constructor and when setter.
In one of the paragraph I wrote:

I don’t like setters. Why? Because those methods in some way break encapsulation.

After sharing this post there were developers that were arguing that setters can be useful.

What can I say?

Growing Object-Oriented Software, Guided by Tests

It’s been awhile since my last post. Recently, there have been many conferences and meetups I had pleasure to spoke at. Making presentations, carrying out research, readings, conducting reviews, etc., everything takes time. I need to admit that I like each part of this process, because I always learn something new. Even if I’m reading the same materials, blogs, books, even if I’m thinking once again about the same topic, I always find some things I didn’t noticed before.

Do you really want to test it?

I’m probably not the only one who had a chance to participate in deliberations over whether some private method should be tested (because it’s worth it) or not (because we shouldn’t test private methods). I’m not writing about pure theoretic conversations while you’re filling your cup of coffee and talking with your colleagues. I believe that in those moments most of developers would tell you a firm NO.

But what about situations when you are working with real code? When all those rules and principles are not so strictly followed? Would they also say NO so firmly? Based on my experience, I can tell you they wouldn’t. At least not always.

Ok, but should they? Should we? Or is it yet another nice-to-follow rule the observance of which depends on context?