Hacker News Comments on
Refactoring: Improving the Design of Existing Code
Hacker News Stories and CommentsAll the comments and stories posted to Hacker News that reference this book.
I think this is the sort of thing that enters the collective consciousness and then gets generalized, but code smells were originally pretty specific anti-patterns that had specific fixes. All from this book if I recall correctly
There's always the classics:
EDIT: And it appears the website is a direct rip-off of these books.
⬐ wbillingsleySo much so, and for so long, that I'd always assumed it was authorised. It seems not.⬐ icholyFWIW I already have both of those.⬐ petecox"Refactoring to Patterns"
For a professional programer, if Beck is deemed "unsuccessful", I don't know who among us you will call successful.
If you are a professional programer in 2016, you very likely are familiar with the term "refactoring". This term was placed in our vernacular by the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler . In the Preface to the book, Folwer writes:You might also have heard of xUnit style of testing. Beck had a hand in many of these frameworks.
Once upon a time, a consultant made a visit to a development project. The consultant looked at some of the code that had been written; there was a class hierarchy .. ... I must admit to some bias here. I was that consultant. Six months later the project failed, in large part because the code was too complex to debug or to tune to acceptable performance. The consultant Kent Beck was brought in to restart the project, an exercise that involved rewriting almost the whole system from scratch. He did several things differently, but one of the most important was to insist on continuous cleaning up of the code using refactoring. The success of this project, and role refactoring played in this success, is what inspired me to write this book, so that I could pass on the knowledge that Kent and others have learned in using refactoring to improve the quality of software. ... In this book I describe the fruit of a lot of research done by others. The last chapters are guest chapters by some of these people. .... I've left the final word, Chapter 15, to the master of the art, Kent Beck.
TL;DR - pay heed to the history of your profession.
⬐ trevynThis sort of demonstrates my point perfectly -- if you look at the most successful people in the world, what percentage would you classify as a "programmer"? And of those, how many are actively programming?
TL;DR - If you want to be in the top tier of success, don't take advice from programmers.⬐ swalshActually, come to think of it, 2/3'ds of the successful people I know are actually formally trained accountants who have people skills. Although I think accounting and programming have a similar mindset. If those same people were 20-30 years younger, they might be programmers today.⬐ emodendroketWhat if you don't necessarily want to be "in the top tier of success" but just want to be a successful programmer? Come on.⬐ nostrademonsAmong my most successful people, about 80%. Counting only those who are actively programming it drops to around 50%.
It's easy to forget that the definition of success is relative. Someone you consider a success might be considered a miserable failure in life by others.
I disagree with the premise that organizing code is not a recognized or appreciated skill among developers.
At least not since this was published:
Martin Fowler really struck a chord all the developers trying to do the right thing by cleaning up badly structured code, by giving the practice a name and explaining why it's important. Refactoring is definitely a widely acknowledged and accepted practice today, although probably more so in some communities than others.
> what we in the old days called "rewriting", before the hipsters made it cool
Calling it refactoring dates back to at least the early 90s, which I'm pretty sure predates "hipster hackers." If anyone "made it cool" it was probably Martin Fowler.
"Refactoring: Improving the Design of Existing Code" http://www.amazon.com/Refactoring-Improving-Design-Existing-...
Note I said -refactor-, not -rewrite-. I am not a fan of rewriting apps: developers always underestimate the complexity involved, and then business rules change along the way, and it's just a mess.
Refactoring is when you rework a specific section of code, usually that you're about to work on, or just worked on, to be cleaner. It's a long-term approach, and it's how large applications stay maintainable over the long term. For your specific example, you'd leave your app alone. You wouldn't rewrite it, or touch it, until you find a bug, or need to add a new feature, and then you'd rework anything you need to to add the feature cleanly.
On a related note, Refactoring by Martin Fowler is a great book, and I'd recommend everybody pick up a copy. It's a beautiful hardcover and looks great on a shelf, too.
As the link by lttlrck also advocates: throwing shit out can easily be a mistake. More usually, http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea... + http://www.amazon.com/Refactoring-Improving-Design-Existing-... can get you further, faster. Stuff keeps working while you incrementally improve it.
You'll want these:
Read it. Learn it. Love it. Make it a habit that is so ingrained you do it automatically.
Extract method: do it reflexively.
> Perhaps you could name this mysterious IDE
Is it just you, or does everyone using eclipse take "what eclipse does" to be refactoring?
I didn't mention IDE even once. A small part of refactoring can be done by eclipse. Rest of it is to be done by the programmer.
I am not a Fowlerian, but this is the only reference I could find. http://www.refactoring.com/catalog/index.html
Eclipse helps with a small subset - rest has to be done by the programmer. And most of it is easier to do in Ruby than in Java.
Compare the ruby edition http://www.amazon.com/Refactoring-Ruby-Edition-Jay-Fields/dp... to the java edition http://www.amazon.com/Refactoring-Improving-Design-Existing-...
On an average, ruby code ends up easier to modify and concise.
Anyone have recommendations about the linked book?
Refactoring: Improving the Design of Existing Code http://www.amazon.com/Refactoring-Improving-Design-Existing-...
⬐ sigpwnedThat book changed the way I look at programming. For me, it was the first book I found that actually answered questions that I didn't have the vocabulary to ask yet, rather than just talking around them.
Disclaimer: I'm the author of the post, so that's not actually a different recommendation, just a more elaborate one. :)⬐ marcusfIt's one of the classics of our trade; Even if you know everything there is to know about refactoring you should really read it just to have read it. So consider that my recommendation :)⬐ rhizomeRefuctoring: http://www.waterfall2006.com/Refuctoring.pdf⬐ greenyodaAnother book on refactoring that I'd highly recommend is "Working Effectively with Legacy Code" by Michael Feathers. This book gives you lots of practical hints about how to start refactoring a large, messy code-base. While the task may seem overwhelming at first, you can start by getting small chunks of the code refactored and testable.⬐ bostonvaulter2Wow, you got me there. "Working Effectively with Legacy Code" would be even more directly in-line with what I'm looking for. Way too much Java EE stuff in the code base I'm working with right now.
In my view it is the single most important programming book in existence. Yes, other books will teach you other, incredibly important things. Other books will teach you the specifics of one technology or another. Other books will open up your mind on the very nature of programming (especially learning functional programming). And other books will teach you all of the incredibly important stuff that isn't siting at a keyboard and typing in code. But personally I'd rather work with someone who thoroughly groks refactoring even over someone who thoroughly groks functional programming.
I think the best introduction to object oriented design is shown in the first chapter of Martin Fowler's book "Refactoring". He gives the example of a DVD rental shop that has to calculate the rental fee based on the type of DVD: - A New Release is $3 per day - A Children's DVD is $1.50 for three days, then $1.50 per day after that - A Standard DVD is $2 for two days, then $1.50 per day after that
⬐ jrockwayThe rest of that book, unfortunately, is stuff like: "To move code from one file to another, follow these simple steps. Step 1: Delete the code from the source file. Step 2: Add that code to the destination file. Step 3: Update references to the code in (1) to point to (2). Step 4: Recompile your project and fix the parts that don't compile."
The only way to learn how to program is to just do it. Pick a language. Start with small programs. Learn the features and syntax of the language. When you feel you know the language well enough to write a program that uses most of its features, then pick an open source program and learn its code. Make some modifications to it. When you feel you're pretty comfortable in one language, pick a new language.
Rinse repeat. You'll find that once you have one language down, the process will go much faster with the second. The features and syntax of most languages are pretty similar.
You can pick any language you like to start with, but personally I'd recommend starting with a hard typed compiled language rather than a dynamic language. Dynamic languages are easy to learn, but its easy to be a lazy and bad programmer in them. They let you get away with too much. Hard typed compiled languages are a) much better at catching your errors and b) much harder to be a lazy programmer in. They don't let you get away with things nearly as much.
I'd recommend Java, seems to be the language a lot of people start with. It will also give you a good founding in open source programming. I started with C/C++ and I'm glad I did. But that was more of a challenge - had to learn pointers and memory management in my first language. And after that I took a little while to learn the open source mindset, since I'd started in a procedural language.
Once you have a good grasp of an object oriented language like Java (or Python) and what object oriented programming means, then I'd recommend reading the Gang of Four book on Design Patterns (http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...) and Martin Fowler's book on Refactoring (http://www.amazon.com/Refactoring-Improving-Design-Existing-...). Those will give you a pretty good basis in software design and maintenance.
In terms of recommended reading for learning a language, the O'Reilly books are nearly always good in my experience. Here's one for Java (Learning Java: http://www.amazon.com/Learning-Java-Patrick-Niemeyer/dp/0596...) and here's one for Python (Learning Python: http://www.amazon.com/Learning-Python-Powerful-Object-Orient...)
⬐ Female-hackerAmazing. No Google search led me to an answer this helpful. Thank you for your input on languages also...it seems there is quite a debate between Java and Python.⬐ SkyMarshalI disagree with starting with Java. Rather I second coffeemug's advice in the following comment, focus on C, Lisp, and Haskell:
My first manager taught me something college had failed to (or that I failed to learn there), which is that programming languages come and go in trends, but they are all based on recurring fundamental concepts, which endure beyond any single language.
Most new programming languages are a remix or mashup of some or all of these concepts, so if you master those concepts you'll be able to easily pick up any other language.
It's like learning Latin as your first foreign language, and being able to quickly pick up any Latin-based language after that. C, Lisp, and Haskell are the Latin of the CS world.
Since you're at MIT, take the famous Structure & Interpretation of Computer Programs (used to be 6.001, not sure if it still is). http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussma.... That'll get you started with Lisp (specifically the Scheme dialect).
For C, start with K&R (http://en.wikipedia.org/wiki/The_C_Programming_Language_(boo...).
For Haskell, Real World Haskell is good, and the e-version is free. (http://book.realworldhaskell.org/)
Joel Spolsky has an article worth reading on why not Java:
And of course PG's essays on Lisp are a must read:
Since it sounds like you're running a business you may feel pressured to learn Java or whatever your coders are currently using to get your business off the ground. But I heartily recommend resisting that pressure, doing it right, and mastering the enduring fundamentals first. It may cost you something in immediacy and expedience, but that's what school is for, especially one such as MIT. You should carefully weigh how you spend your time there, and unless you think you've got the next Facebook, focus on mastering the enduring concepts, not the trends. You'll be glad you did the rest of your life and career.
PS - there's little to nothing that Clojure (a Lisp dialect on the JVM) and Haskell can't do in the web space, so the cost in immediacy and expedience is slim to none anyway.
PPS - it didn't register till just now that you're an Econ Major not going into CS or Software Engineering as a career. If you just want a tried-and-true, versatile, easy-to-get-started-with language with tons of libraries and frameworks (reusable code) to hack in, huge and helpful community go with Python. Java is too bureaucratic a language for this purpose.
Start with Zed Shaw's excellent introduction, Learn Python the Hard Way (hard way = by doing lots of follow-along examples until it gets into your brain muscle memory), then go from there.⬐ dbinghamPython's a good language, but it's a soft-typed interpreted language. Which means it will let you get away with certain things.
It also tends to have really hard core adherents who will swear by it above and over anything else, which is why there is something of a debate. It really doesn't matter that much what language you start with.
One of the keys to being a good programmer is knowing your toolbox. And that includes knowing multiple languages. The best programmers don't have one favorite language. Rather they have a toolbox of a half a dozen or more, and they pick the best language for the task at hand.⬐ Adam503"...it will let you get away with certain things..."
...like reading what she just typed in? Yes. Python will let her "get away" with reading her code. ;-)
Here's a link to the Beginners Guide to Python...
I cannot stress this enough: learn refactoring, http://www.amazon.com/Refactoring-Improving-Design-Existing-...
You will simultaneously learn:
- terminology and models relevant to software design and construction at every level
- principles of good coding and how to tell good code from bad
- the ability to redesign code as needed
- the experience and knowledge necessary to approach coding with confidence
All of these are the most critical tools you need to transform yourself from someone who sorta-kinda knows a few principles of coding to someone who groks software construction.
If I had to choose between a co-worker who truly groked the principles of re-factoring and a co-worker who had a PhD in Computer Science I would choose the former every time. It's really that important.
⬐ jngI don't think that's good advice for a newbie.
To the OP: practice, practice and practice. It will take a long time. Months to start getting it, years to go anywhere. 10+ years to be good. If it's too hard, choose another profession. 99% of folks out there would hate programming.⬐ InclinedPlaneI could not disagree more, refactoring is perfect for a newbie. It's not an advanced technique, it's fundamentals. Any beginner who can write a method can extract a method.
But more than that, refactoring provides the mental models and the vocabulary to talk about, reason about, and understand code. It provides well-worn expert advice about the characteristics that make good code good and bad code bad, heuristics to be able to recognize good and bad code, and basic techniques to transform bad good into good safely and effectively.
There may be some advanced techniques in the book itself which won't be useful to beginners, but that's true of any programming book, and that's easy enough to skip over and return to later (especially with the organization of the canonical refactoring book specifically).
A beginning programmer who has learned even the simplest of refactoring techniques (extract method, insert/remove cached value, etc.) will be able to look at a piece of code and see the ways it can be changed, and will also have a reasonable idea about which changes are more likely to improve the code. They will also have the mental models and vocabulary to talk about, reason about, and understand the code, even if only to themselves. These tools are hugely important for beginners. They can transform coding from a task filled with uncertainty, fear, and irregular advancement born from experimentation to a task filled with confidence, knowledge, and curiosity.
Certainly practice a lot, but don't just blindly stumble about on your own, there's lots of good material out there, learn the techniques and then practice applying them, build up your toolkit a bit at a time until you feel more and more comfortable with coding.
Some books to read:
Consider buying these books:
Also, check out this refactoring book:
⬐ juwothanks. I notice though it may be a bit dated - 1999.