Refactoring

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. Moreover, adding compute cycles will be far cheaper than adding extra development hours when making changes to poorly structured code.

When to Perform Refactoring:
Many of us may follow common advice of ‘don’t fix what’s not broken’ religiously. Software engineers have a profound liking to it. If you are working on code which can use refactoring, and you are certain that no enhancement requests will be coming in future, then it might make sense to leave code as it is. However, this rarely happens. Most of the times we are working on applications for which change requests are inevitable. For such applications, best time to refactor is when you are working on code adding new features or fixing existing bugs. This is the time to refactor, to change variable names, reduce parameter list, add structure to code, remove duplicate code and so on. Do not leave Refactoring to be performed as a separate activity at a different time. Obviously, test your changes using test cases while you are at it. If there is any part of code, which took you more than expected time to understand then this chunk of code might be good candidate for refactoring. Once you understand it, move your understanding from your head back to code by refactoring it. Your future self and other developers will thank you.

In the next post, I will be summarizing some of refactoring steps that I frequently use and which I keep in mind while doing code reviews.

References:
This post is heavily inspired from book Refactoring: Improving Design of Existing code.

Comments

Post a Comment

Popular posts from this blog

Practice Questions - AWS Solutions Architect - Associate Certification

These are some of the practice questions from the e-book which is available on Amazon:
1.Name of S3bucket must be unique: a)Within your AWS Account b)Across all your AWS Accounts c)Within a region d)Globally across all AWS Accounts
2.Which of following can be used as storage class for S3: (Select all that apply) a)S3 - Standard Infrequent b)Amazon Glacier c)Storage Gateway d)EBS e)Dynamo DB
3.S3 replicates all objects: a)On multiple devices within availability zone b)In multiple availability zones within a region c)Across multiple regions to achieve higher durability and availability d)On a single device
Read more

Continuous Integration using AWS CodePipeline (GitHub to Elastic BeanStalk)

AWS CodePipeline can be used to continuously deploy code changes to Elastic Beanstalk in Staging Environment. Here is an example which makes use of amazon web services to deploy code changes for Grails Project. CodePipeline will get code from GitHub repository, build using CodeBuild and then deploy the war file to Elastic Beanstalk. AWS CodeBuild uses buildspec.yml to get build instructions. Add buildspec.yml at root folder of your project. Since Grails uses gradle to build the project, the content of file can be: version: 0.1 phases: install: commands: - echo Install started on `date` pre_build: commands: - echo Pre Build started on `date` build: commands: - echo Build started on `date` - ./gradlew assemble post_build: commands: - echo Build completed on `date` artifacts: files: - build/libs/*.war The root folder should also contain gradle wrapper (gradlew). We won't have to install gradle on build server …
Read more

AWS Cross-Account RDS Backups

It is hard to deny importance of cross-region copies of RDS snapshots. Recovery will be a very difficult process, if not entirely impossible, in case of a disaster as small as un-availability of AWS region. However, even cross-region copies of backups are not sufficient. What if AWS Account credentials gets compromised? Or some employee goes rogue and deletes snapshots? These scenarios are not unheard of [1]. In any case, it is good idea to have off-site backups. Backup is not a backup if it is not in a completely separate location. Over AWS, these off-site backups can be snapshots stored in entirely different AWS Account. Unfortunately, AWS does not have service which you can use to create and store backups in different account. But it is trivial to set it up yourself using scripts or Lambdas. Creating manual snapshots and saving these snapshots in completely different AWS account will ensure data recovery in majority of disaster scenarios. And this process can be automated easily u…
Read more