|
In GREP we trust. Use GREP, find in files, or find usages to see all the references to a particular class and it's public methods.
Start the new dev with a small task - a bug fix or minor enhancement. Then have the new dev document every class and method that contributes in some way to the scenario. Have the new dev document every other class and method that depends on the code that is changed, all the way up to the UI or interface.
Also, I absolutely concur with the idea of debugging and examining the stack. If unit tests and integration tests are available then run these in the debugger. If a developer went to the trouble to write unit tests, then it must be important.
|
|
|
|
|
Could I also echo the responses from some of the other repliers that that is a chronic shortage of documenters for most open source products?
They are like rocking horse poop.
If you want to hone your coding skills and can find a project that deeply interests you, then hack away.
If you are just looking to contribute to a project that matters to you, then documenters are always welcomed with open arms.
|
|
|
|
|
I think your first impulse (find and solve an issue) was the right one.
At least you have a "goal" in mind; the rest ("reading code") gets old pretty fast.
Ultimately, you will find out your value is in seeing the big picture quickly, and prioritizing what needs to be done.
A lot of code never gets executed or deals with fringe cases; better to focus on the stuff that actually gets run; i.e. the "buggy" parts.
|
|
|
|
|
Since you're a novice first focus on what you are comfy with.
Pick that layer.
Pick up a tool like Ndepend or Nitriq and see how the layers interact.
Then and only then start playing on the keyboard.
|
|
|
|
|
Here are a few tips.
If nothing else fix layout issues - indentation, spacing etc - and add (sensible) comments where it makes sense. The act of tidying up layout and having to think about what a small section of code is doing, in its own right, will help build your understanding of the bigger picture. From there is probably won't take long for you to start spotting refactoring opportunities.
If you do decide to make changes, start with the small trivial things since these will often be overlooked or tolerated for the sake of the big things. Build up a testing regime for your changes BEFORE you make the changes.
Don't focus on code structure or control too much. That will become obvious. The key to any code base is how it organizes its data and moves it around. This you can analyse and diagram.
Remember, fundamentally all any software is really about is moving data from A to B.
With this in mind, pay special attention to the interfaces between modules, components and systems. This is likely where the most problems are. Especially when either side of the interface has been independently developed.
Also look for places where data is transformed from one form to another e.g. conversions, lookups. Another source for faults.
If you are able to run the software, another way of gaining understanding is to include detailed logging/tracing of the software's operation as it is running. In this context, look to trace the initial state of variables and when variables change, the function calls (including explicit variable values) and function returns and error events in the code. Those three categories of logging should be enough for you to hone in on most problems with the code when it is running. This is ofc verbose and has performance implications so make sure it can be turned off or removed from the release product entirely.
Finally, study design patterns and identify where they have been used in the code. Either intentionally or unwittingly. You may be lucky and the patterns may be explicitly named e.g. WidgetFactory or WangleAdaptor. Design patterns are not the be all and end all, but they are a useful shorthand for common development problems.
|
|
|
|
|
Look Big, but start small.
First get an overview of the what it's fundamentally trying to achieve.
But then,look at a function/class at the bottom that needs a little maintenance and update it.
Maybe only a little refactoring to make it clearer or updating the inline documentation.
Then follow up into the calling classes and see what's happening there.
Like pulling a piece of knitted wool, each tug takes you further into unraveling it until you've touched every part of the main codebase.
And then review/throw away most of your changes. You had no clue what you were doing at the start.
|
|
|
|
|
The two main tips I have are:
1) Use doxygen to generate a hyperlinked, annotated version of the source code you can navigate in your browser.
2) Do code reviews: this gives you an opportunity to ask questions about code that developers who are currently hot in. Only works if you have a functioning code review system in place, of course.
|
|
|
|
|
Garfield[^]
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I've got a drawer like that. I put a pair of socks into it, but only ever get one of them out. I wonder where they all go.
|
|
|
|
|
For me it's a coat pocket!
|
|
|
|
|
You keep your socks in your coat pockets?
Are you residentially challenged? 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: Are you residentially challenged?
No! He is homeless...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
That would explain why he's always "Working" or "InThePub" 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Well the flat I live in at the moment had two optics in the kitchen when I moved in...
|
|
|
|
|
Error insufficient caffine level, apply more ![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif) , no I meant ear buds. Though a few years ago back in my student days I 'lost' many pairs of socks and worryingly awoke in a friends house to find a pair I had 'lost' before in my pocket. I dread to think of the how and why... 
|
|
|
|
|
I love that the so called "tangle proof" guitar cords are the most difficult to untangle. Cord organizers only serve to allow several different types of wire to wrap around each other so that you remove all of them trying to get the one off the rack. I never let two sets of earbuds to be within a few feet of each other lest they conspire to demonstrate a knot that is far superior to any that I learned as a Boy Scout... It's not just wires, electronic tools like oscilloscopes and meters are proof of evolution in so much as they will spontaneously sprout legs and walk away never to be seen again. 
It was broke, so I fixed it.
|
|
|
|
|
S Houghtelin wrote: electronic tools like oscilloscopes and meters are proof of evolution in so much as they will spontaneously sprout legs and walk away never to be seen again.
There are at least two lines of evolution. In Israel, equipment sprouts wings!
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Turn your back on a 'scope it walks, unless it's an old one with a CRT and a funny smell when powered on they do appear to have lost there locomotive powers, snips even blunt ones can run and hide though...
|
|
|
|
|
glennPattonWorking wrote: unless it's an old one with a CRT and a funny smell when powered on
Like any old dinosaur, they go and find a place to die. 
Although my old Tektronix 465 b[^] with the DM44 module is still ticking. But it lurks in the dark cellar staring out of the corner.
It was broke, so I fixed it.
|
|
|
|
|
How earbuds become tangled[^]
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Yesterday, one of the team phoned my office and said something to me that I had been waiting for a long time...well 19 months since I joined, but not that I'm counting.
I headed outside and across the bridge to one of the other platforms, headed up to the helideck and looked out over the water towards to Iran, there was a massive level of activity in the water over a large area, easily at least a few km2.
There were whale sharks lounging around, there where also whales (not sure what species) clearly rising out of the water and shoals of fish manically moving around, jumping etc. Watching and listening to the sounds of the blow, the sun and calmness of the Arabian Gulf and just getting to see nature unfold in front of you.
Just to top it all off, I went down for my lunch just after this and it was nice juicy steak.....nom nom nom.
Overall a good day...
|
|
|
|
|
My work is horrible with bad traffic, bad bosses and tons of junk code.
So I'm glad your work has got decent perks.
Any pictures you could share please?
modified 1-Nov-16 3:47am.
|
|
|
|
|
We are in a high security zone so pictures are a no no. However, see there are some good videos to be had at the following link. These are the official videos from the research project.
The Al Shaheen Oil Field[^]
|
|
|
|
|
|
Yeh, I should have changed the display text.....not very exciting is it! That is just what it defaulted to when the link was pasted.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
