Defensive programming complements patch programming. It is a must for those who want to enjoy life outside of programming and not climb the programmer ladder.
Below I'll unfold a short initiation session, so read on when ready ...
Let's start with the basics, I'll give you your motto: An extra safety net can't hurt. It's the salute that a defensive programmer uses to greet other defensive programmers. At the time of this writing, it is not known that defensive programmers have a special dress code, so you'll need to learn the salute by heart, and as a safety net, keep a paper with some sample code of yours at all times with you. This way you can easily prove your membership to the group and you won't be taken as an undesirable TDD- or refactoring-programmer.
A good practitioner of defensive programming requires that you:
1. Extensively use safety nets like if (obj != null) sometimes right after the object is created, so you'll never be responsible for a NPE again.
2. Add extensive comments explaining why you did what you did in the way you did instead of refactoring the code. This way, if somebody does not understand your code, it's completely their fault.
3. Clone an object both when you set it in its container and when you return the object back from the container; this way you'll be extremely sure that nobody will modify the initial object.
4. When creating a class with similar functionality to an existing one, copy and paste the old class; better yet, even if your class will deprecate / replace the old class, leave it there in case someone takes pleasure in investigating obsolete code.
5. When extending a class, to make sure that an inherited method is called, override it and merely call the super version; who knows what happens with the dynamic dispatch mechanism in the JVM and your method won't be called.
Far from being exhaustive, this list should have given you a good picture of this programming style. As a final advice, take some rhetoric classes: they will teach you how to convince the rest of the team that those bugs in your list ... aren't actually yours.
Thursday, February 26, 2009
Tuesday, February 17, 2009
patch programming
It is again that time of the year when we work like crazy to clear the list of bugs; it is right after we developers did our part of feature regression testing, and right before the product will enter the QA phase, and then product launch.
It is that time of the year when we won't make important changes to the codebase not to break existing functionality. That time of the year when I am answered back with "I suggest you keep that in mind for the next version and just put a workaround instead".
That period when good old refactoring is not practiced much, and instead we code-patch. Some of the patches will be checked in with TODOs, but some of them will lack even this. Because I expect the number of TODOs in the code to increase, I decided I would put a "baseline" on the number of TODOs and compare them with the new number after release. So here it is, 895 TODOs and 31 FIXMEs. I am thinking now at a possible new code quality metric TODOs/codebase size.
If you are the optimistic type, you will have your hopes that after product launch, we will definitely replace the hacks with proper code. And I just have my doubts because everybody will be coding new features in that time of the year.
The result of all this development process can't be other than increasingly dirtier code. But how much can the code become dirtier before "exploding"? And what will this explosion mean? From a technical perspective it can mean writing the same amount of code in more time, or hiring more developers, or less frequent releases, or less features in new product versions. The peak could be a rewrite. All of these have economical consequences that you can easily infer.
I gave all of this some thought and the solution I see is practicing Zero Known Bugs. ZKB means a much shorter period like this one, so less opportunities to introduce hacks. ZKB on anybody's buglist means more confidence that making a change won't break existing functionality, means more focus on activities with added-value like new features. Zero-bugs means a smaller QA team, less fiddling with the bug tracker and less time from managers that weekly count bugs and take time sending encouraging emails that say We can do it together. It also means more free weekends and less stress.
So why not do it? I guess my next step is how I can convince the one who make decisions that this is the way to go.
P.S. After I wrote this, I intended to find a good link about ZKB. You should read it. So yes, it is controversial like most of the software development topics. But be it exactly zero, or 2, the principle is valid and we as a team are far from it, so I still needed to write this piece as one who had never been in a team that practiced ZKB :(
It is that time of the year when we won't make important changes to the codebase not to break existing functionality. That time of the year when I am answered back with "I suggest you keep that in mind for the next version and just put a workaround instead".
That period when good old refactoring is not practiced much, and instead we code-patch. Some of the patches will be checked in with TODOs, but some of them will lack even this. Because I expect the number of TODOs in the code to increase, I decided I would put a "baseline" on the number of TODOs and compare them with the new number after release. So here it is, 895 TODOs and 31 FIXMEs. I am thinking now at a possible new code quality metric TODOs/codebase size.
If you are the optimistic type, you will have your hopes that after product launch, we will definitely replace the hacks with proper code. And I just have my doubts because everybody will be coding new features in that time of the year.
The result of all this development process can't be other than increasingly dirtier code. But how much can the code become dirtier before "exploding"? And what will this explosion mean? From a technical perspective it can mean writing the same amount of code in more time, or hiring more developers, or less frequent releases, or less features in new product versions. The peak could be a rewrite. All of these have economical consequences that you can easily infer.
I gave all of this some thought and the solution I see is practicing Zero Known Bugs. ZKB means a much shorter period like this one, so less opportunities to introduce hacks. ZKB on anybody's buglist means more confidence that making a change won't break existing functionality, means more focus on activities with added-value like new features. Zero-bugs means a smaller QA team, less fiddling with the bug tracker and less time from managers that weekly count bugs and take time sending encouraging emails that say We can do it together. It also means more free weekends and less stress.
So why not do it? I guess my next step is how I can convince the one who make decisions that this is the way to go.
P.S. After I wrote this, I intended to find a good link about ZKB. You should read it. So yes, it is controversial like most of the software development topics. But be it exactly zero, or 2, the principle is valid and we as a team are far from it, so I still needed to write this piece as one who had never been in a team that practiced ZKB :(
Friday, February 6, 2009
boring (III) / unread email count
After the fun I had last time with JavaScript, I felt like coding another micro-project along the same idea: this time I wanted to display the unread emails count in the Reader page.
So I needed that special URL GMail uses to retrieve the count. So I sent myself several emails and all this time I used HttpFox to sniff everything that went in and out my browser; in the end I discovered a JavaScript object that held the information I was after.
Next, I needed to make an async request to the URL I found previously. A very forgiving version of XmlHttpRequest that allows one to make cross-site requests is the one GreaseMonkey provides.
Next, good old string parsing did the job of extracting the unread count from the response I got from GMail, so finally I just needed to append the count to the existing GMail link in Reader.
At this step unfortunately, more testing proved that the URL I've found worked for me only and not for other GMail accounts. I relied on the fact that account specific information would be sent using cookies, and I failed.
So I was back at finding the magic URL. My search went on through cookies, text/html and text/javascript content GMail responded with and I was lucky enough to track down the same js object sent back from another URL, this time a simple one with no scrambled GET parameters. A quick test for 3 GMail accounts on 2 different machines proved it working.
You can install the script from here.
So I needed that special URL GMail uses to retrieve the count. So I sent myself several emails and all this time I used HttpFox to sniff everything that went in and out my browser; in the end I discovered a JavaScript object that held the information I was after.
Next, I needed to make an async request to the URL I found previously. A very forgiving version of XmlHttpRequest that allows one to make cross-site requests is the one GreaseMonkey provides.
Next, good old string parsing did the job of extracting the unread count from the response I got from GMail, so finally I just needed to append the count to the existing GMail link in Reader.
At this step unfortunately, more testing proved that the URL I've found worked for me only and not for other GMail accounts. I relied on the fact that account specific information would be sent using cookies, and I failed.
So I was back at finding the magic URL. My search went on through cookies, text/html and text/javascript content GMail responded with and I was lucky enough to track down the same js object sent back from another URL, this time a simple one with no scrambled GET parameters. A quick test for 3 GMail accounts on 2 different machines proved it working.
You can install the script from here.
Subscribe to:
Posts (Atom)
