|
Inheriting someone elses Code
I am about to assume new resposibility whereby I will take over an application developed by a programmer.
This is his baby - he is moving on to other things within the company.
I have enough problems looking at my own code after time has elapsed - what would be the best way to approach knowing the new application?
The application is an authentication system developed for unified login in our company. We are a large multi-national with many divisions that were acquired during the go-go years of the mid-niineties.
Hence there will probably be a number of divisional LDAPs to integrate to. There are plans in the works to migrate all accounts to a central database (with the properback-up) - and access any where in the company has to come through this application.
Ram Dass
Wednesday, October 1, 2003
Spend as much time as you can with the original coder, preferably in a room with a white board. Ask about the architecture overview, tricky portions, bugs, upcoming deliverables, etc.
Julian
Wednesday, October 1, 2003
Embrace the not-invented-here syndrome. Accept that his code is not as good as yours and rewrite from scratch.
In-A-Flippant-Mood
Wednesday, October 1, 2003
Build a full suite of black-box tests for it, then tinker with the code until you understand it.
As long as it keeps passing the black-box tests you know you haven't broken it.
Matthew Lock
Wednesday, October 1, 2003
Watch the performance. Centralizing something so critical may become a real bottleneck.
For understanding large source trees, I use these:
1. ctags - Hit on any symbol in your source tree & it'll tell you where it's defined. Nice & quick
2. cscope - Builds a database of where every symbol's defined and lets you know who called it. Amongst other things
3. A fast laser printer - Print out the important headers. I use two pages per physical page with line numbers. Read through them and highlight the important stuff. Use a notepad to keep a diary of what you're figuring out. Write down the questions you have, too.
When you're done with the headers, look for the source files that do most of the architectural work. Print, read, highlight, and document.
It's much easier to come to the original architect with a good foundation of what the code looks like. Otherwise, he's going to use a lot of terminology specific to the project, which you're not going to know. With more research behind your questions, you're going to ask better questions which tell you more about what's going on. And definitely, definitely, read the questions off the notepad and write his answers down.
The more you work ahead of time on the codebase, and the more you appear to value his time, the more flattered he's going to be. If your attitude is of an apprentice talking to the master, he's going to more easiliy fall into the teaching role. He'll be more receptive to your questions and give higher priority to answering them.
H. Lally Singh
Wednesday, October 1, 2003
This is something that bothers me.
As Outsourcing continues most "In House" Programmers will be experiencing this sort of challenge.
In the company I work for, all new projects are being coded off shore (India) - then the code is being shipped here for us American programmers to maintain, customize & enhance.
It's challenging because 9 times out of 10 we could have designed & written the code way better. We basically get crap and have to live with it!!!! (Managers don't have a clue, donn't understand, can't do anything about it or simply don't care)
It's depressing, I once thought I earned a BS in Computer Science to design & build great software - now it seems like our fate is that of a maintenance "grunt" programmer...
GenX'er
Wednesday, October 1, 2003
[Build a full suite of black-box tests for it, then tinker with the code until you understand it.
As long as it keeps passing the black-box tests you know you haven't broken it. ]
This is good advice, but I'd temper it. Write tests for the code that you change, before you change it. Write tests for defects before you fix them. Leave the code that's not bothering you alone.
You write tests for code you expect to break. Writing a test that never breaks is, by definition, a waste of your time.
anon
Wednesday, October 1, 2003
>>now it seems like our fate is that of a maintenance "grunt" programmer...
Face it, 90+% of programming is maintenance/grunt programming. If you only want to work on cutting-edge new development, you are going to be very unhappy.
I actually interviewed a programmer once who had 1-2 years of experience and he said in the interview "I only like working on new development, I don;t like maintance programming." Saved me a lot of time in the interview, I ended it there.
RocketJeff
Wednesday, October 1, 2003
"Build a full suite of black-box tests for it, then tinker with the code until you understand it.
As long as it keeps passing the black-box tests you know you haven't broken it. "
This advice only works if you know exactly what the code is supposed to do. If you write a test based on a false assumption about how the code should perform, you could be breaking something without failing the test.
Things I'd do: Step through the code in a debugger. Add comments of the type "what's going on here" where it isn't obvious. Rename variables, classes and methods when their names don't match what they do. If the original programmer is still around, ask, but only after trying to find the answers in the code!
Big B
Wednesday, October 1, 2003
I agree that you should write tests, but get a very strong understanding of what the code should do before you write the tests.
I disagree that "Writing a test that never breaks is, by definition, a waste of your time." A test that never breaks is a test that's *succeeding*, that's telling you that a piece of code is *not* failing. If I have two dozen tests and three break, it's at least as instructive to know which code *isn't* breaking as knowing which code does break.
Good luck, though. This is a tough job.
The Pedant, Brent P. Newhall
Wednesday, October 1, 2003
"Face it, 90+% of programming is maintenance/grunt programming. If you only want to work on cutting-edge new development, you are going to be very unhappy."
I have been in the industry for 7 years now, and I have worked on new projects & maintenance projects.
It's not that I don't want to work on Maintenance projects at all - it's that I don't want to ALWAYS HAVE TO work on maintenance projects.
Example:
We have a VB Classic App which we have been maintaining for 7+ years which grew into a monster. The company wants to re-write it in 3 Tier Web Services Front End, Java Middle Tier & DB.
Instead of having us do it - the initial effort is probably going to be outsourced. Then we will get it back for maintenance. I don't mind maintaining it, but I'd rather build it first then maintain it.
That's my point....
GenX'er
Wednesday, October 1, 2003
To add to the "black box testing" suggestion...
If you're faced with one of those offshored code maintenance problems, something management should have thought of is incorporating black box testing into the code acceptance criteria.
You spec the modules and ship it to the low-rent coders, with test cases. When it comes back to you, you run the test cases to verify performance and spec compliance.
Keep failure stats and rejection stats. Use that to objectivly evaluate the quality and "savings" of the offshoring efforts.
If you want to influence management you have to speak their language. They've been sold a bill of goods that off shoring will save them money. Let's see if it holds water.
Tom Dratler
Wednesday, October 1, 2003
I find the best way is to find an 'annex' you build onto it. Some area of new functionality that doesn't require you to deleve too deeply into their code. This allows you to make it yours, understand a bit of the code at a time, show the bean-counters you're making progress.
Mr Jack
Wednesday, October 1, 2003
I'm reminded of one thing that Joel said in one of the articles that I hadn't thought of but rang true; and that's that the code is much more information dense than prose and that you have to adjust your reading speed accordingly.
Joel pointed out that sometimes programmers complaints about other people's code is just arising because they're trying to read the code at book reading speed. Book reading speed is sometimes possible when reading your own code (because you know the background/context very well). But when you're reading other people's code you need to conciously slow down your reading speed a lot.
Bill Tomlinson
Wednesday, October 1, 2003
Excellent point, Bill.
The Pedant, Brent P. Newhall
Wednesday, October 1, 2003
 Recent Topics
Fog Creek Home
| 
