Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The key points of "Working Effectively with Legacy Code"

understandlegacycode.com

Post reply on HN
Print view View original

21–30 of 74 posts

Re: The key points of "Working Effectively with Legacy Code"

#21

Post by th0ma5 »

Lovesong wrote: post #17

I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however: >But the code examples are in Java and C++ and I do python/JavaScript/ruby/ The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your…

I've skimmed the source material and it doesn't either except for the general advice of putting it all in some kind of conceptual box and slowly move parts to modern or better managed solutions as you try to reverse engineer it all. The underlying subtext was that it is all probably worse than you think and there isn't much good news... But "containment" in various forms is the direction forward mostly unfortunately.

Re: The key points of "Working Effectively with Legacy Code"

#22

Post by jaggederest »

bitwize wrote: post #20
Lovesong wrote: post #17

I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however: >But the code examples are in Java and C++ and I do python/JavaScript/ruby/ The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your…

> VB.NET *laughs in VBA*

I got started professionally in ASP/JScript. That's right, ADO through JScript, backend programming in javascript circa 2001.

(If you've never heard of JScript, be thankful. It was microsoft's very-slightly-modified ECMAscript variant)

Re: The key points of "Working Effectively with Legacy Code"

#23

Post by PaulHoule »

commandlinefan wrote: post #10

Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…

My feeling about it is that there is not a tension between refactoring and feature work but rather that a specific bit of feature work is best done with a refactoring. For instance about 10 components on a certain page I was working on all had the same accessibility problem which involved changed the HTML and then changing the CSS so this is a good chance to make a single component which can be used to replace the problematic code in all 10 components and to rationalize the CSS.

Re: The key points of "Working Effectively with Legacy Code"

#24

Post by strken »

Lovesong wrote: post #17

I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however: >But the code examples are in Java and C++ and I do python/JavaScript/ruby/ The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your…

> the article doesn't give any compelling argument to answer this

Is "[w]hen code is not tested, how do you know you didn’t break anything?" not a compelling argument to your boss?

Re: The key points of "Working Effectively with Legacy Code"

#25

Post by jbjbjbjb »

Big caveat that I’ve not read the book but I get that the premise is “legacy code is code that is untested” and I’ve always struggled with that definition. I think a more accepted definition would be that it is not well understood, uses old tooling/languages/runtimes and is usually high stakes code (driving some business that was successful enough to last longer than the staff that coded it up). I’m sure added tests help deal with legacy code under that definition but not sure it’s the panacea, I’ve certainly seen code without tests lots very high coverage that people area afraid to work on due to them being unfamiliar with the domain and codebase.

Re: The key points of "Working Effectively with Legacy Code"

#27

Post by MarkSweep »

Lovesong wrote: post #17

I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however: >But the code examples are in Java and C++ and I do python/JavaScript/ruby/ The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your…

Would you be so lucky if your legacy code was written in a well-known language. At a previous employer we had a big pile code in a “macro” language. It could interface with the main C++ code base. It was similar to assembly language in that it had no loops (just gotos) and register-like local variables (no custom names, just L0, L1, L2,…). The semantics were weird, something like unexpected pass-value-value versus pass-by-reference behavior when calling functions.

One customer required lengthy qualification processes when changing the software. But “configuration changes” had a lower bar and somehow these “macros” counted as config. So eventually all the interesting business logic and RPC processing end up in a giant macro file.

Re: The key points of "Working Effectively with Legacy Code"

#28

Post by _mu »

commandlinefan wrote: post #10

Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…

> now you have to be careful how and when you use the term "refactor" because the people who ought to be supportive hear "wasting time".

Programmers had a hand in this, sadly: https://martinfowler.com/bliki/RefactoringMalapropism.html

Nowadays people throw the term "refactoring" around quite loosely, usually meaning "rewrite" when that was not at all the original meaning of the term!

A little bit like how "vibe coding" quickly went from one definition to another even though people should have known better.

Re: The key points of "Working Effectively with Legacy Code"

#29

Post by kens »

Lovesong wrote: post #17

I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however: >But the code examples are in Java and C++ and I do python/JavaScript/ruby/ The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your…

I read the book shortly after it came out, when I was working on an enormous system of legacy code. Unfortunately, I didn't find the book particularly helpful in terms of strategies for understanding or modifying legacy code. Yes, tests are a good thing, but I expected the book to provide a lot more.

I agree with the parent comment that it is useful to follow the "trail" through the code. It can be a big effort just to figure out how the pieces are connected. Figuring out the data structures and files is another important thing. Also, write documentation as you go; this will help others understand the big picture. If you can just jump in and start writing meaningful unit tests, your legacy system is kinda trivial :-)

Overall, there are people who view testing as a useful tool and people who view testing as an ideology. This book falls into the latter category.

Post reply on HN