[b. 1963] American-resident British software developer, author and international public speaker on software development
Scroll down
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, don Roberts
ISBN: 0201485672 This book is available from Amazon
People also underestimate the time they spend debugging. They underestimate how much time they can spend chasing a long bug. With testing, I know straight away when I added a bug. That lets me fix the bug immediately, before it can crawl off and hide. There are few things more frustrating or time wasting than debugging. Wouldn't it be a hell of a lot quicker if we just didn't create the bugs in the first place?
Refactoring improves the design. What is the business case of good design? To me, it's that you can make changes to the software more easily in the future. Refactoring is about saying, "Let's restructure this system in order to make it easier to change it." The corollary is that it's pointless to refactor a system you will never change, because you'll never get a payback. But if you will be changing the system‹either to fix bugs or add features‹keeping the system well factored or making it better factored will give you a payback as you make those changes.
Why is composing symphonies tough? I don't know. It's just very few people in the world can do it well. And I think that's the case with upfront design. It is very hard to do well.
I wrote that about aesthetics in discussing when you apply refactorings. To some extent, the situations I describe in the refactoring guidelines are fairly vague notions of aesthetics. But I try to provide more guidance than just saying, "Refactor when the code looks ugly." I say, for instance, that duplicated code is a bad smell. I say that long methods are a bad smell. Big classes are a bad smell.
...if you're afraid to change something it is clearly poorly designed.
One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is avoid duplication. "Once and only once" is the Extreme Programming phrase.
..You can almost do this as an exercise. Look at some program and see if there's some duplication. Then, without really thinking about what it is you're trying to achieve, just pigheadedly try to remove that duplication. Time and time again, I've found that by simply removing duplication I accidentally stumble onto a really nice elegant pattern. It's quite remarkable how often that is the case. I often find that a nice design can come from just being really anal about getting rid of duplicated code.
I think another good principle is separating presentation or user interface (UI) from the real essence of what your app is about. By following that principle I have gotten lucky with changes time and time again. So I think that's a good principle to follow.
Another design principle that's struck me very firmly, particularly recently, is making things explicit. Make the code very explicitly say things...A dictionary is not explicit. A class, even though you have to do all the work writing in the member variables and accessors, is explicit. You can just look at that source code and know what data is present.
When you actually sit down to write some code, you learn things that you didn’t get from thinking about them in modeling terms…there is a feedback process there that you can only really get at from executing some things and seeing what works
Refactoring changes the program in small steps. If you make a mistake, it is easy to find the bug.
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.
from Is Design Dead?
I can’t choose whether someone is offended by my actions. I can choose whether I care.
Not all eyes that notice bugs in Open Source code belong to saints who will report or repair them in the interest of the public good.
Code smells.