Happy New Year 2017!!!

class HappyNewYearWishes {
   private YearFactory yearFactory = new YearFactory();
   private BlogRepository blogRepository = new BlogRepository();
   private YearRepository yearRepository = new YearRepository();

   @Test
   public void youShouldMakeAllWishesComeTrue() {
      Year year2017 = yearFactory.aNewYear(2017);
      Person you = blogRepository.findAllReadersOf("Let's talk about Java").you();

      you.acceptChallengesOf(year2017);

      assertThat(you.allGoalsOf(year2017).achieved()).isTrue();
      assertThat(you.didLearnSomethingNewIn(year2017)).isTrue();
      assertThat(you.booksReadIn(year2017).count()).isGreaterThan(you.booksReadIn(aYear(2016)).count());
      assertThat(you.currentJob().isGreat()).isTrue();
      assertThat(you.currentSalary()).isGreaterThan(you.salaryIn(aYear(2016)));
      assertThat(you.wantMoreIn(aYear(2018))).isTrue();
   }

   private Year aYear(int year) {
      return yearRepository.find(year);
   }
}

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?

Brace yourself for a new blog design

As you probably noticed I have slightly changed the design of my blog. I hope you like it and it’s more visually appealing than the previous one. I would be more than grateful for your comments regarding the change. Is it better? Worse? Or maybe something is missing?

I also added new subpages.
On the first one, you can find some information about me and contact details which may, some time, come in handy.
On the second one, there is a list of conferences and talks where I will have (or already had) pleasure to talk and share my ideas. You may find there also a links to slides and videos.

I hope that all changes are steps in the right direction.
I encourage you to write comments and share your ideas or suggestions. If there’s something that you would like to find here - simply leave a comment. It may help me refine the blog even more.
Don’t hesitate, write your opinion and help me improve.

Pair Programming for the rescue!

Those of you who’ve already read some of my articles have probably noticed that I’m sort of a developer that is extremely passionate about code that is clean. The reason behind this fanaticism is not my fascination with pure beauty because I’ve never treated code as art as such. I’m so much focused on writing clean code and maintaining code readability because ... I’m a really lazy person.
I just think that code that is easy to understand makes my (and not only my) work easier. I don’t have to spend tremendous amount of time going over the code and seeking answers to my questions.

Want to talk?

It’s been awhile since my last article. I want to assure you that writing is still on top of my list of priorities. Recently I was just overwhelmed by lots of activities that are extremely important for me. All of them required some effort and preparation but I think that I’m almost ready to come back to writing. So expect more really soon!

Many parameters and lost information

The less code, the better? The fewer objects, the better? Is it true? As usual, it depends.

There are cases when by adding something more we are adding unnecessary complexity. It happens when we are creating interfaces or other abstractions just because “we may need this additional flexibility in future”. It happens when we forget about YAGNI principle and we are writing code that may make our life easier in case of new requirements that… may never come.

Implementation, behavior and the amount of the code...

Implementation, behavior and the amount of the code... Today is the right time for another code-related question that I’d like to ask.
Take a look at these methods:

refactoring.setState(IN_PROGRESS);

refactoring.setState(VERIFIED);

refactoring.setState(DONE);

To make everything clear, we can easily assume that each invocation is done in a different place and after different activities have been completed.
There is nothing exciting in this code and probably you saw something similar in your code bases many times. Nothing complicated. We are just changing the state of the object.

So, now’s the time for the question: what’s wrong with this code?

Conjunctions we... hate

Recently I’ve written about implementation-related names and I’ve presented a few examples where the method name was incorrect because of its strong relation with the body.
At one moment, we had the following code:

boolean isComplexOrUnreadableWithTests() { 
    return (complex || unreadable) && tests.exist(); 
}

Just to remind you of the context: it was supposed to find out whether we may or may not do the refactoring:

if (code.isComplexOrUnreadableWithTests()) {
	doRefactoring(code);
}

Recently I’ve told you that the name is wrong because of its direct relation to the implementation. However, this is not the only problem. The use of conjunctions in the method’s name is a sign that we could not find a right name and we just list all known things that we’ve done. It does not matter whether this list is implementation- or logic-related.

The name should express the intention

This time I will start with a code sample. Take a look at this:

if (code.isComplexOrUnreadable()) {
    refactor(code);
}

Can you tell me what is wrong with this code? No?

Let me ask you another question then. How do you think the implementation of isComplexOrUnreadable() method looks like?
I assume that many of you would imagine something similar to this:

boolean isComplexOrUnreadable() {
    return complex || unreadable;
}

Am I right?

Ok, so let me ask you again: can you tell me what is wrong with this code?

Should you follow the rules?

In the last article I wrote that I’m a big fan of tools for static analysis. Those tools help you follow established rules. To be more specific, they’re yelling at you through red builds whenever you break these rules. Isn’t it great? Before your code gets under the review, we are already sure that many things have already been checked and we don’t have to bother ourselves with verifying the code from this side once again.
However, this solution comes with a problem. When a developer receives feedback, they know what is wrong, but not always know why a particular part of the code was recognized as invalid.
And lack of understanding of rules can lead to huge damage.

What is a problem?

Recently one of my colleague from the team has tried to push code for a review. Yet, static analysis build didn't let him do it. It failed. The problem lay in a missing constructor for a util class. Ok, fix it and move on, but… after adding the constructor another issue was found - there was not even a single test for a private constructor. For the sake of coverage!

I don’t want to talk whether our rules are good or not. I want to talk about a feeling that may appear after some time of receiving such messages.
What’s the feeling I’m writing about? Irritation. Not because you’ve made a mistake in your code. It’s not a problem, everyone does. Not because build was red. It’s great, it should fail in case of our mistake. Not because we have to solve an issue. It’s reasonable that you are fixing issues in your code. The problem is that we learnt nothing. There is a message which describes WHAT is the problem, but it doesn’t explain WHY it is a problem.

Why it is a problem?

When you don’t understand the reason next problem found by static-analysis tool becomes annoying noise, not a good suggestion. You start looking for an exception from the rule, for an excuse to break it. This is not because you don’t want to create a high quality code. You do want, but until you don’t understand the reason behind the rule it may look stupid to you. It may look worthless.

What will happen if you don’t find an exception? Probably you will start to obey this rule. Automatically. But it will still be against you, it will bother you. And you won’t follow such suggestion, because you know why it is important. No, you will follow it because you have to. Such practice will be full of negative emotions. And if a new person some day asks you why you’re writing code in this way you will tell them that it is because “some stupid rules”. And now there will be two people who will apply it into their code without understanding.

Is it really a problem?

Is it really so bad? Isn’t it better to have a developer who writes good code without understanding rather than allowing them to write worse code?
Well, yes. If we are looking at this from this angle, this is true. However, we want to work with good developers, we want to spread the knowledge and understanding of good practices. We want to teach others and share experience with them. It will be a win-win situation for both sides. We want to work with people who can improve our solutions and challenge our ideas.
Over time, the quality of the code will get worse if we have to work with people who follow the rules blindly. Why? Because of the lack of knowledge. Code review, refactoring, design and redesign, etc. those are activities that require specific knowledge. If we don’t share it, there will be a huge number of developers who won’t do it because they wouldn’t know how.

Fix it!

After we fixed all issues in the code we had a great discussion about values of those static analysis tools. Values and the risks that I explained above.
When we talk about problems we start to think what we can do to avoid them. Or at least minimize. How to change a description into an explanation?
We come up with the idea to change default messages. Add explanation why a described problem is a problem. Or at least add a link. We should avoid leaving people without knowledge.
Our idea is to change those failing builds into a great lesson!

This is our idea and I’m pretty excited about it. I know it would take time to improve all messages, but on the other hand I’m also pretty sure it is worth the effort.

What do you think about it? Maybe you have your own idea? Share them in comments. It would be great to know your ideas.

What’s really matter? When you break a rules!

I’m a big fan of tools like PMD, FindBugs, checkstyle, etc. Those tools are really helpful. Thanks to them you don’t need to worry about many small issues. You don’t have to verify whether an author of the code you are reviewing follows coding standards or other agreed practices. Your tools will do it for you.

Need some explanation?

As developers we are doing everything what we can to increase the quality of the code we are working on. To make it easier, we learn to use new tools, techniques and practices. Each tool makes us stronger and better weaponized for the fight for the sake of the code quality.
However, a tool won’t be useful until we use it according to its design and intended purpose.
What are the main reasons behind doing a code review? In my opinion they include sharing knowledge (learning and teaching) and increasing readability and understandability of the written code.

Code Review and Single Responsibility Principle

According to the Single Responsibility Principle each unit in our code should have only one reason to change.
Code Review, on the other hand, is a technique that helps us improve the quality of our code and increase its readability.
I believe that you know both the principle and the technique.
The question is: why do I juxtapose them in one article?

Well, if SRP is about one reason to change code, then I think that code in the review should be organized around one change. The author should organize the commit of the code which is sent to the review in a way that will reflect only one change.

Code Review and the effort

Code review is really useful and important. However, it requires some amount of effort from the reviewer. A developer that will read the code will have to understand what needs to be implemented. They need to know whether expectations are met. They need to have enough understanding to verify the quality of the code and its readability. All of it requires both time and full attention. During the review, if you want to do it right, you have to stay focused.

That’s why we should make code review as small as possible. To decrease the effort that must be put into this activity.

Code Review and only one change

Many changes mean that you are jumping from one place to another and you are trying to figure out which change is the reason of which modification of the code. It makes reading the code harder, because you need to keep in mind many contexts and reasons. It makes it harder to find bugs in such situation.
More things that are merged can go unnoticed..

When the code that is put to the review, it has various reasons for modifications than, except for everything I mentioned in the previous paragraph, we need to carry out two additional activities: switch contexts and group changes into subsets organized around each change. And we also have to remember that each change can have an impact on another.

So the amount of the effort and time that reviewer needs to invest into a code review is:

Number of changes * effort needed for one change + switching the context + understanding implication

I heard more than once that “it is better/easier/faster to do one code review instead of many, because you will do a review only once”. As you can see, though, putting many things into a code review is not simple multiplication of effort needed for one review.
Unfortunately there is additional complexity in this equation.

Many changes in one review

The additional complexity of the review is not the only thing that stands against putting many changes into one commit. What is also important, many changes in one commit mean less readable history so when you want to find something, it would be harder because some changes will be merged with other changes. What would be the name of your commit in that case? It will need to either focus on the most important change or it will be something meaningless, because you will try to use one sentence to explain many things that were modified.

Such thing doesn’t help when you have to find a root cause of some issue or you want to understand some part of the functionality. It is hard because of the same reasons that make the review of such code hard - complexity and presence of many contexts.

One change at a time

What do you think about this idea?
Let’s organize our commits around a single change.
Let’s make things simple and easier for us and all of those who will read the code.

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?

The places where you want to be

Today I would just like to invite you to a few conferences/event where I will have a pleasure to talk.

The first exception changes the rules of the game

We are developers who care. On a daily basis we use techniques and practices that help us make our code easier to maintain, develop and understand. We carry out code reviews, pair programming, TDD, etc. We use tools that allow us to automate many things. We have rules that help us protect common coding standards and design practices. Rules that we agreed to follow. Rules that help us improve the quality of our code and its design.

Yet, there is a one challenging thing in following the rules. If you agreed to follow them, you should not allow for any exception. Why? Because the first exception is the first step for more exceptions. The more exceptions are made, the less valuable the rule becomes.

@Autowired all the things!

Recently I have written that @Autowired annotation make our lives easier in that it allows us to write less code. However, using it may often make your design more complicated. Especially when we are talking about using it on class’s properties. It makes it easier to violate Single Responsibility Principle. It makes it easier not to notice that.

It is ok to use @Autowired with properties, yet, I think, that presence of the constructor visualizes the problem with too many dependencies when it occurs. Even without exercising additional care from our side.

@Autowired and optional dependencies

@Autowired annotation makes our lives easier. It also can result in decreased amount of code if we are using it on properties of the class. We need neither constructors nor setter methods. It looks great at first glance, but the benefits rarely come without cost.

Today I want to make you aware of the costs that have to be paid.

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?

Constructor or setter?

It goes without saying that every object needs to be created before it can be used. It does not matter whether we are talking about a domain, frameworks, libraries or any other type of the classes. When your code is an Object-Oriented, those classes are only definitions of the objects. You cannot use objects before they are created.

When we are talking about object’s initialization, we often need to think about dependencies. How will you inject them? Will you use the constructor or setter?

Abstract Factory or Factory Method?

Today I would like to tell you about Factory Method Pattern and Abstract Factory Pattern. The purpose of the article is to help you recognize places where one of them should be used.

Performance improvements… or experiments?

The project I’m involved in will face great challenges in the upcoming years. That was the reason why we have decided to focus on improving performance of the application before these improvements become a necessity.
How to increase efficiency? Stability? Responsiveness? How to prepare for future? That was the question that we asked ourselves and our goal was to find the answers.

We prepared the list of the challenges and potential improvements that can help us face them. Then we had to choose the most important items from the list. Each of us had a chance to share their opinion, share their view and suggestions.
During this conversation one of us reminded us about the most important activity that needs to take place before any other - we have to improve the measurement of our application’s performance.

We cannot start to improve, before we’ve got nothing but assumptions!