4 ms·

For rewrite from scratch projects, I always start by identifying the use cases covered by the application. You don't need the code for that. Just run the applic

For rewrite from scratch projects, I always start by identifying the use cases covered by the application. You don't need the code for that. Just run the application and identify what it is that it does. Then, work backwards. For each use case, use the existing code as specification of the use case behavior. At 100 million lines, I'd suspect this is either an extremely large project, where a rewrite from scratch is inadvisable, or that there is a code generator at work. If it is the latter, you want to analyze the code generating source, not the end result. Anyhow, generically, for a first contact with a new code base, code coverage tools are a good start, as is a call graph debug run of the project. It'll let you spot dead code as well as hot code (code being called at every run of the application). It'll highlight the important and non-important code parts, allowing you to read less code and get a grasp on the architecture.

rkalla 12y ago
This, 100x this. You and your team don't just have to build an understanding of the code (e.g. frameworks, patterns, DB's, etc.) but the app itself so you can truly understand it's purpose. Your rewrite won't (hopefully?) also be 100mm lines so being able to understand the high level purpose of the app completely and then diving deep from there, you may (hopefully) find many places where the system can be simplified. Are you really not exaggerating? 100mm lines of source? Yiiiikes...
fleitz 12y ago
Yup, start the profiler up, use the application, check the call graph. At 100 MLOC the code base is probably a complete mess. Also, simian is probably your friend as it will identify large chunks of duplicate code. As well source control can be your friend, the older the source is the more likely it is to contain useful code. The files with the most changes will usually be where the bugs are.
- jacquesm 12y ago
  Why did this get downvoted? It's actionable and on topic.
stronglikedan 12y ago
I could be wrong, but I think the "M" means thousands in this case. I know it means thousands when dealing with inventory UOMs. 100 million lines just seems like a lot, even for a code generator, and not something that would be turned over to a single team.
- crpatino 12y ago
  I don't think there are that many companies with ~10^8 LOC code bases in the world, let alone for a single product[1]: Facebook(webapp): ~310^7 LOC Linux Kernel: ~210^7 LOC Windows XP: ~5*10^7 LOC My impression is that 10 million LOC codebase is relatively common... but past that the size of the organization (company or volunteers) needed becomes a major sorting criteria. [1] http://www.wired.com/2013/04/facebook-windows/ http://www.wired.com/2013/04/facebook-windows/
  - atmosx 12y ago
    Yes but these project are no dumped to a team to re-write them all the often, are they? The way I get this, his team is limited in personnel and resources and kinda overwhelmed by the project. I'm sure Facebook/Linux (OS devs)/Microsoft are not exactly out of developers.
    - crpatino 12y ago
      All the more reason to sharpen the good old resume... if there was not a typo in the OP numbers, this smells a lot like an intentional career killer.
  - n1ghtmare_ 12y ago
    I realize Facebook is not a trivial software, but seriously - this large? I heard this before and I just don't get it.
  - crpatino 12y ago
    Errata. Numbers should read as: Facebook(webapp): ~3 * 10^7 LOC. Linux Kernel: ~2 * 10^7 LOC. Windows XP: ~5 * 10^7 LOC.
johan_larson 12y ago
Identify the users. Figure out who actually does anything with the system. They'll be invaluable as you try to determine what part of the system are active. Look for a test suite. You'll need one once you start making changes, to keep from breaking anything. If necessary create one based on actual jobs run of the system. You want integration tests, for big parts of the system, rather than unit tests. Once you have a test suite, start with dead code analysis. Any codebase as big as this one will have a lot of accumulated cruft that is just getting in the way. Delete it.

rkalla 12y ago

This, 100x this. You and your team don't just have to build an understanding of the code (e.g. frameworks, patterns, DB's, etc.) but the app itself so you can truly understand it's purpose. Your rewrite won't (hopefully?) also be 100mm lines so being able to understand the high level purpose of the app completely and then diving deep from there, you may (hopefully) find many places where the system can be simplified. Are you really not exaggerating? 100mm lines of source? Yiiiikes...

fleitz 12y ago

Yup, start the profiler up, use the application, check the call graph. At 100 MLOC the code base is probably a complete mess. Also, simian is probably your friend as it will identify large chunks of duplicate code. As well source control can be your friend, the older the source is the more likely it is to contain useful code. The files with the most changes will usually be where the bugs are.

jacquesm 12y ago
Why did this get downvoted? It's actionable and on topic.

stronglikedan 12y ago

I could be wrong, but I think the "M" means thousands in this case. I know it means thousands when dealing with inventory UOMs. 100 million lines just seems like a lot, even for a code generator, and not something that would be turned over to a single team.

crpatino 12y ago
I don't think there are that many companies with ~10^8 LOC code bases in the world, let alone for a single product[1]: Facebook(webapp): ~310^7 LOC Linux Kernel: ~210^7 LOC Windows XP: ~5*10^7 LOC My impression is that 10 million LOC codebase is relatively common... but past that the size of the organization (company or volunteers) needed becomes a major sorting criteria. [1] http://www.wired.com/2013/04/facebook-windows/ http://www.wired.com/2013/04/facebook-windows/
- atmosx 12y ago
  Yes but these project are no dumped to a team to re-write them all the often, are they? The way I get this, his team is limited in personnel and resources and kinda overwhelmed by the project. I'm sure Facebook/Linux (OS devs)/Microsoft are not exactly out of developers.
  - crpatino 12y ago
    All the more reason to sharpen the good old resume... if there was not a typo in the OP numbers, this smells a lot like an intentional career killer.
- n1ghtmare_ 12y ago
  I realize Facebook is not a trivial software, but seriously - this large? I heard this before and I just don't get it.
- crpatino 12y ago
  Errata. Numbers should read as: Facebook(webapp): ~3 * 10^7 LOC. Linux Kernel: ~2 * 10^7 LOC. Windows XP: ~5 * 10^7 LOC.

johan_larson 12y ago

Identify the users. Figure out who actually does anything with the system. They'll be invaluable as you try to determine what part of the system are active. Look for a test suite. You'll need one once you start making changes, to keep from breaking anything. If necessary create one based on actual jobs run of the system. You want integration tests, for big parts of the system, rather than unit tests. Once you have a test suite, start with dead code analysis. Any codebase as big as this one will have a lot of accumulated cruft that is just getting in the way. Delete it.