Author: Adam Tornhill
Buy: Book Depository
For me the key takeaway from the book was how we can figure out which parts we really need to refactor.
There can be parts in the code which are totally useless to refactor and there can be key areas which are really slowing us down.
The easiest way to figure out the code that needs to be refactored is to use the data stored in our version control system.
Take the most often modified files and order them based on complexity and boom, you have possibly found the culprit.
Maintenance is the most important phase in the software development lifecycle.
Maintenance is a good sign, because only successful applications are maintained.
Our primary task as a developer is not to write code but to understand it.
To get the most out of the redesign you should improve the part of code that is most likely to be worked on in the future.
Complexity is only a problem if we need to deal with it. If no one needs to read or modify a particular part of the code, does it really make a difference if it is complex?
Code that has changed in the past is likely to change again.