|
| Subject |
Author |
Status |
Date |
 Re: How do you usually attack trying to make modif
ications to code?
|
Suguna Karyodi |
|
2/22/2008 2:54:48 AM |
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, d
on'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.]
Post Comments |
|
Re: Thanks for the response... |
Jessica Tandatti |
|
2/22/2008 2:56:15 AM |
Suguna, Thanks for the response... i was thinking about leaving comments in the code
myself thats a good idea
Post Comments |
|
Re: How do you usually attack trying to make modif
ications to code? |
Jeiron Deivtan |
|
2/22/2008 2:57:52 AM |
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.
Post Comments |
|
Re: How do you usually attack trying to make modif
ications to code? |
Rudra Kandedat |
|
2/22/2008 3:01:37 AM |
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!
Post Comments |
|
Re: How do you usually attack trying to make modif
ications to code? |
Boroto Meida |
|
2/22/2008 3:02:55 AM |
When I get code like that, I simply ask what the c
ode was supposed to do then I rewrite it from scr
atch.
Post Comments |
|
Re: The best way to build new maintainable code |
Peechccaro Teindano |
|
2/22/2008 3:04:37 AM |
... 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 ...
Post Comments |
|
Re: ometimes management doesn't like this either |
Oottay Keisa |
|
2/22/2008 3:09:00 AM |
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!
Post Comments |
|
Re: How do you usually attack trying to make modif
ications to code? |
Nazarina Habeeb |
|
2/22/2008 3:07:06 AM |
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.
Post Comments |
|
Re: How do you usually attack trying to make modif
ications to code? |
Rudra Kandedat |
|
2/22/2008 3:11:15 AM |
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!
Post Comments |
|
