In Continuation of previous post: Refactoring Following is summary of some of the refactoring approaches that I frequently use, and that I keep in mind while doing code reviews. Some of the following guidelines may seem like common sense but it is important to revisit, nonetheless. Moreover, more often than not, you will come across code which faced design decay due to number of reasons and can use some basic refactoring approaches: Extract Functions: Functions should be atomic. Ideally, one function should be doing one task and doing it well. Split functions into smaller functions if it is getting complex to understand Code should look like endless calls of delegation Write small functions with meaningful names such that every function shows its intent. Do not underestimate importance of good names. I am not suggesting not to have comments at all, but before adding comments consider if splitting functions or if giving meaningful names can avoid need of comments. A good name wil
Showing posts from February, 2019
- Other Apps
Like many programming concepts, refactoring is broad concept and for different people it may have different meaning. I am sticking with definition of refactoring presented by Ken in his book . Refactoring can be defined as process of: making code easier to understand making code cheaper to modify adding structure to code, if possible At this point, I would also like to mention what refactoring is not. Refactoring is not optimization . I am sure many of us have been part of debates where engineers were hesitant to add structure to code arguing performance may deteriorate. In my experience, most of the times my own fears related to performance were baseless. Every application is different; however, key is not to speculate but to have performance tests, set the benchmark, refactor code and run performance tests again. Even if performance gets a hit, you might find it easier to optimize now that code is refactored and hopefully it will be easier to understand and cheaper to modify.