In this webinar we’ve talked about general strategies and effective refactoring process, all of it using and explaining CLion’s refactoring capabilities.
Useful links and further reading:
- Demo project can be taken from GitHub.
- “Refactoring to Patterns” by Joshua Kerievsky
- “Refactoring” by Martin Fowler
The video includes the time stamps:
00:10 – Sample project description and overall structure
01:55 – Extract function and remove duplicates
07:44 – Parallel change strategy (sample 1: movie structure)
16:20 – Parallel chance strategy (sample 2: rental structure)
24:00 – Extracting domain logic into a separate class: extract frequentRenterPoints to the class
29:00 – First round of Q&A
36:00 – Duplicate and reduce technique
48:42 – Second round of Q&A
Q: Could you please share some links for further reading on the topic and the strategies you’ve mentioned?
A: References where these names come from are (among others): The book “Refactoring to Patterns” by Joshua Kerievsky, “Refactoring” by Martin Fowler – see also his website, e.g. for Parallel Change.
Q: Don’t you violate the Single Responsibility Principle by just making
movie a struct and keeping related behaviour in the main app?
A: Yes and no. There is no actual
movie related behaviour. And I’m not done with all the refactoring steps for now. Input in the
movieData variable could be treated as
movie related, but can be also seen as just an Input. Besides, it will later be refactored into
Q: Why to use Inline and not simply keep functions separated?
A: I’ve inlined free functions as they are a part of the class logic. It actually happens quite often when you refactor something, move it around and then inline, and all this for the goal of moving a bunch of lines to another place.
Q: What to do if we don’t have tests on the project and so can’t check the changes introduced by refactorings easily?
A: That’s a difficult question. As Bjarne Stroustrup says, if you haven’t tested your application, it doesn’t work, as you can’t say it works. So the first step is to get tests. That’s a prerequisite for any refactoring because, if you don’t have tests to make sure you don’t break anything, don’t touch it. So the tests are really essential for this kind of work.
Q: How do you approach program logic? How do you analyse program so you can split program into classes and functions?
A: If we talk about the program logic, we often have names that are part of our domain (business) language. Usually I try to go into the direction of domain driven design. If I have a name like
movie, these are indications that we need classes for these different concepts. And usually we see quickly that there is logic that belongs to these concepts as well.
About the presenter:
Arne has been an enterprise C++ developer for almost a decade. Due to his involvement in large legacy projects in the insurance market, he has developed an interest in software craftmanship topics. Since the beginning of 2015 he blogs frequently about modern C++, clean code and related topics. Arne works at Zühlke Engineering, currently dipping his toes into the world of C++ on embedded devices.
- Blog: Simplify C++
- ACCU 2017 talk: Learning (and teaching) modern C++ – Challenges and Resources
- Twitter: @arne_mertz
More info on refactorings in CLion is here.
The CLion Team