3 ms·
Not all functions are refactorable. A 'purely hypothetical' scenario: a numeric routine of several klocs on length, that takes in 20 parameters with 1-3 letter
by fsloth 11y ago
Not all functions are refactorable. A 'purely hypothetical' scenario: a numeric routine of several klocs on length, that takes in 20 parameters with 1-3 letter obscure variable names, was written 30 years ago in fortran, was f2c:d 20 years ago into c and has been doing it's 'stuff' correctly ever since somewhere in the bottom of mission critical code in a codebase of millions of lines. Commercial codebase. Only a handful of developers. Management expect new features and expedient, safe bugfixes that do not change end user functionality.
- TeMPOraL 11y agoThat's actually simple. All you need is to npm yeoman to generate a proper skeleton for grunt and gulp to work using Mockito.js, C2F.js and Fortran.js, then you can auto-generate unit tests that will be paralelly distributed over AWS. More seriously though, the kind of code you described will be what I imagine the first subject of study of the software archeology field in the future. http://akkartik.name/post/deepness http://akkartik.name/post/deepness
- annnnd 11y agoThe scenario you describe is a disaster waiting to happen. Refactor it, preferably yesterday - but make a "shadow deploy". For each set of input / output parameters run both functions and compare them. If they differ, use the old one and go back to figuring out where it went wrong. After some time you can be quite sure that the new clean function works as it should - then you just switch.
- HerpDerpLerp 11y agoI am not sure the above idea is mentioned by Michael Feathers in his amaze book "Working Effectively with Legacy Code" but it is a great idea, and combined with the things that Michael does cover will do you a lot of good! http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 http://www.amazon.co.uk/Working-Effectively-Legacy-Michael-F...