4 ms·

My inspiration from massive science projects is more like: "With that in mind, debugging this 1500-line function is nothing!"

by nerdy 11y ago

balabaster 11y ago
Dude... refactor that shit. There is no place in today's development world that a 1500 line function is okay :P
- Practicality 11y ago
  Indeed. It will save you from needing inspiration to debug it as well. It's much less cognitive load when you break those crazy things into understandable parts.
  - joelberman 11y ago
    The potential speedup on those old F2C routines is amazing. The ability to use much more memory, understand cache levels, etc. have a huge impact.
- TeMPOraL 11y ago
  When was the last time you've seen pure Assembly? Also, JavaScript namespacing shenanigans & stuff... :P.
  - nerdy 11y ago
    I make 3rd party/unsanctioned mods for video games in my free time, which involves plenty of Assembly :)
- 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 ago
    That'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 ago
    The 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 ago
      I 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...
- nerdy 11y ago
  It's a legacy system developed by someone who is lucky he lives 4300 miles away! I've been working at the system to free it from that subsystem with an eventual replacement. There are all kinds of single-letter variables and Russian words, refactoring wouldn't be economical or sane.

My inspiration from massive science projects is more like: "With that in mind, debugging this 1500-line function is nothing!"

by nerdy 11y ago

My inspiration from massive science projects is more like: "With that in mind, debugging this 1500-line function is nothing!"

balabaster 11y ago

Dude... refactor that shit. There is no place in today's development world that a 1500 line function is okay :P

Practicality 11y ago
Indeed. It will save you from needing inspiration to debug it as well. It's much less cognitive load when you break those crazy things into understandable parts.
- joelberman 11y ago
  The potential speedup on those old F2C routines is amazing. The ability to use much more memory, understand cache levels, etc. have a huge impact.
TeMPOraL 11y ago
When was the last time you've seen pure Assembly? Also, JavaScript namespacing shenanigans & stuff... :P.
- nerdy 11y ago
  I make 3rd party/unsanctioned mods for video games in my free time, which involves plenty of Assembly :)
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 ago
  That'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 ago
  The 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 ago
    I 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...
nerdy 11y ago
It's a legacy system developed by someone who is lucky he lives 4300 miles away! I've been working at the system to free it from that subsystem with an eventual replacement. There are all kinds of single-letter variables and Russian words, refactoring wouldn't be economical or sane.