Archive for the ‘Martin Fowler’ Category
A perfectly valid conclusion.
But going back to Enrico Zaninotto’s statement the part where it says “reducing irreversibility” is completely true. But I find it difficult to to accept “contain complexity” part of the sentence. Does trying to “reduce irreversibility” actually reduce complexity of the system? My answer would be an emphatic NO. It actually would increase the complexity of the system.
Refactoring
Posted on: October 18, 2010
- In: Java | Martin Fowler | Refactoring | Techniques
- Leave a Comment
Writing under constrained circumstances means that one needs to go back and correct the code that has been written and here is where refactoring comes into picture.
Many a programmers may have been doing it without realizing that they are refactoring (as the term has started existing only after Martin Fowler has made it a formal declaration).
The book “Refactoring – Improving the design of existing code” gives a set of wonderful techniques that can be applied to make code more readable, more efficient, more maintainable and more beautiful.
For every technique that it suggests it also suggests the reverse as another refactoring method and also illustrates as to when it should be used.
Extremely important book for every programmer. Although the examples in the book are based in Java they can be applied to programs in any Object Oriented Language.
Along the same lines there is a book on Refactoring Databases. Again a wonderful book.
And another book called Refactoring to patterns. Although the name of the book reads refactoring to patterns, it clearly warns against overuse of patterns and gives examples as to why force fitting patterns will cause the programs to become ugly and unmaintainable.
All three wonderful books and should be in the repository in anybody who wishes to write BEAUTIFUL CODE and BEAUTIFUL APPLICATIONS.
- In: IT | Knowledge | Martin Fowler | Quote | Software | Technology
- Leave a Comment
“Any fool can write code that a computer can understand. Good Programmers write code that humans can understand”
Wonderful statement. I wish this is made part of our academics (in India specifically) and this fact should be drilled into the heads ot students who are expected to write programs in their careers.
“Computer Science is a discipline that believes all problems can be solved with one more layer of indirection”. This statement was made by Dennis De Bruier.
The problem with flexible solutions is that flexibility costs. Flexible solutions are more complex than simple ones. The resulting software is more difficult to maintain in general, although it is easier to flex in the direction I had in mind. Even there, however you have to understand how to flex the system.
How right and and one hopes that one’s clients understand this fact.
In the book the authors talk about presence of bad code to bad smells and give details of how to identify bad code equating to bad smell. One statement that they make stands out. “Watch out for comments”. It is not that the authors are against comments, it is just that presence of comments indicates a high possibility of bad code. This is what the authors have to say about comments in code.
“We are not saying that people should not write comments. In our olfactory analogy , comments are not bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant. Its surprising how often when you look at a thickly commented code and notice that comments are there because the code is bad.
Comments lead us to bad code that has all the rotten whiffs we’ve discovered. If we refactor the comments will most likely become redundant.
If you need a comment to explain what a block of code does, try Extract Method. If the method is already extracted and you still need a comment to explain what it does, use Rename Method. If you need to state some rules about the require state of the system use Introduce Assertion.
A good time to use Comment is when you do not know what to do. In addition to describing what is going on, comments can indicate areas in which you are not sure. A comment is good place to say why you did something. This kind of information helps future modifiers, especially the forgetful ones.”
Absolutely brilliant summary about comments.
Read the book
Sundarrajk's Weblog 