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 4.        You have successfully launched an ec2 instance in VPC and have also downloaded the Private key which you will use to access instance via SSH. What else do you need to do to access the instance? a)        Add
Read more

AWS Parameter Store

A typical web application needs credentials to access different resources such as credentials to connect to database and tokens to communicate with other web services. It is common practice to pass these secret parameters to applications via system properties or environment variables. For example, if you are using Elastic Beanstalk for java web application then you can pass parameters (database url, username, password etc.) as properties.  Every infrastructure is different, but in general this practice is neither secure nor manageable. Some of the common problems are: parameters are not encrypted, parameters might be available in plain text on ec2-instance ebs scripts, parameters are hard to rotate if parameters are being shared by multiple applications. Moreover, if credentials are shared by different applications and multiple people are responsible for deployment then all those people will need access to credentials. Instead of passing secret parameters as environment variab
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 t
Read more