New Job:How to tackle???

[l3d007]

I just started a new job, this is actually my first job out of college. The old programmer left the company abruptly and there was no transition between him and myself. I pretty much have a code base and naming conventions to try and piece this application together because he did not comment his code. There are no database diagrams to view relations in the db. How do you guys usually attack trying to make modifications to code your unfamiliar with?

[pbmods]

Heya, l3d007. Welcome to TSDN!

First off, visit Worse Than Failure every day so that you don't feel so bad.

Second, get it working. I'm working on an (abhorrent) PHP/MySQL app right now, and it's pretty much the same situation: barely functional, no comments, no consistent coding style. But by running it, fixing errors, running it again, and so on, I'm starting to get a pretty good feel for what everything does.

Third, write your own comments for the other guy's code. Even if you're not sure what it does, jot down your guesses and/or findings. Leave yourself lots of notes so that at least you know what YOU were thinking!

[EDIT: Fourth, don't make it personal. Some of that code will more likely than not have you wanting to pull your hair out. But whatever you do, don't flame the other guy in your comments. Management doesn't like that so much.]

[l3d007]

thanks for the response...i was thinking about leaving comments in the code myself thats a good idea

[RedSon]

When I am faced with an unmanageable code base, in any language, I have this program that I use called Source Insight. Its a 3rd party IDE but it will scan your code and create a crossreference database so you can worm your way through the code. I also creates logic flow and caller/callee graphs. I suggest you check it out. Its a free trial for 30 days but it might give you the insight to the source that you need.

[Dököll]

Keep copies of the original, then beat it to death. Keep copies of your modified versions.

And yes do not make the same mistakes one made, comment for the next person. Good luck!

[r035198x]

When I get code like that, I simply ask what the code was supposed to do then I rewrite it from scratch.

[gits]

When I get code like that, I simply ask what the code was supposed to do then I rewrite it from scratch.

... thats probably the best way to build new maintainable code out of a bunch of 'prototype-like' code (we always learn that from the old rapid-prototyping development paradigm) ... but it is not always a straight way for that ... imagine an app that is productive already (i know that an productive app is not (almost should not be) a prototype ;) but thats theory only ... most of you know that ... i know! ;) ) ... so you have to maintain the productive app and besides that, you refactor or rewrite it at the same time - in a way of creating an new application ... i always use to do it that way ... therefore you probably need a feature-freeze ... until your rebuilt app is ready to replace the old one ... and: it is always a good hint by pbmods not to flame the old developer ... or to flame the old code either ... try to 'sell' this only by the advantages you would get out of refactored code ... maintainance, robustness and performance are always points that are to be considered ...

kind regards ...

[praveen2gupta]

I just started a new job, this is actually my first job out of college. The old programmer left the company abruptly and there was no transition between him and myself. I pretty much have a code base and naming conventions to try and piece this application together because he did not comment his code. There are no database diagrams to view relations in the db. How do you guys usually attack trying to make modifications to code your unfamiliar with?

Hi

This is common problem in small companies. Remember

1. Don't over commit to management for overnight updations. Tell them the basic project management or software project management problem is there.

2. Make a personal diary, write flow diagrams there.

3. it's not easy to understand others logic and source code. What ever you will understand at first instance will not be correct.

4. Be careful to update the code. One wrong update will create many new problems.

5. Learn Faster This is an Opportunity.

[LacrosseB0ss]

When I get code like that, I simply ask what the code was supposed to do then I rewrite it from scratch.

sometimes management doesn't like this either. The best way to do it I've found is:
Ask your supervisor what it's supposed to do. Document what you think it's supposed to do through diagrams (flow charts, use cases, whatever you need to feel for it). Show your supervisor again and make changes as he/she advises.
Slap a code break at the beginning and step through everything. It's going to take a while, but it'll help. As you go make notes.
While studying the code, make your own comments. This will help not only you but others to follow.
If, after stepping through the code, your results don't match the original flow charts, ask for permission to re-write everything (if required). Again, some companies don't like this approach for whatever reason. But if you can prove the existing code is crap, you could win your right.

I don't mean to keep beating a dead horse but comments are your best friend. You will benefit from them when it comes time to debug or after vacation or whatever. But also the corporation will benefit from the comments later on. Most times my initial plan of attack when approached to write a module or whatever is to create a comment "to do" list. Say 1. define variables 2. initialize 3. while loop to do xyz 4. return abc. This will keep you on track, remind you what needs to be done AND you'll have comments in your code at the end!

I may have gone a bit off course there, sorry. Hope it works out!
- LB

[Dököll]

Job search is back on, now my boss is trying to kick me out...means well, wants me to explore my horizon whatever that means:-)

Anyway, just wanted to let you know I will aain try everything you've proposed...Thanks!