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: Increase Connection Timeout

Environment: Elastic Beanstalk - Java with Tomcat Recently, we faced a situation where java-tomcat server was taking more than 60 seconds to process the request. And we were getting Bad Gateway 5xx Errors. For this particular use case, we could not use asynchronous communication protocol such as Queues; And business users were more than happy to wait for requests to complete even if it takes more than a minute. For every request, Classic Load Balancer maintains 2 connections. One connection is from client to load balancer, and another connection from load balancer to ec2-instance. By default, idle timeout of classic load balancer is set to 60 seconds which means it can close connection if data is not sent within 60 seconds. In order to handle requests which takes more than 60 seconds to process, we can edit the idle timeout setting and increase it to any value upto 4000 seconds . However, If we want to handle requests which takes more than 60 seconds to process, then Load Balancer
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