Skip to main content
8 events
when toggle format what by license comment
Sep 19, 2012 at 16:05 vote accept dukeofgaming
Sep 1, 2012 at 17:09 comment added Bill the Lizard @Aaronaught Yes, that's an accurate picture of where I'm working at right now. The older code seems to work, but it could all use test cases and refactoring. (It was originally written by quants, but full-time developers have been brought in to extend and maintain it.) New code is constantly being added as regulations change or features are added. We try to treat old code and new code the same by doing code reviews, adding unit tests, and refactoring for every check in.
Sep 1, 2012 at 16:53 comment added Aaronaught I see - so you're looking at this from the perspective of having a (semi) large existing code base that may or not be clean/tested. That's fair. I would agree that there's not much point in doing reconstructive surgery on code that's been in production for months/years. But if the team is putting out fires (OP's words) then that implies that the existing code isn't stable and/or new code is being written that is poor quality, which to me would justify constant/frequent code review and refactoring for new check-ins, and possibly the least stable areas of the application... right?
Sep 1, 2012 at 16:47 comment added Bill the Lizard @Aaronaught No, I consider new code to be a change to the code base. It should definitely be tested and refactored before being checked in.
Sep 1, 2012 at 16:44 comment added Aaronaught I apologize if I'm reading too deeply between the lines, but are you saying that we shouldn't write tests for new code unless and until the functionality needs to change? For legacy code maybe it's a reasonable approach to defer test-writing/refactoring until a change is required, but for new projects - well, that's how they become legacy code.
Sep 1, 2012 at 12:13 comment added Bill the Lizard @Aaronaught I'm not saying anyone should try to predict what's going to need to change at some point in the future. I'm saying you write tests for and refactor what you know you're about to change because a bug fix or new feature calls for it. Those things that change most often will naturally get the most attention.
Sep 1, 2012 at 2:45 comment added Aaronaught I want to agree with this, but developers and business people alike are notoriously poor predictors of what is actually going to need to change, and the longer an individual or team waits before refactoring poor code (especially code with poor or nonexistent tests or documentation), the more brittle that code and any dependent code starts to become. Inevitably it gets to a point where even minor changes are high-risk due to the accumulation of "just this once" hacks and dependencies in other areas of the system, and nobody remembers which parts of the design were intentional vs. incidental.
Aug 31, 2012 at 19:47 history answered Bill the Lizard CC BY-SA 3.0