|
If you are lucky to work at a company that has decent documentation practices, read the project documents. To get an overall idea of what a project is about read the specification document. Then read the code description, if there is one. Also, try to follow the flow charts. These are standard documents in medical device design and manufacturing.
If you are into database or web design, good luck! 
It was broke, so I fixed it.
|
|
|
|
|
S Houghtelin wrote: read the project documents
...while keeping in mind that the actual product probably deviates substantially from the original documentation.
|
|
|
|
|
dandy72 wrote: ..while keeping in mind that the actual product probably deviates substantially from the original documentation.
Hence the "If you are lucky to work at a company that has decent documentation practices."
It was broke, so I fixed it.
|
|
|
|
|
I think it takes more than "decent documentation practices" just to ensure documentation is kept up to date, unfortunately.
|
|
|
|
|
I've been at this for 40 years and have yet to find a company that had more than completely minimal documentation at a level that could help a developer. It has always been a learn-as-you-go process. Most developers do NOT document their work.
|
|
|
|
|
In the medical device industry if we do not have documentation, you will not be able to sell your device. It is a requirement and for good reason. Would you want to be on the operating table being monitored by devices with software of unknown provenance?
"Most developers do NOT document their work." and we wonder why the quality of the software out there sucks. That's called winging it and in my opinion it is unprofessional and if a developer is unable or unwilling to maintain at least some level of documentation I would not be inclined to hire them or to keep them in my employ.
It was broke, so I fixed it.
|
|
|
|
|
That's certainly good to know. I wasn't talking about end-user documentation, though, I was talking about the documentation that would help a developer. I wonder if the code behind those medical devices is documented any better than what I've seen in a dozen or so other industries?
|
|
|
|
|
We have to comply with GMP, UL, ISO, FDA, CE and EU standards among others. We are required to have our documentation internally and externally reviewed and accepted by the regulatory bodies. Every aspect of the product needs to go through risk and hazard analysis and QA tested using the very documents the software developer wrote. If the software and document do not match, it needs to be corrected and retested. This doesn't mean bugs can't get through, but certainly the obvious glaring stuff rarely does.
This is why it takes forever and a massive amount of $₤€ to get a new product out.
End user documentation is also very regulated, but thankfully I don't have to deal with that aspect.
It was broke, so I fixed it.
|
|
|
|
|
Good to hear, and also makes a lot of sense. Most of the organizations I worked with were not producing software that could wind up being "life critical" like that. Glad to hear that someone does it.
|
|
|
|
|
S Houghtelin wrote: In the medical device industry if we do not have documentation, you will not be able to sell your device
S Houghtelin wrote: "Most developers do NOT document their work." and we wonder why the quality of the software out there sucks
The only way comparing the software industry with the medical device industry could be fair is if software was priced to match said medical devices.
Don't blame developers for not documenting their code. That decision is not made by them.
|
|
|
|
|
Sadly this is very true. When there is a clock ticking down the profit margins, documentation is usually the first casualty.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
The sad part in all the comments on this topic is that not one suggested writing some documentation for the project. Documentation is always someone else's responsibility.
Two years ago I was handed 100KLOC of undocumented but production critical cowboy code. Programmer who wrote it was adamant that "the code is self documenting". It wasn't. It took 18 months to document it to the point where it could be maintained...barely. If you REALLY want to contribute to a project, write something other than code.
"Everyone complains about the weather, but no one does anything about it."
|
|
|
|
|
Documentation can be self documenting as well. The amount of times I despair when I see a summary of a method which basically repeats the method name.
Code should be simple and self explanatory as to the implementation. If it isn't then it probably needs to be refactored. A method can explain its function in its name, no need to repeat it (as an example I saw the documentation to an attribute "rtpHeaderExpected" as "expects an rtp header").
Documentation is useful when it explains the why of code, not the what (which is what the code should explain). So yes to documentation, but only when its useful !
|
|
|
|
|
|
It's admirable wanting to get involved and commit to an open source project, but my suggestion would be only get involved in a project if it's something you use/reference as part of some other development project you are working on, and there are improvements or fixes that would benefit your own project that you believe would also be of benefit to others.
|
|
|
|
|
Wastedtalent wrote: only get involved in a project if ...
I disagree. There is great value in studying large, commercial-grade software for its own sake. Even if the OP never commits but just spends hours or days spelunking one of the codebases he mentions, he is bound to be enriched by the process. Many of the techniques of enterprise-scale coding can't be taught in books.
|
|
|
|
|
I agree, I also think studying and getting involved in are two very different things, and the OP was talking about making commits.
|
|
|
|
|
I also suggest that getting involved in that depth with a project that you use regularly will increase your interest and commitment to the process.
Doing work on a project that you have little interest in, just for the sake of it, will soon feel like a thankless task.
I've only ever contributed to projects that I have a direct interest in, because the first step in contributing to any product is using it.
|
|
|
|
|
Do you know WHAT you want to contribute?
If you're just thinking about making some contribution or another you're going to have a difficult time, but if you have something specific in mind try to find just that place where it should be implemented.
For example, let's say your contribution is going to be that NodeJS always logs to the console when starting a server.
Now you want to find where it is that Node finds your file and runs it.
Since it's a command tool try looking for that point of entry, perhaps by searching for some optional parameters.
From there find where Node is loading your file, you can do this by following the code in your editor or debugger (I tend to use the debugger as I want to know for sure the code actually runs).
You should now be close to where you want to insert your code.
When working like that you can make contributions, add to the code, fix bugs, etc. without having to know everything that's going on.
I've never actually looked at the NodeJS code, let alone contribute to it, but that's what I would do.
P.S. Just for the record, my suggested contribution isn't exactly one we'd want (as we can optionally add it with a single line of code). It's just an example.
|
|
|
|
|
Go small at first.
Follow the code paths from UI to the finish line for that particular path. I cannot stress this technique enough. Pick a path that is relevant to your current task or project.
Don't try to learn the entire system at one time.
|
|
|
|
|
If a debugger is available, use it to see the call stack, for the functionality you're currently working on. This will give you an idea of the control flow for that functionality.
Once the first functionality is reasonably well understood, go to the next functionality, and so on.
|
|
|
|
|
Try reaching out to the dev community, and see if they can suggest easy items for a newcomer to the codebase. I know Mozilla has a list of them, but doubt they're the only project to do so.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
TheOnlyRealTodd wrote: when I open the project file for these, it can be tough trying to figure out where to even start.
Getting them to compile is the hardest step! 
TheOnlyRealTodd wrote: and also looking at the unit tests to get an idea of whats happening
That's a good approach, especially single stepping through the tests.
And write down everything you learn, and your questions for what you don't understand yet.
Personally, I think most of these open source sites could benefit greatly from writing some "programmer documentation", as you're not the only one with "how the elephant does this stuff work?" question. And that might be the most useful contribution at first!
Marc
|
|
|
|
|
Play with it without looking at the code, first -- get the grand view, and get to know the whys and wherefores.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
To analyse a large code base you could try running a dependency tool such as DeepEnds
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
