Coding Conundrums: To Code from Scratch or Not?

As developers, we may want to build anything and everything we hear. We will be suspicious of any library or framework. We will be skeptical, if the library has enough Github stars, Are there pending issues?, Is there a good community support? etc. The decision highly depends on the context and the circumstances. But there are some approaches, in this article we will discuss them. Definitely read the last approach which we should never take 😵💫.

Until now, we would have heard from many technologists that everything in software development is tradeoff. If we build it from scratch: the number of iterations to make it working for all the scenarios, the time and effort required will be the major things to consider. But we will have more clarity and better control of the code base.

If we are using an existing library: The community support, future issues and open issues are the major things to consider. But we will be able to know how others in the community have solved the problem and quickly ship the feature.

Different approaches:

It would be better to start using the library, test the scenarios we might be using by creating unit tests. Usually we may take the library for granted and not test. But having tests for the features using the library, will be beneficial in knowing what is working and what is not.

By this we will deliver the features quicker and benefit the business. Later if there are any errors, we can always fix it.

Another approach is to go through the library's code and using the code snippets that are required to complete the feature. This has an advantage of not depending on the library, hence no potential bugs. We will also use only the parts that we require and we can also adapt the code for our requirements.

Yet another approach is to copy the complete library code and paste it in our code base and change some codes in the library to adopt to our requirement. Mind blowing right 🤯? In normal circumstance no one does this. But in time constrained and highly pressurized environment, we might be intrigued to take this approach.

Never in do this. Why? Consider the case where we used an older version of the library, The framework has released a new version. The library will also release a newer version to support the latest framework release. Now comes the twist in the story. Since we had copied the whole library and changed the code for our requirement, our changes and the library code has become indistinguishable. So to upgrade the library we would have to literally, re-implement the feature once again.

Imagine explaining this state to the project manager! 🤭

So what to do in this case?

SOLID principles show us a way: O stands for open for extension and closed for modification. Import the library, extend the class we want and override the functions to match our requirements. By this, there will be a clear separation between our requirements and the library's code base.

Earlier we discussed, on using the library and fixing it if we found an issue, remember? That can be done by fixing bug in the repo, If that is taking more time we can extend and fix the bug or cover for the new scenario in our code base.

Example:

Lets consider we want to log all the requests that is made from our code base.

# Adding logging capabilities to HTTParty for better debugging
gem 'httparty'

require 'httparty'
require 'logger'

# Extending HTTParty with custom logging
class LoggingHTTParty
  include HTTParty
  format :json

  # Initialize the logger
  @@logger = Logger.new($stdout)

  # Custom GET method with logging
  def self.get(url, options = {})
    @@logger.info("Requesting GET #{url} with #{options}")
    response = super(url, options)
    @@logger.info("Received response: #{response.code} - #{response.body}")
    response
  end

  # Custom POST method with logging
  def self.post(url, options = {})
    @@logger.info("Requesting POST #{url} with #{options}")
    response = super(url, options)
    @@logger.info("Received response: #{response.code} - #{response.body}")
    response
  end
end

# Using the extended HTTParty class in your application
response = LoggingHTTParty.get("api_get")
puts response.body  # Logs the GET request and response

response = LoggingHTTParty.post("api_post", { body: { key: 'value' }.to_json })
puts response.body  # Logs the POST request and response        

In some languages this is even considered as Monkey patching. It is similar but not the same.

Conclusion:

Choose an approach considering the context and tradeoffs. Be careful on not violating the license policies when using or copying the code. But never copy the whole code base and adulterate it with your requirement so that it comes back later to give you cardiac arrest 🥶.

Feel free to comment your feedback or other pitfalls you have come across! Share the newsletter, as you may not be able to tell this openly in your team 😝