7

So there is this program with legacy code from 15 years ago the client is in love with. Every time we try to accomplish something it proves that the mf who wrote it was so lazy and incompetent that he should have never chosen this profession. Goto, one-two letter for type and variable names. Dude even wrote an ascii decoder as if he would be payed for lines of code. Today we found a code where a rows of data was misindexed by one (we incorrectly assumed that we could extract some data from it but the column we wanted to use was just there for decoration, it was not actually used). the calculations the system uses are replicated for each interface with duplicate lines of code so the same binary data can show different values because of the multipliers.

If I could I woukd go back in time and bang the guy's head to the desk emphasising each word like "You - should - quit - and - never - ever - write - code -again"

Comments
  • 7
    There's an art to working with legacy code.

    Step 1) define current behavior
    Step 2) write tests to confirm it behaves that way
    Step 3) refactor with added confidence

    Loop over this as you discover new behaviors and update your testing assumptions

    Once the code base is in a feature friendly state, then start adding new behaviors.

    It's a tonne of work but it can be done without reduced frustration, and if you get good at it, there's big bucks
  • 2
    15 year old program end users still love? I'd call that a win.
  • 1
    I guess I would have to see the code. I have run into some interesting things at my current job. Just weird stuff. The walled gardens bother me the most.
  • 0
    @Demolishun which one Apple or Microsoft?
  • 0
    @max19931 I am talking about code hidden behind walled gardens by the programmer. Making all class definitions be in the cpp file rather than in the h file. So your only interface is one class with a couple of functions. Makes code reuse non-existent.
  • 1
    @lungdart ir was 3-4 month just to understand how a 4 module distributed component works, which i was assigned to. Writing tests is very hard in this distributed system because individual modules are written so that unit tests are impossible (no intetfaces no dependency injection and goto's everywhere) And prod release happens only when there is a business value added. That means if we refactor we will see if it breaks anything in 3 months when business needs something we can release.
    That said in the last 5 month we managed to rewrite this distributed component in a testable way and now we have some unit tests have a system test for basic use case. But still we get surprises when something arises. And it makes me angry just how this code has never been reviewed and it kived through 13years without source control
Add Comment