Over a million developers have joined DZone.

For the Sake of Laziness

DZone's Guide to

For the Sake of Laziness

Don’t let yourself skip testing during development. You have to be too lazy for that! It’s better to spend one extra hour right now rather than days in the future.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

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.

Have you ever had a problem with the name of the class/method/field/etc.? If yes, then you know how hard it may be to come up with a well descriptive and self-explanatory name. You can struggle with such problem. After a while of fruitless thinking, a new idea appears in your head: Maybe I will just leave it as it is. Well, at the end it is only the name, isn’t it?

Don’t go this direction, my fellow developer. If it is so hard to come up with a good name right now, when you are in the context and you understand this mystery code, try to imagine how hard it will be to understand this code without proper names a month from now! You don’t want to read tons of lines. You don’t want to look for the “whys,” “whats,” and “hows.” You don’t want this effort. You should be too lazy for that. It’s better to spend one additional hour right now rather than days in the future.

You are reading code. There are things you can understand pretty fast. However, there are some in a little worse shape and finding out what is going on with them is much harder. You have to understand this functionality because your team will work on the change (or feature or bug fix or whatever) that requires modification in here. So, you are reading. Finally, you know more less what this code is about and what will happen under specific circumstances.

What's your next step? Happy development? If yes, then you should stop for a moment. Maybe it would be good time for quick refactoring.

I know that refactoring requires some time. Can you estimate how much? How much is it in comparison to the time you spend on “real” work? I assure you it is not as much as you can imagine. Why am I so certain about it? Because you already did the hardest job. You understood the code. And what is refactoring about? About increasing descriptiveness of the code!

Use knowledge you already gathered! You know what was hard to understand. You know the places that were problematic. What's more important is that now you understand these parts of the code! Simple renames and private methods extractions would be enough if you don’t have a time for more. Believe me — these renames and extractions will make understanding the code less painful.

If you are still not convinced, just remind yourself how much effort and time you put into understanding this code. Do you want to experience this ever again? You should be too lazy for that!

Developers read far more code than they write. That’s a well-known and pretty obvious truth. Have you ever been in a place where you really could not understand justification for the part of the code? You were going through every business scenario you could imagine and you still didn’t know why this code was written in the first place. After some time, you were almost certain that this code was useless and not needed and you almost decided to remove it, but… maybe there’s a magic place where it’s used through reflection? You are just scared a bit. What if?

You don’t want to be in that place. You don’t want to feel that fear. You don’t want to be forced to imagine every scenario. There’s always a chance that you miss a one or two or even more. It's always about additional effort. Sometimes it's huge. What would make it easier? What would let you forget about the fear? Tests for the code would be useful for that. Well-written tests may be used as pretty good documentation, don’t you think?

Don’t let yourself skip the testing part during development. You have to be too lazy for that!

Do you know other ideas how we can use the laziness to our advantage? If yes, share them and leave a comment!

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

refactoring ,agile ,names ,work life

Published at DZone with permission of Sebastian Malaca, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}