Monday, May 06, 2013

On "Testing and Refactoring Legacy Code"

I finished watching Sandro Mancuso's "Testing and Refactoring Legacy Code" excellent coding kata on InfoQ and I saw there a couple of practices which I can hardly wait to use in real (legacy) projects.

Although that the overall movie quality is not so good, I had no problem understanding the code and the incremental refactorings.

What I liked the most were the practical pieces of advice that are meant to transform developers in real software craftsmen.

On my TODO list:

  • split editor when writing (or reviewing) test code
  • add tests from shortest to deepest branch
  • refactor from deepest to shortest branch
  • use coverage tools when adding tests
  • introduce builders quickly
  • use MockitoJunitRunner 

Sunday, April 21, 2013

Code Review Goals

I did a huge number of code review sessions in the passed years, gathered a lot of experience from my mistakes and I thought now it's a good time to share my findings with the world!

Finding 1:  Code reviews must be taught and learned

It doesn't seem obvious that a simple code review needs to be learned. If you have an intermediate or senior developer in your team, he or she should be capable without too much effort to do a "proper" code review, right? 

Well, from my experience this is not always true! Becoming a good reviewer like becoming a good coder takes time and practice. Although good engineers have a good sense of how a good code should look like, they are not always comfortable with the review process itself, it's underlying goals and benefits, approaches, etc. Same thing applies also for the ones that have their code reviewed.

For one of the projects in my current company I started to teach people how to do reviews by themselves and the results were simply outstanding: from a team of people highly reticent to have their code reviewed, the team arrived at a point where reviews were asked remotely by people working from home being in sick leaves, reviews were ranked as "properly made, with serious benefits, with a lot of discovered bugs" in team's retrospectives.

How did I do it? I invited as a first step in each review an additional developer to assist me, than in time I became the assistant and afterwards I didn't have to participate at all.
After a while everybody knew what they needed to do. I must admit I had my share of good reviews after that moment, a lot of bugs were prevented also in my code by my pear reviewers.

Finding 2: Review goals need to be defined and agreed

When trying to teach people how a good review should be performed, discovered that problems exist in understanding the purpose of various review activities. The easiest way to overcome this problem was to create a shared document that contained the goals of the various code review activities.

The goals and underlying review tasks looked like bellow:

Review Code

Goal: Reviewer must gain understanding on the reviewed part and be able to continue working on it if necessary

Reviewer must know what the code should do.
Reviewer must understand all changed code.

Goal: Reviewer must make sure that the code can be easily maintained

Reviewer should focus on naming and spotting bugs.
Check changes using "show differences" option

Goal: Reviewer must make sure that new changes are well integrated with the existing code.

Have a look over the entire class (maybe some refactoring can be done)

Review Tests

Goal of test review: Tests are more important than the code itself, they are our safety net!

Goal: Reviewer must make sure that tests will avoid bugs

Check that Not Only “Happy path” is covered

Goal: Reviewer must make sure that tests will help preventing "maintenance hell"

Check if integration tests can be replaced by unitary tests

Finding 3: Face to face reviews are priceless

Although there are a lot of tools that can be used for reviews (and used myself for quite a while ReviewBoard), discovered that at least in the early stages of project face to face reviews are priceless! 

When a team is forming, when the team members don't share a common language and the same set of values, the face to face reviews could become a real benefit. 

In these early stages it doesn't even matter if a review session discovers a bug, or not. What's most important here is that the team members have an extra chance to share their visions and set of values!

I know that you can loose some benefits when doing face to face reviews without using any review tool - collaborative reviews are no longer possible, reviewer has not enough time to try thinking out of the box, etc. But nevertheless, I will always opt for "face to face" if I'll have a choice! 

The real benefits

The real code review benefits? The shared language between developers, seeing my team growing, seeing that there is no difference in terms of quality and standards between our code and existing famous open source code, and so on!

Thursday, January 31, 2013

On leading teams

I recently saw a presentation that opened my eyes on some points I probably should have known about long time ago. For me it was a breakthrough, and I apologize I wasn't aware of them sooner.

First of all, regarding the question: "What is my top responsibility as a team lead? What should be the No. 1 in my TODO list?". The simple answer is:

Keep asking myself how my team has improved in the past interval: how my team has improved in becoming a team, how my team has improved in doing things, how my team has improved in becoming a super team, how each member of my team has improved himself/herself, how did I improve myself for my team, how did I improve myself for myself...

If I am not at least thinking about that, I am just a programmer with special attributions!

Secondly, I realized that nothing can improve out there in the comfort zone. If I'm leaving you in your comfort zone, and I stay in mine, we might be more comfortable with each other, but we won't in any way progress in anything.

So If I don't have the guts to challenge somebody or myself out of his/her/mine comfort zone, I am just a programmer with special attributions!

Thirdly, I realized that I can easily become an impediment for my team. Yes mister Scrum master, you can easily become an impediment for your team! If somebody comes to you complaining about the WiFi in the meeting room and you don't ask him "what will you do about it?" but just forward the question, you're on the right track in becoming impediment.

Fourthly, I realized that broken window theory doesn't apply just to failed unit tests but to any practice you would like to have in your team. Skip a code review once, and code review will become optional, skip a retrospective, and all the retrospectives will become optional or nice to have, just break the window and everybody will know it's save whatever they want.

So if you have an hour, enjoy the movie, it contains also other cool stuff: Code Leaders and Beautiful Teams

The guy's site is pretty helpful too:

Sunday, January 27, 2013

Bye Eclipse, Hello Intellij!

I know it's a religious war out there with thousands of followers on each side, that's why I won't just say that Intellij is better than Eclipse or the other way around.

I always tried to replace the tools that slow me down and unfortunately Eclipse started to become such a tool for my current projects where Maven and Git are used intensively. Between me and you, m2e and eGit eclipse plugins still need a little work in order to become really useful.

So, how do you replace your favorite IDE with a different one? What are the steps, does it really pay off?
I can tell you what worked for me, I hope it will be helpful.

Stop using Eclipse if you want Intellij

I tried for a while to use both tools in parallel and it didn't work at all. Each time I had a "problem" I went back to my good old Eclipse to solve it. This way the amount of time spent with the new tool was reduced and no progress seemed to happen. 

I only started to become productive with IntelliJ when I decided to quit using Eclipse!

Start by learning one aspect at a time

How do you enter a new Universe if not one step at a time? 

I first started to read code using IntelliJ - focusing on view elements and shortcuts that helped me to navigate between various classes and code fragments. 

After that I started to write code so I only focused on editing, code completion, refactoring aspects.   

Then I focused on build system, debugging, and so on...

Pair programming

If you have someone out there using IntelliJ, start pairing with him! I learned a lot of things very quickly just by sitting near somebody who knows the tool. It takes minutes to learn a new trick visually and hours to find it by reading documentation!

Use tools

There are tools out there that help you do anything. Even learning IDEs.

I started to use Key promoter and I am very happy with it! It really helps you learn shortcuts you didn't even know exist.

Does it pay off?

In terms of productivity certainly yes, I feel it everyday. It really makes my life on my current projects easier.
I started to use it also for my home Android project - the UI Designer is quite cool!