• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Five Lines of Code: How does this compare to Refactoring, 2nd Ed?

 
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Christian,

Thanks for hanging out with us this week and answering questions about your new book. How much overlap does this have with Martin Fowler's "Refactoring, 2nd Edition"? Are there techniques you discuss in more detail or that were left out of Fowler's book? What would you say is the main difference between FLoC and Refactoring, 2E?

Thanks!
 
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Junilu,

Thanks for your question.

I must admit I have not gotten around to really study the 2nd edition, so take this with a large grain of salt. I view my book as a good stepping stone towards Fowler's book, not as a replacement.

First, he presents many more patterns, which I have found to be overwhelming for some, especially because they are not put in a larger context. These are exactly the points I try to address by having part 1 be one big example introducing all the refactorings and smells in the book as we encounter them in a life-like scenario. Fowler has the same type of example, but only in one chapter.

Second, in his book, he uses JavaScript which is an untyped language thereby greatly increasing the need for automated tests, as there is no other safety net, and while I am a big fan of testing I find that learning both refactoring and automated testing at the same time greatly increases the complexity.

Third, he introduces and explains code smells, and although these are great, I have found most inexperienced refactorers to struggle with them. Smells are fluffy and abstract. When I was teaching I would get questions like "when is a method too long", and this is a great question, especially because programmers are used to working with quantifiable data. My rules are designed to be concrete, and to be easily spotted and applied, while a programmer subconsciously builds intuition towards code smells.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I get your approach and I've seen the kind of barriers to entry that you mention. I often do an exercise based on the Compose Method refactoring example given by Joshua Kerievsky in his book "Refactoring to Patterns" and it's very revealing how many programmers just don't have a keen sense of smell for things that reduce readability. However, my experience is that once you explain smells like Arrow Code, duplication, and violations of SLAP, even newbies are quick to develop a nose for them.

I'd love to give your book a whirl as a reference in a workshop or course on refactoring. I'm sure there are many lessons we could learn from observing how people consume the book's content.
 
Junilu Lacar
Marshal
Posts: 15877
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Christian Clausen wrote:
Smells are fluffy and abstract. When I was teaching I would get questions like "when is a method too long", and this is a great question, especially because programmers are used to working with quantifiable data.


I probably get ahead of that question with the way I present material on refactoring. I usually tell my audiences about 5 lines of code is a good goal for "small" methods with the caveat that it takes a lot of time and practice to get down to that level. I go a lot easier on beginners, telling them to try for 30 lines, then bring it down to 20, then 15, then 10 lines. When I was learning, it seems like going down from 30 to 15 took a lot more effort to master than it did going down from 10 to 5. I wish I had taken notes though or just committed more of my work to version control.

BTW, do you talk about those kind of details in your book, using version control so you can go back over the history and study your "moves" like how athletes study film of themselves?
 
Christian Clausen
Author
Posts: 31
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I only mention version control briefly in the book. I think it is an amazing tool, and am actively trying to use it as much as possible in my own work. However, in the interest of not overloading or distracting the reader, I don't go into any technical Git. I was nervous even writing about "diff" because I don't want to teach Git in this book. I strive to keep my message as clean as possible

I do write about Git on my blog though, including recommending doing an interactive rebase before delivering, so the history reflects the story you want it to.
 
    Bookmark Topic Watch Topic
  • New Topic