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

Announcing the Second Edition of “Refactoring”

martinfowler.com

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Announcing the Second Edition of “Refactoring”

#31

Post by jeremiep »

solipsism wrote: post #29
digorithm wrote: post #3

Wow, this is huge! I'm stoked for the book. I'm surprised-but-not-really that it will use JavaScript as its main language to teach the concepts! > When I wrote the first edition I was frustrated that I was having to write the book's code in a language that was significantly worse than the language I preferred (Smalltalk). Little did I know that I would take another step downwards twenty years later. Oh, the irony!

But the compelling reason for choosing it over Java is that isn't wholly centered on classes. That doesn't explain why choose it from among the majority of other languages that aren't centered on classes. JavaScript is so quirky, it seems like a really strange choice for a general programming book. Perhaps it's my back end bias showing.

He probably went where most developers are. Just like choosing Java over Smalltalk for the first edition.

I feel its better to reach more developers, than aim for the best technologies that very few are actually even aware of.

Re: Announcing the Second Edition of “Refactoring”

#32

Post by pelhage »

jmsaucier wrote: post #26
saryant wrote: post #19

Earlier quoted context omitted.

A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time. Keep those tasks separate.

I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.

The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line

Re: Announcing the Second Edition of “Refactoring”

#33

Post by digorithm »

jeremiep wrote: post #31
solipsism wrote: post #29

Earlier quoted context omitted.

But the compelling reason for choosing it over Java is that isn't wholly centered on classes. That doesn't explain why choose it from among the majority of other languages that aren't centered on classes. JavaScript is so quirky, it seems like a really strange choice for a general programming book. Perhaps it's my back end bias showing.

He probably went where most developers are. Just like choosing Java over Smalltalk for the first edition. I feel its better to reach more developers, than aim for the best technologies that very few are actually even aware of.

Exactly my thoughts!

Re: Announcing the Second Edition of “Refactoring”

#34

Post by konamicode »

pelhage wrote: post #32
jmsaucier wrote: post #26

Earlier quoted context omitted.

I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.

The problem I deal with is that if I see something worth improving that doesn't get fixed now as I see it, unless it's a really significant issue, the code won't get improved down the line

At work, we often create tickets to deal with such things and have epics dedicated to "code gardening". These are often addressed on a Friday afternoon or at other times when one feels their productivity is especially low.

Re: Announcing the Second Edition of “Refactoring”

#35

Post by Dangeranger »

jacobkg wrote: post #8
thaumaturgy wrote: post #2

I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not everything needs to be a class). Has anybody here read the first edition, and what was your impression of it?

One of my biggest lessons from the book is right in the introduction. To paraphrase: "If a change you want to make to the codebase is hard, refactor the codebase until that change is easy, then make the change". I always try to either be refactoring or changing behavior but not both at the same time. That has kept me out of a lot of trouble.

This quote is inspired by Kent Beck who coined it while he and Martin Fowler were working together.

> "For each desired change, make the change easy (warning: this may be hard), then make the easy change"[0]

[0] https://twitter.com/KentBeck/status/250733358307500032

Edit: Added a link to his first Tweet containing the quote that I know of.

Re: Announcing the Second Edition of “Refactoring”

#36

Post by bcbrown »

jmsaucier wrote: post #26
saryant wrote: post #19

Earlier quoted context omitted.

A rule of thumb that I try to follow (but often neglect) is to keep changes either sweeping/shallow or narrow/deep. So if you're refactoring a module and that has implications across the codebase, don't try to make a deep change to the business logic at the same time. Keep those tasks separate.

I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.

One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.

Re: Announcing the Second Edition of “Refactoring”

#37

Post by kodablah »

solipsism wrote: post #29
digorithm wrote: post #3

Wow, this is huge! I'm stoked for the book. I'm surprised-but-not-really that it will use JavaScript as its main language to teach the concepts! > When I wrote the first edition I was frustrated that I was having to write the book's code in a language that was significantly worse than the language I preferred (Smalltalk). Little did I know that I would take another step downwards twenty years later. Oh, the irony!

But the compelling reason for choosing it over Java is that isn't wholly centered on classes. That doesn't explain why choose it from among the majority of other languages that aren't centered on classes. JavaScript is so quirky, it seems like a really strange choice for a general programming book. Perhaps it's my back end bias showing.

From the article:

> Such a language needed to be widely popular, among the top half a dozen in language popularity surveys. It really helps to have a C-based syntax, since most programmers would recognize the basic code structure

You can argue others, but at least this will help you understand why he chose it over many other languages that aren't centered on classes.

Re: Announcing the Second Edition of “Refactoring”

#38

Post by funkymike »

thaumaturgy wrote: post #2

I'm hunting around these days for good books on general programming. I'm a fairly pragmatic programmer (not everything needs to be a class). Has anybody here read the first edition, and what was your impression of it?

To me refactoring doesn't need a whole book or set of terminology. So long as a person understands and values the principles the individual refactorings will come naturally with experience. In my view it comes down to three main points.

1. Refactoring does not change functionality. The observable behavior should be the same before and after.

2. Refactoring should be done one step at a time. Each step should be as small as possible and obviously correct.

3. When changing code, at any given time you should be working on a functional change or refactoring - never both at once. Ideally these should be split into separate commits as well.

I think beyond the principles something like extracting a chunk of code into a separate function is not a task that needs a proper name. It's just something that comes naturally once you get into a mindset of always making things better, or as we say where I work: "suck less." It's getting into this mindset that takes the most work. If every time I deploy code it sucks less, or even just on average, that's good enough.

Refactoring is compound interest for maintainability. Once people buy into this everything starts getting better.

I also believe that you should never ask permission to refactor - just do it. A gardener who's task is to mow the lawn shouldn't ask permission before pulling a weed just because it's outside the narrow scope of the task at hand. Likewise a programmer should not ask permission before refactoring code (excluding large, time consuming refactors).

Re: Announcing the Second Edition of “Refactoring”

#39

Post by Sileni »

solipsism wrote: post #29
digorithm wrote: post #3

Wow, this is huge! I'm stoked for the book. I'm surprised-but-not-really that it will use JavaScript as its main language to teach the concepts! > When I wrote the first edition I was frustrated that I was having to write the book's code in a language that was significantly worse than the language I preferred (Smalltalk). Little did I know that I would take another step downwards twenty years later. Oh, the irony!

But the compelling reason for choosing it over Java is that isn't wholly centered on classes. That doesn't explain why choose it from among the majority of other languages that aren't centered on classes. JavaScript is so quirky, it seems like a really strange choice for a general programming book. Perhaps it's my back end bias showing.

Python is amazing for these types of books. Written with the intention in mind, the actual code reads like pseudo-code, and a good percentage of people have interacted with the language at least briefly. Though the latter point is certainly more relevant for JS.

I'm sure the author had his reasons, and there are certainly worse choices in the top dozen languages. (Refactoring... in PHP!)

Re: Announcing the Second Edition of “Refactoring”

#40

Post by funkymike »

bcbrown wrote: post #36
jmsaucier wrote: post #26

Earlier quoted context omitted.

I find that I will be making a change, notice a refactoring, and then get lost in the rabbit hole. I try to keep a pad of paper by me at all times now, and if I notice something, then I will make note of it, but keep moving with what I was doing. Then after I'm done, I can revisit the notes that are on my paper. Right now, a lot of those become backlog techdebt items that will get fixed in the future.

One approach I sometimes take is to make the refactoring in one commit and the change in another. They can go into the same PR (within reason), but they're clearly separated out.

This is the approach I try to take. It requires discipline but it has helped on several occasions.

The biggest benefit is that it makes code reviews easier for others because the reviewer can step through each commit. This makes the refactoring changes much more obvious.

Splitting the commits also makes it much easier to roll back a functional change that goes wrong or isn't needed while still keeping the refactoring improvements.

Post reply on HN