How do you deal with a large project?
So I started working on an open source project for my resume/portfolio, its a really great project that needs alot of work and there is only 2-3 people working on it.
Now, let me be clear, its not actually a "large" project, its maybe 50-60 files, 6-7 libraries, maybe 60k lines of code. My teacher would tell stories of millions of lines of code.
anyway, i'm feeling a little overwhelmed, and everything is very well organized but the logic is often spread across many files, and I'm catching myself trying to read it all instead of focusing on the few things i want to work on.
Should i try to read and understand the entire thing first? how do you go about doing that? is it better to just stay focused on something small; what happens when that something small is spread out and could potentially be a conflict with something else?
Now, let me be clear, its not actually a "large" project, its maybe 50-60 files, 6-7 libraries, maybe 60k lines of code. My teacher would tell stories of millions of lines of code.
anyway, i'm feeling a little overwhelmed, and everything is very well organized but the logic is often spread across many files, and I'm catching myself trying to read it all instead of focusing on the few things i want to work on.
Should i try to read and understand the entire thing first? how do you go about doing that? is it better to just stay focused on something small; what happens when that something small is spread out and could potentially be a conflict with something else?
Trying to understand the whole project might take very long time so I don't think that it is a good approach it might have changed considerably by then.
I would recommend to speak with the programmers, they probably know best how newcomers should start. What project is it ? Can you post the link?
I would recommend to speak with the programmers, they probably know best how newcomers should start. What project is it ? Can you post the link?
closed account (48T7M4Gy)
Start with the project description. Just write a couple of lines on what the software is supposed to do. What does the customer want to be able to do? eg This is a customer sales and invoicing system. Or, this is a navigational system for a rocket. Without this aspect don't expect to achieve much. But it doesnt have to be complicated.
From that you need to use various conventional tools such as use case and sequence diagrams, class diagrams, entity relationship diagrams, flow charts and the like among others
You can then use these to allocate jobs to the team and identify and focus on components.
(Google "project management" )
From that you need to use various conventional tools such as use case and sequence diagrams, class diagrams, entity relationship diagrams, flow charts and the like among others
You can then use these to allocate jobs to the team and identify and focus on components.
(Google "project management" )
| Should i try to read and understand the entire thing first? |
As you said, there are projects with millions lines of code (e.g. libreoffice has about 5 MLoC), and even hundreds of millions (none in open source, I think, but I worked on a 175 MLoC codebase before).
Trying to "read and understand the entire thing" before doing any work does not scale.
| it better to just stay focused on something small |
That's what always worked for me: even if you have ideas for something big, first fix a few simple bugs, implement a few low-priority small-scale enhancements, and you will have code you recognize and understand, the procedures become familiar, and other devs see you as valuable help.
| what happens when that something small is spread out and could potentially be a conflict with something else? |
First of all, don't be afraid to break code. If it is really a "very well organized" project, the unit tests will direct you to the exact bit of functionality you didn't think of. If not, this will expose lack of coverage and it's a good thing.
Second, if you're changing some "spread out" code, look at who wrote it and if they are still around, ask them to review the changes: they might care about it, it is a polite thing to do.
Topic archived. No new replies allowed.