I love this book, it teaches me not just about refactoring but also about testing and effective software engineering as a whole. Thank you from Vietnam, Mr. Martin Fowler.
Thank you Martin, Carter, and Nathan for this enlightening discussion! The historical context here was completely new to me. I have two questions after listening to the podcast. I hope here is a good place to ask: - Martin explains the changing requirements as one of the reasons for the importance of refactoring as a practice. I get the argument intuitively, but somehow the logic doesn't feel right. After all, the point of refactoring is to change the internals without changing the external behaviour, right? So how come it's a solution for keeping up with changing requirements? - The argument that software requires changes over its lifetime, unlike other forms of engineering, appears in multiple books (The Pragmatic Programmer, for example). But the arguments why other forms of engineering do not benefit from gradual change over time are usually weak. In the podcast Martin says it's because software interfaces with human processes and human processes tends to evolve. But other forms of engineering also interface with human processes. For example, buildings are meant for people to live in, work in, etc. Isn't the main reason software requirements change is just because it's easier? I know these are a bit high level and philosophical. I would very much appreciate to hear your thoughts on these points. BTW, I didn't read the book, but it's on my reading list. If the answers to these questions are in the book just say so and I will look them up. Thank you again 🙏
57:08 that’s why I like stack overflow answers that get updated over the years… so they hold their relevance into the future. I think blog posts and other long form written content could do the same. We don’t need to stop improving blog posts just because they are published. They can be improved and revised over time.
Martin Fowler changed my outlook on software programming 20 years ago. Another person who did it for me is Eric Evans with DDD. Hope you guys do an episode with him to pick his brain.
Regarding the idea that many people don't understand what refactoring is: A great video demonstrating refactoring: th-cam.com/video/aWiwDdx_rdo/w-d-xo.html A 6-minute video I made: th-cam.com/video/vrlY_ZzaHSY/w-d-xo.html
this guy caused more damage then anything else in software. he has no clue wtf hes talking about. his biggest programm is something that sort his emails. so much bad advice. OOP and all this bullshit. fowler and uncle bob. worst persons in coding!
I love this book, it teaches me not just about refactoring but also about testing and effective software engineering as a whole. Thank you from Vietnam, Mr. Martin Fowler.
Lovely podcast and very insightful. Please keep going, we need more podcasts like this. Well done guys!!! Thank you so much
OMG look at those speakers on Martin's table!
Thank you Martin, Carter, and Nathan for this enlightening discussion! The historical context here was completely new to me. I have two questions after listening to the podcast. I hope here is a good place to ask:
- Martin explains the changing requirements as one of the reasons for the importance of refactoring as a practice. I get the argument intuitively, but somehow the logic doesn't feel right. After all, the point of refactoring is to change the internals without changing the external behaviour, right? So how come it's a solution for keeping up with changing requirements?
- The argument that software requires changes over its lifetime, unlike other forms of engineering, appears in multiple books (The Pragmatic Programmer, for example). But the arguments why other forms of engineering do not benefit from gradual change over time are usually weak. In the podcast Martin says it's because software interfaces with human processes and human processes tends to evolve. But other forms of engineering also interface with human processes. For example, buildings are meant for people to live in, work in, etc. Isn't the main reason software requirements change is just because it's easier?
I know these are a bit high level and philosophical. I would very much appreciate to hear your thoughts on these points.
BTW, I didn't read the book, but it's on my reading list. If the answers to these questions are in the book just say so and I will look them up.
Thank you again 🙏
Wow! One of the best books I've read! This is a gem!
First thing I've noticed apart from Martin: the speakers.. exactly the ones I had with my very first PC, Pentium 166MHz.
just ordered this book...it's been on my todo list for a while
57:08 that’s why I like stack overflow answers that get updated over the years… so they hold their relevance into the future. I think blog posts and other long form written content could do the same. We don’t need to stop improving blog posts just because they are published. They can be improved and revised over time.
Great work, thx for sharing it.
Those speakers are from the first edition of Refactoring
Martin Fowler changed my outlook on software programming 20 years ago. Another person who did it for me is Eric Evans with DDD. Hope you guys do an episode with him to pick his brain.
Thanks for this :)
Such a good story!
Sensible Practices 🎉🎉🎉
Wow, we have a new interviewer.
Always a pleasure hearing from the originator of the term "semantic diffusion". Keep blogging, MF!
Regarding the idea that many people don't understand what refactoring is:
A great video demonstrating refactoring: th-cam.com/video/aWiwDdx_rdo/w-d-xo.html
A 6-minute video I made: th-cam.com/video/vrlY_ZzaHSY/w-d-xo.html
Is the main takeaway from the book that unit tests will help you refactor? Is it worth reading the entire book?
That’s the main idea, along with a lot of advice on how to refactor safely and efficiently. It’s definitely worth the whole read!
And small steps of changes where each step DOES NOT break the code
difficult to refactor poor architectural decisions
this guy caused more damage then anything else in software. he has no clue wtf hes talking about. his biggest programm is something that sort his emails. so much bad advice. OOP and all this bullshit. fowler and uncle bob. worst persons in coding!
great episode! do we have some forum(facebook/discord?) to talk about it the book as well?