5 ms·
10 years ago I worked on a large project to re-write a code base written in C. Our approach was to forget about the code and document everything it did from the
by goshx 12y ago
10 years ago I worked on a large project to re-write a code base written in C. Our approach was to forget about the code and document everything it did from the user's perspective.
Once everything was mapped out we decided on what we were going to keep, modify or remove, and then started building everything from scratch.
You can always go back to the original code to see how a particular feature was implemented and perhaps re-use the same logic.
- burnte 12y agoHaving done projects like this before as well, this is the best method. Knowing WHAT needs to be done today and tomorrow is far more important that knowing HOW it was done before. The how is only important once you know what you need to do.
- k__ 12y agolol, so true... Funny thing is, often the users tell you "I used it for XYZ" and it was... ...never been written for XYZ ...never DID XYZ, all the results/numbers were trash, but no one noticed
- _em_ 12y agoI will totally second that approach. Rather spending time on reading code line by line, you should have your team spend time (as a tester) to figure out use-cases. One by one. The end result of those use-cases should be a user-case/requirement document which you can feed into developers cycles to start building from scratch. You can break the steps in more agile method and have 3 sub-teams. 1. Figuring out use cases 2. Developers 3. Testers
- astockwell 12y agoThis. Also from a business- (and CYA-) perspective, this gives you a punchlist of functionality to give to executive management, which can be used for anything from doing a proper scoping exercise to actually giving you a metric to show progress against.
- pan69 12y agoIndeed. Code is useless without the people who wrote it being around. It's not the code that's valuable, it's the experience of the programmers who it that's valuable.