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

51–60 of 61 posts

Re: Announcing the Second Edition of “Refactoring”

#51

Post by mherrmann »

thaumaturgy wrote: post #15
mherrmann wrote: post #7

Earlier quoted context omitted.

I read it 15 years ago. No other book has influenced my programming as much as this one. The main value I got from it is that it teaches you what "clean" code looks like. Highly recommended.

You might also enjoy "Beautiful Code" then. While not everyone will agree that every example in that book is "beautiful", usually there's something in there for everyone. It's currently my favorite generalized programming book.

Thank you for the suggestion. I started that one but somehow never finished it.

Re: Announcing the Second Edition of “Refactoring”

#52

Post by Karunamon »

SlySherZ wrote: post #43
Karunamon wrote: post #21

Earlier quoted context omitted.

I'm asking this from a position of massive ignorance (I'm mostly a backend dev who does the occasional website), but is there any type hinting tooling in the Javascript ecosystem? Python has PEP484 where you annotate types in either comments or docstrings, Ruby has YARD tags used similarly, and smart IDEs can pick up on these and offer decent refactoring tools. But does anything similar exist in JS land?

Yes, there is JSDoc[1] which allows you to add type annotations in comments, that can then be used by some tool. The VSCode editor is able to leverage the TypeScript engine even with vanilla JS to automatically infer types and also supports JSDoc. Basically you write vanilla JS, add JSDoc comments here and there when the inference doesn't work as you want and it gives you most benefits of a typed language, without ty…

This is more what I was looking for; the others appear to be supersets of JS.

Re: Announcing the Second Edition of “Refactoring”

#53

Post by quietbritishjim »

hyperpape wrote: post #46
quietbritishjim wrote: post #45

I realise this is an unpopular opinion, but I really didn't like the previous book. Don't get me wrong, I definitely think refactoring is a good thing (in moderation!). But Fowler presented a list of possible refactoring operations, including step by step instructions... for very trivial things. In the introduction he drew comparisons with GoF design patterns book, saying he wrote it hoping people would refer back to…

I never read more than a fraction of the first edition, but I found it valuable. The key idea was that refactoring was a methodical, careful process that consists of steadily taking the code from one working state to another. At the time, refactoring was a dirty word at my company, and people didn’t distinguish it from rewriting code in any arbitrary fashion.

This sounds mostly like the first chapter, which was the bit I enjoyed the most. That was about automated testing, and a whole book about that might've been quite useful.

Re: Announcing the Second Edition of “Refactoring”

#54

Post by mcguire »

slobotron wrote: post #13
mcguire wrote: post #11

Earlier quoted context omitted.

I found it very interesting for being one of the very few books that deals with code as a formal system. You don't need to understand the code; you don't need to step through the code. You follow the steps for "extract method" and you go from a working state to another working state with no worries. The individual refactorings are more-or-less interesting, but as others have said, they're somewhat commonplace now. Tw…

Would you recommend "Software Tools in Pascal" vs the original?

Either. The details aren't especially relevant in either case. I just picked one.

Re: Announcing the Second Edition of “Refactoring”

#55

Post by hyperpape »

quietbritishjim wrote: post #53
hyperpape wrote: post #46

Earlier quoted context omitted.

I never read more than a fraction of the first edition, but I found it valuable. The key idea was that refactoring was a methodical, careful process that consists of steadily taking the code from one working state to another. At the time, refactoring was a dirty word at my company, and people didn’t distinguish it from rewriting code in any arbitrary fashion.

This sounds mostly like the first chapter, which was the bit I enjoyed the most. That was about automated testing, and a whole book about that might've been quite useful.

Automated testing is great, but you can apply the core idea to code without automated tests. The difference is that you have to be even more mechanical and cautious.

In addition to the principles about refactoring, reading a few of the examples helped to drive in how methodical it was.

Re: Announcing the Second Edition of “Refactoring”

#56

Post by edem »

Am I the only one who thinks that using javascript is a terrible, horrible, no-go decision?

He could have chosen Python which is also one of the top languages and it does not have the quirks of javascript.

I can't help but feel that he only chose this language because this is the language which will net him the most ROI.

And we'll take the collateral damage which is an influx of people who will wave his book and say "Let's use this language! Even Mr. Fowler uses it! This must mean that this is the best language there is!"

Imagine the damage this will do to us grunt programmers in the field. Now it will be even harder to push real languages through management now that a celebrity in our little scene is using javascript.

I bet that Mr. Fowler doesn't have to program in that crappy, quirky, horrible 9nth circle of hell language.

Sorry for the rant but this had to come out.

Re: Announcing the Second Edition of “Refactoring”

#57

Post by edem »

neves wrote: post #20

The Refactoring book in Javascript looks like an early April, 1st joke :-) What I really miss is the integration with the automatic refactoring tools in our IDEs. How would I make a heavy refactoring if I already have a "extract method" in my interface? Would it be the same? Some of the refactorings are easier to automate so are more common in the IDEs. Would are better paths considering what is automated?

I honestly hoped that this was an April fool's joke.

Re: Announcing the Second Edition of “Refactoring”

#58

Post by edem »

dgreensp wrote: post #23
Karunamon wrote: post #21

Earlier quoted context omitted.

I'm asking this from a position of massive ignorance (I'm mostly a backend dev who does the occasional website), but is there any type hinting tooling in the Javascript ecosystem? Python has PEP484 where you annotate types in either comments or docstrings, Ruby has YARD tags used similarly, and smart IDEs can pick up on these and offer decent refactoring tools. But does anything similar exist in JS land?

TypeScript is fast becoming the go-to language for JavaScript with types.

They still didn't manage to put together a usable language. Just try to import your `Foo` class into `Bar` and your `Bar` class into `Foo`. BOOM! It will explode into your face. And this is just a basic thing which should work in a real language.

Re: Announcing the Second Edition of “Refactoring”

#59

Post by simonlc »

edem wrote: post #56

Am I the only one who thinks that using javascript is a terrible, horrible, no-go decision? He could have chosen Python which is also one of the top languages and it does not have the quirks of javascript. I can't help but feel that he only chose this language because this is the language which will net him the most ROI. And we'll take the collateral damage which is an influx of people who will wave his book and say…

I'm curious as to what you believe are the "quirks of javascript" and if you think there are any more reasons as to why it's a "crappy, quirky, horrible 9nth circle of hell language"?

Thanks.

Re: Announcing the Second Edition of “Refactoring”

#60

Post by edem »

simonlc wrote: post #59
edem wrote: post #56

Am I the only one who thinks that using javascript is a terrible, horrible, no-go decision? He could have chosen Python which is also one of the top languages and it does not have the quirks of javascript. I can't help but feel that he only chose this language because this is the language which will net him the most ROI. And we'll take the collateral damage which is an influx of people who will wave his book and say…

I'm curious as to what you believe are the "quirks of javascript" and if you think there are any more reasons as to why it's a "crappy, quirky, horrible 9nth circle of hell language"? Thanks.

Just google it. There is not enough space here to list them all.
Post reply on HN