Timeline for Best Practices for Handing over Legacy Code
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 15, 2011 at 7:00 | vote | accept | PersonalNexus | ||
| Nov 15, 2011 at 7:00 | history | bounty awarded | PersonalNexus | ||
| Nov 15, 2011 at 7:00 | vote | accept | PersonalNexus | ||
| Nov 15, 2011 at 7:00 | |||||
| Nov 15, 2011 at 6:58 | vote | accept | PersonalNexus | ||
| Nov 15, 2011 at 7:00 | |||||
| Nov 10, 2011 at 3:21 | comment | added | James Anderson | @PersonalNexus. You can carry this approach over to documentation as well. Ask which documents are most useful, and, which documents are unreliable or out of date (believe me 95% of documentation falls into the last category!). | |
| S Nov 9, 2011 at 20:18 | history | suggested | Clare Macrae | CC BY-SA 3.0 | Improved formatting, for readability |
| Nov 9, 2011 at 20:13 | review | Suggested edits | |||
| S Nov 9, 2011 at 20:18 | |||||
| Nov 9, 2011 at 18:54 | comment | added | PersonalNexus | I like the idea of picking the parts you mentioned. Intuitively, I would have followed a top-down but that way the most nasty parts buried deep in the code might not have come up until very late, maybe too late in the process. Your way makes more sense, I think. Do you have any suggestions for the "how to document" part? UML? Text? | |
| Nov 8, 2011 at 4:53 | history | answered | James Anderson | CC BY-SA 3.0 |