The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

A lot of times we get to work on an existing system. We’re lucky if the system is of high quality: easy to read, easy to understand, and easy to maintain. A lot of times, though, we get a system that’s messy: long methods, complex code. Anotherwords, the code smells.

We are asked to make changes to the system. What do we do? We make the change, verify that the system works, and submit the changes. We keep the system in the same state. We don’t want to introduce other changes. We are afraid of taking the risk and moving some of the code out of long methods to a new method. We have deadlines to meet, we don’t mess around. We think copy and paste is not so bad under those conditions. We’re ordinary programmers. That’s not the way good programmers approach it.

Good programmers always, I mean always, try to make the system better after every change. The least they can do is keep the system the same. I like to think of myself as a decent programmer. How do I improve the system? Whenever I’m making a change and I see something that’s not clear to me, I refactor it. I don’t change the functionality; I just try to make the code look better. Why? Because I know when I come to fix something else here, I’ll have the same problem of trying to understand what’s happening. I don’t want to think hard on the same thing twice. I like things simple.

For me, a bad smell in the system is a smell of opportunity. Opportunity to improve the system. This applies to any type of a system in any state. No matter how good or how bad it is. How do good systems decay? Programmers don’t try to improve it. They just do their thing and they’re done. Ordinary programmers do that. Good programmers like to understand the code. They try to make it better every time. You might say, I don’t have time to do that, we have deadlines to meet. I don’t buy that. Not under any condition. Most likely, you don’t know how to make it better. You don’t know how to program well. You know how to hack.

Part of being a good programmer is keeping the codebase clean. To know that you’re programming for other people, not for computers. That’s why when you see a long method, duplicated code, or unclear piece of code, refactor it. How do you do that? Read Refactoring by Fowler and he’ll show you how. Keep your code DRY (Don’t Repeat Yourself); keep it SHY (don’t reveal too much — data hiding, encapsulation); and TELL the other guy (to do the work for you — ie, no getter methods). Or as Thomas and Hunt say: Keep it DRY, Shy, and Tell the Other Guy (great article — May 2004, IEEE Software).

The degrading of the system starts with a single broken window that’s not fixed. Don’t let that happen, always fix any code smell that you see. Be a good programmer, not ordinary one. Also, if you’re serious about improving, check out The Pragmatic Programmer and Code Complete 2, they’ll help you. They helped me.