5 ms·

Working Effectively with Legacy Code by Michael Feathers. It's a bit hard to wrap your brain around the Java and C++ examples unless you have experience with t

Working Effectively with Legacy Code by Michael Feathers. It's a bit hard to wrap your brain around the Java and C++ examples unless you have experience with them, but the techniques are timeless. You may need to practice them extensively before you understand how important they are, though. In a recent book club we did at work, a common complaint was, "This just looks like common sense". Indeed it does... though the common sense is uncommonly hard to find when you are staring at the actual situations this book helps you with.

sepent 9y ago
I just finished reading this book yesterday. I am not an expert in refactoring but the book seems too old, although most advises could be still useful. Anyway, today I found a new book by the author: Brutal Refactoring: More Working Effectively with Legacy Code. Unfortunately, I couldn't find a good review of the book on the Internet. But I think it could be more useful.
- fsloth 9y ago
  "the book seems too old" 2004 is old now? Really? Honestly, good books don't age as long as their core domain stays valid. Structurally C++ is pretty much the same as when the book came out.
  - johndubchak 9y ago
    Modern IDEs can deliver many of the recommendations of the book. Our productivity has increased a great deal. Back then there was no intellisense, code navigation through clicking on method names/classes etc. highlighted syntax errors, built-in unit test frameworks etc. It was written for a different type of developer and a different type of development environment and a specific language, C++. You haven't looked at C++ lately if you think it's the same as it was in 2004. The ISO has released new versions of the language in 2011, 2014 and ratified a new standard here in 2017. If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++. Edit: Modern C++ contains native support for the filesystem, threads, lambda expressions, variants, upcoming networking library, coroutines (at least in Visual Studio), no more new/delete memory management, parallel algorithms and a ton more. This is a completely different language now and the code you write looks nothing like 2004 C++ code.
    - pvg 9y ago
      Our productivity has increased a great deal. Back then there was no intellisense, code navigation through clicking on method names/classes etc. highlighted syntax errors, built-in unit test frameworks etc. Just about all of these things were around in 2004.
    - mattmanser 9y ago
      Intellisense (the MS one) was introduced in 1996. VB6 had good intellisense. I seem to remember having intellisense while working in classic asp vb (as in pre .Net), but could be wrong, it's so long ago now.
    - atilaneves 9y ago
      A lot of people have to maintain legacy C++98 codebases and don't get to play with new compilers.
    - fsloth 9y ago
      "You haven't looked at C++ lately if you think it's the same as it was in 2004." "If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++." I applaud your attempt at an authoritative voice. But you focus on mostly technical trivia that are thin scaffolding on top of the language. I agree modern C++ is nice but it's the same language still. "This is a completely different language now and the code you write looks nothing like 2004 C++ code." Are you trolling? This reads like a transcript from a TV commercial.
      - khedoros1 9y ago
        They sound like they're echoing the kinds of things that are normally said about C++11. > I agree modern C++ is nice but it's the same language still. Well...in the same sense that any language is the same language after you add a bunch of things to it that weren't there before and shift to using those new features as idiomatic parts of the language. I would expect C++ written in 2004 to use different patterns than C++ written in 2017. Not "completely different"...but different.
- johndubchak 9y ago
  Me and a friend continually send IM's to each other, "LEAN ON THE COMPILER!". That statement alone, one of the sections of the book, recommending you to allow the compiler to find your errors for you, is an example of the "age" of the book. At the time I read it, when it first came out, I loved it. I still love Michael's work and advice to this day, but this book was written for another time.
  - TeMPOraL 9y ago
    I do not understand this. It seems like a perfectly good advice, and in fact it's what I'm doing every day - leaning on my compiler, and in Java world, on my IDE. And also it seems to be something lots of programmers don't realize for some reason - many times I had to instruct people to crank up their compiler warning settings and actually read them. Especially in C-land, I can't count the number of times I solved someone's problem by appending -Wall to the gcc invocation and telling them to come back after they fixed all the warnings...
    - johndubchak 9y ago
      My point was that with a modern IDE we can do that without resorting to a full compile, which can be burdensome with large codebases. The IDE space has improved a lot since 2004, eg. Jetbrains' tools around refactoring and code cleanup suggestions, make things super simple. Don't get me wrong, I've read this book, multiple times, it's on my bookshelf and think it's a great book, but it was written when the state of development was a much different landscape, IMO.
      - deleted 9y ago
        [deleted]
      - biot 9y ago
        Leaning on incremental compile via a modern IDE is leaning on the compiler. The principle is the same, even if the implementation slightly differs.
- hinkley 9y ago
  Every day I wished I'd listened to the XP guys the first time I encountered it, and most of that material is from the late 90's. And Fred Brookes' book is over 30 and sadly just as relevant.
- mikekchar 9y ago
  Just looking at the responses to this comment, I have to say that I agree with both sides. The book is really dated, but the advice is timeless. The biggest problem I've had trying to get people to take the book seriously is that they can not identify with it. I had not realised that Michael Feathers had written a followup. I will definitely take a look. Thanks!!!

sepent 9y ago

I just finished reading this book yesterday. I am not an expert in refactoring but the book seems too old, although most advises could be still useful. Anyway, today I found a new book by the author: Brutal Refactoring: More Working Effectively with Legacy Code. Unfortunately, I couldn't find a good review of the book on the Internet. But I think it could be more useful.

fsloth 9y ago
"the book seems too old" 2004 is old now? Really? Honestly, good books don't age as long as their core domain stays valid. Structurally C++ is pretty much the same as when the book came out.
- johndubchak 9y ago
  Modern IDEs can deliver many of the recommendations of the book. Our productivity has increased a great deal. Back then there was no intellisense, code navigation through clicking on method names/classes etc. highlighted syntax errors, built-in unit test frameworks etc. It was written for a different type of developer and a different type of development environment and a specific language, C++. You haven't looked at C++ lately if you think it's the same as it was in 2004. The ISO has released new versions of the language in 2011, 2014 and ratified a new standard here in 2017. If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++. Edit: Modern C++ contains native support for the filesystem, threads, lambda expressions, variants, upcoming networking library, coroutines (at least in Visual Studio), no more new/delete memory management, parallel algorithms and a ton more. This is a completely different language now and the code you write looks nothing like 2004 C++ code.
  - pvg 9y ago
    Our productivity has increased a great deal. Back then there was no intellisense, code navigation through clicking on method names/classes etc. highlighted syntax errors, built-in unit test frameworks etc. Just about all of these things were around in 2004.
  - mattmanser 9y ago
    Intellisense (the MS one) was introduced in 1996. VB6 had good intellisense. I seem to remember having intellisense while working in classic asp vb (as in pre .Net), but could be wrong, it's so long ago now.
  - atilaneves 9y ago
    A lot of people have to maintain legacy C++98 codebases and don't get to play with new compilers.
  - fsloth 9y ago
    "You haven't looked at C++ lately if you think it's the same as it was in 2004." "If you're writing C++ code that is consistent with 2004 C++ then you're writing a really bad version of "C with classes", not C++." I applaud your attempt at an authoritative voice. But you focus on mostly technical trivia that are thin scaffolding on top of the language. I agree modern C++ is nice but it's the same language still. "This is a completely different language now and the code you write looks nothing like 2004 C++ code." Are you trolling? This reads like a transcript from a TV commercial.
    - khedoros1 9y ago
      They sound like they're echoing the kinds of things that are normally said about C++11. > I agree modern C++ is nice but it's the same language still. Well...in the same sense that any language is the same language after you add a bunch of things to it that weren't there before and shift to using those new features as idiomatic parts of the language. I would expect C++ written in 2004 to use different patterns than C++ written in 2017. Not "completely different"...but different.
johndubchak 9y ago
Me and a friend continually send IM's to each other, "LEAN ON THE COMPILER!". That statement alone, one of the sections of the book, recommending you to allow the compiler to find your errors for you, is an example of the "age" of the book. At the time I read it, when it first came out, I loved it. I still love Michael's work and advice to this day, but this book was written for another time.
- TeMPOraL 9y ago
  I do not understand this. It seems like a perfectly good advice, and in fact it's what I'm doing every day - leaning on my compiler, and in Java world, on my IDE. And also it seems to be something lots of programmers don't realize for some reason - many times I had to instruct people to crank up their compiler warning settings and actually read them. Especially in C-land, I can't count the number of times I solved someone's problem by appending -Wall to the gcc invocation and telling them to come back after they fixed all the warnings...
  - johndubchak 9y ago
    My point was that with a modern IDE we can do that without resorting to a full compile, which can be burdensome with large codebases. The IDE space has improved a lot since 2004, eg. Jetbrains' tools around refactoring and code cleanup suggestions, make things super simple. Don't get me wrong, I've read this book, multiple times, it's on my bookshelf and think it's a great book, but it was written when the state of development was a much different landscape, IMO.
    - deleted 9y ago
      [deleted]
    - biot 9y ago
      Leaning on incremental compile via a modern IDE is leaning on the compiler. The principle is the same, even if the implementation slightly differs.
hinkley 9y ago
Every day I wished I'd listened to the XP guys the first time I encountered it, and most of that material is from the late 90's. And Fred Brookes' book is over 30 and sadly just as relevant.
mikekchar 9y ago
Just looking at the responses to this comment, I have to say that I agree with both sides. The book is really dated, but the advice is timeless. The biggest problem I've had trying to get people to take the book seriously is that they can not identify with it. I had not realised that Michael Feathers had written a followup. I will definitely take a look. Thanks!!!