In my experience, I've come across engineers of different calibre. Some who are natural engineers (developers or QA) and others who could do with a bit of help to get to the point of being great engineers. Being a developer I've always been on the look out for ways to improve the code that is produced. The other day I came across this
presentation and it helped me to organise my thoughts on the subject. I've summarised the presentation here and added my opinions to too
Composed methods
Each method does one task. This makes it granular and easy to read and understand.
Within a method all operations are at the same level, functionally.
Smaller methods also are documented by the method name. In fact, working backwards will help you to identify methods that need to be refactored. After implementing the method, change the name to reflect what the method does. Instinctively, you'll identify that the method name is too long or it does not summarise the operation correctly. This means the method needs to be refactored!
Test Driven Development
Every engineer I've spoken to has heard this term and most aren't aware what it means and how to do it. The most common question I've heard is: "
What's the use of unit-testing?". I'm not going to get into
that discussion here, but will summarise the benefits.
- Think like a user. The code/implementation being delivered needs to be used.
- Aids in created composed methods, because smaller atomic methods are easier to test
- Improves reliability by providing an automated regression suite
Static Analysis
FindBugs and
Checkstyle, are two tools that help in reducing common bad practices, bugs and code complexity.
Good citizenship
In other words, ensure all references have the right scope. This includes:
- Scope identifiers, viz., private, default, protected, public. My recommendation is make everything private and increase scope as and when required
- variable scope, viz., block, method, field, static. My recommendation again is to declare a variable as close as possible to it's point of usage and take it higher up only if required. Another recommendation is to rather pass values around using method parameters rather than increase a variable's scope.
With these two it implies that one should avoid using
static references. This can further be extrapolated to avoiding
SINGLETONS. Singletons combine responsibilities, making objects global and difficult (if not impossible) to test. Instead create a POJO to hold the data and a factory to create a
single instance. This not only separates out responsibility and concerns but also make it easier to test.
KISS
Keep It Stupidly Simple! That also means, choose the simplest implementation for the current requirement. Don't go about indulging in
speculative development. A lot of the times, simple things are cheap to throw away. If it gets complex you probably need a framework and should look at reusing existing ones rather than building a new one. Simple code is refactor-able and easy to change hence resulting in more agile and adaptable implementations.
Refactoring is not rework
Many times I've heard the complain:
"We had to change
<insert your code here> and we wasted time in refactoring.
If only we had done a little up front design we would have done it right the first time!"
But this is not true. You saved time the first time you did it without having to worry about complexity. Secondly, if you followed the principal correctly, you would have implemented something simple and hence cheap to throw away. And Thirdly, who ever got it right the first time!
If you are a Linux fan, even today there are new releases of Linux and if you are a Windows fan, Windows is at version 7.x No one got it right the first time, not even Einstein. So why do you expect yourself to be perfect. You
will have to change whatever you do. If you come to terms with that, then why not be simple. Don't get attached to the code. And refactor. It's part of software engineering. It's part of implementation cost. It
cannot be reduced! And hence it is not waste but part of the process.
This kind of thinking is usually triggered by managers asking: "How can we improve the process and reduce waste". Managers
have to ask this. They control the budget and who doesn't want the best value for money? But we as engineers have to stop viewing refactoring as waste and something to be reduced. It is part of the software engineering process!
Ask Question
As simple as this sounds a lot of the time, questions aren't asked especially to authorities. This means you question suggestions, opinions, decisions, implementations, traditions, etc., etc. Questions will either lead to a change, hopefully for the better or will reaffirm that you've got the right implementation. So what's the harm in asking them? In today's world questions are no longer an indication that you don't know something. Quite the contrary, it's an indication whether you are paying attention and an indication of how much you've understood. I've always been of the opinion that '
There are no stupid questions, only stupid answers'. The only exception is when, you've not done your homework
before asking the question or weren't paying attention. In which case, apologise for your
bad behaviour' but still ask the question!
