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

21–30 of 61 posts

Re: Announcing the Second Edition of “Refactoring”

#21

Post by Karunamon »

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'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?

Re: Announcing the Second Edition of “Refactoring”

#23

Post by dgreensp »

Karunamon wrote: post #21
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'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.

Re: Announcing the Second Edition of “Refactoring”

#24

Post by avarun »

Karunamon wrote: post #21
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'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?

Flow does this very well. https://flow.org/

Re: Announcing the Second Edition of “Refactoring”

#25

Post by jmsaucier »

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.

I will second this. I've seen some people choose FB's Flow as their type checker, but for me, I'm loving Typescript. It has minor problems when it has to use DefinitelyTyped and integrate with other frameworks, but those are minor in comparison to not having it.

Re: Announcing the Second Edition of “Refactoring”

#26

Post by jmsaucier »

saryant wrote: post #19
jacobkg wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: Announcing the Second Edition of “Refactoring”

#28

Post by vonseel »

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?

Seems like JavaScript would make sense since there are so many young, inexperienced js developers that stand to potentially benefit from such a book.

Re: Announcing the Second Edition of “Refactoring”

#29

Post by solipsism »

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.

Re: Announcing the Second Edition of “Refactoring”

#30

Post by pmarin »

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?

The original one in written in RATFOR with no structures/records or recursion which make some of the programs more complicated than they should. It easy to find the two versions on Internet.

They describe the design and implementation of many of the classic unix tools. Nowadays it is posible to learn the same principles by reading the userland source code of BSD or Plan9.

Post reply on HN