Timeline for Is it the correct practice to keep more than 10 years old spaghetti legacy code untouched without refactoring at all in big product development?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2023 at 18:07 | comment | added | J. Mini | "My first pull request in really messy legacy code is usually nothing but tests" - But what if the code was never designed to be testable? | |
| Oct 22, 2020 at 16:02 | comment | added | Wiktor Zychla | True refactoring is very methodical, almost mechanical Not really, you can refactor to patterns (e.g. a book by Joshua Kierievsky) which is neither methodical nor mechanical. It requires a deep understanding of what the code does and what pattern it tries to reinvent. | |
| Sep 28, 2020 at 13:26 | comment | added | cmaster - reinstate monica | Note that this mechanical method of refactoring spaghetti code may be the most efficient way to gain an understanding of what the code does. Sufficiently huge spaghetti code is impossible to comprehend, but once you start factoring out the repetitions, sorting them into classes, turning bunches of features into abstractable behavior, you start to see structure. Nevertheless, it may be a giant effort, and it may leave you owing the company (geekherocomic.com/2008/10/09/programmers-salary-policy/…). | |
| Sep 28, 2020 at 4:01 | comment | added | Peter Mortensen | Re "many developers incorrectly call any rewriting refactoring": Yes, indeed (as refactoring has now become cool - refactoring is a synonym for "good"). Often what is really (incorrectly) meant is any improvement that is not adding new features: restructuring, changing/improving interfaces, and removing parts of the system that seems not be used any more (it is also now cool to delete code, even if you don't fully understand it). (Real story - I wasted more than one year of my work life on this account.) | |
| Sep 27, 2020 at 12:55 | comment | added | Peter - Reinstate Monica | As you say, it is often unclear what negative impact the legacy code has. At the same time it is obvious that refactoring will occupy resources lacking elsewhere, and as always the initial estimation probably underestimates the effort. This can be combined to the statement that the net benefit of the refactoring is not apparent to management, and indeed the management may be right! | |
| Sep 26, 2020 at 17:49 | comment | added | Cort Ammon | To add to the measurement problem, Measuring the correctness of your changes is often mighty difficult. This is especially true if the company hasn't been spending the money to maintain the kinds of testing and requirements which make it easier. | |
| Sep 26, 2020 at 7:32 | comment | added | Rui | For the part of code I have refactored, I indeed have understanding on it as I have been maintaining the legacy code base for years. | |
| Sep 26, 2020 at 5:00 | comment | added | Jörg W Mittag | "Changing code you don't understand is a recipe for disaster unless you are making dead simple changes." – This is a variation of Chesterton's Fence. If you can't see why something is there, don't touch it. Only when you understand why something is there, can you delete it. Also, this story from the Jargon File is relevant. | |
| Sep 26, 2020 at 3:35 | history | answered | Karl Bielefeldt | CC BY-SA 4.0 |