Slashdot Mirror
The P.G. Wodehouse Method of Refactoring
covertbadger notes a developer's blog entry on a novel way of judging progress in refactoring code. "Software quality tools can never completely replace the gut instinct of a developer — you might have massive test coverage, but that won't help with subjective measures such as code smells. With Wodehouse-style refactoring, we can now easily keep track of which code we are happy with, and which code we remain deeply suspicious of."
I totally agree. Even if you are a developer for a large, corporate, multi-vendor project - knowing how components that feed components you directly interface with will allow you to become a better developer for the project and to point out problematic architectural design issues.
And if I hear one more project manager say, "Let's not worry about this corner case" (usually said with no idea how this is going to negatively effect the entire process tree) I'm going to punch them in the colon.
There are two ideas of thought about corner cases (and the GP pointed out one).
Thought #1) (GP) There's no such things as a corner. It is a requirement - it may be that fewer people/fewer processes use it; but, it is still a section of the total solution that must be designed to overcome some problematic section. Otherwise, why is the code being written?
Thought #2) Corner cases only effect a small number of your user-base; therefore, code to satisfy 95%-99% of your customers. The underlying principle here is that the manager will wait for another release. This approach is usually taken when the project manager failed to account for something and says (and I quote), "We'll just re-design it after the first release."
If you find yourself in an environment where #2 (hehe) permeates the thought structure of management you have few options available to you.
a) Kindly (because wrapping your hands firmly around their neck is just not understood these days) explain to them the flaw in that kind of thinking. It usually involves educating the manager to a level they've never even considered before. Completion of this project will be long and arduous. Good luck to you.
b) If step 'a' fails - inform management. Project Managers (in large corps) are not, usually, the final decision maker. Elevate this threat (to the project) to the PM's manager - a Director, perhaps.
c) If you're able, move to a new project within the company where the project manager in case 'a' has no influence. I know that's not feasible in most segments.
d) Find a new job.
If the project is sufficiently high profile enough then recourse option 'a', above, is your only solution. Mitigate the damage by engaging the offending PM and try to keep them under thumb by sharing your expertise with them. Good luck with that brick wall. YMMV.
Doxygen is my favorite tool for C/C++/Java programming. It also handles some other random languages as well. Its main purpose is to create documentation (think javadoc but Open Source, handles more than just java, and better results). Here's an example of what it can do.
Anyways, related to your post, doxygen can map out the call graph from functions and dependency/include graphs of files. It may be helpful in understanding the structure.
Lack of planning on your part does not constitute an emergency on mine.
While the Mozilla story did have a happy ending, the rewrite resulted in IE getting a near monopoly of the browser market. The "new" Netscape was massively delayed, and was finally released as a rebranded version of the bloated Mozilla suite. It was in the period between about 1999 and 2004 that IE expanded it's market share. In other words, Netscape lost as a result of throwing away the old code base.
It was only from around 2004 onwards, with Firefox, was Mozilla able to present a viable alternative to IE.
I know French "jokes" may be acceptable in the U.S. ...
only for a small conservative subset of the U.S., which as we know have proven themselves to be a joke.
rd