re: If you get it (the raise), just start digging in.
Would suggest that this is exactly what poster did do, and
how he came to be
confused and asking for help in here.
DON'T just start digging in. What you need to do is look at
the
functionality from a high level, write down EVERYTHING the
system is doing
in as much detail as possible. Get a spreadsheet going to
help you organise
all this. You'd almost be reverse engineering the business
requirements and
tech spec.
Once you have done this, go looking for the code responsible
for each bit of
functionality. You may need to do this in increments, getting
deeper and
deeper each time as you find "new" bits of functionality you
hadn't realised
existed. Spend a lot of time doing this and getting really
really familiar
with the code/system at a higher level but getting lower and
lower each
pass. Along with updating your spreadsheet with line numbers,
descriptions
etc, you should add comments to your version of the app.
Find some debugging tools and trace tools - anything t all
that can help you
see whats going on.
Must repeat - DON'T just start digging in. This mentality is
likley what led
to such a poorly docuemnted app - developers not wanting to
follow a
methodology or process and instead they just start "digging
in"!!
I wouldn't be asking for a raise either - you can't expect
more money just
becuase a challenge presents itself. If you are a coder, then
its your job
to do it. However, I would consider asking for more resources
if its too
overwhelming - you are just one person after all.
"Brian Simmons" <bsimmons@centrasoft.com> wrote in
message
news:f5mov7$j6m$1@forums.macromedia.com...
> First things first: Ask for a raise. If you don't get
it, figuring out
> the code is easy, let the next guy do it.
> If you get it (the raise), just start digging in. Start
with the
> Application.cfm, default.cfm, etc... and document and
figure out what it's
> doing. Take it in small chunks, so you don't overwhelm
yourself any more
> so than you need to.
>
> Think of it this way: The guy that wrote it, didn't
write it in a day or
> all at once. You won't figure it out in a day or all at
once, it'll be
> slow gradual process.
>
> hth,
> Brian
>
>
> --
> Brian Simmons
> bsimmons@centrasoft.com
> The ultimate ColdFusion MX 7.0 Certification testing
tool:
> Check out CFMX Exam Buster 7.0 at:
http://centrasoft.com
>
> "wolfv" <webforumsuser@macromedia.com> wrote in
message
> news:f5mlsh$fur$1@forums.macromedia.com...
>>I have been tasked to learn the code of a conference
room-scheduling tool.
>> It uses 20,000 lines ColdFusion, JavaScript, and SQL
server 2000. There
>> are
>> no inline comments or any other documentation. The
author is not
>> available.
>> Some of the files are dead code. The software is
Beta, and I have
>> managed to
>> get some of it running.
>>
>> This is my first experience learning an undocumented
program of this
>> size. I
>> tried to manually trace some code but quickly became
lost. I tried
>> reading
>> some files, but can?t figure out what they are
supposed to do. Most of
>> the
>> database tables and attribute names make sense, but
some are cryptic. I
>> am
>> overwhelmed. How do you do it? What is a good
strategy for learning
>> undocumented code?
>>
>>
>> Thank you for your advice.
>>
>>
>
>