Skip to main content
  1. Posts/

Refactoring Go Safely

··372 words·2 mins
Author
Hairizuan Noorazman
Software engineering experiments, implementation notes, and lessons learned.

An excellent resource to read on Refactoring Golang code safely and to ensure that Golang code continue does not result in breaking changes in the codebase.
https://talks.golang.org/2016/refactor.article

An important to take away from the article is the fact that when making API changes to a code base, the portion that results in largest amount of work is the amount of code repair that needs to be done. Here are some of the examples to take note:

This types of code repair refactors would likely happen in the Golang standard libraries.

  1. Moving constants across packages - part of code repair
    const OldAPIConstant = NewPackage.APIConstant
  2. Moving functions across packages - part of code repair
    // Use OldAPI's signature
    func OldAPI(){
        NewAPI()
    }
  3. Moving vars across packages - part of code repair
    var OldAPIVariable = NewPackage.APIVariable
  4. Moving types across packages - part of code repair
    type OldAPIType = Packagetype.NewAPIType

Here are some additional refactoring notes:

Doing the following adds plenty of extra code to your codebase. If you are sure no one is using the code base - e.g. It’s a private repository and nobody else is actually using the same codebase, then, it might be fine to just add/remove or doing other code edits which might usually cause application breakages.

For some that would require breaking changes etc, one extra step that you can do is to actually add a note about depreciation of some functionality and add some information on why the function or variable is depreciated

  1. Add a new field to a struct safely (Don’t depreciate it yet - adding of new fields might result in unexpected behaviours?)
type Planet struct {
    Name   string  `json:"name"`
    Radius float64 `json:"radius"`
}

type PlanetWithMass struct {
    Planet
    Mass float64 `json:"mass"`
}
  1. Add a new parameter to a function - note (This is for temporary, once it is ok to do a major release, can clean out past versions)
// Test1 is the old function - move code to new function
// Test1WithOwner is the new function

func Test1(name string){
    // fmt.Println(name) - past code - move it to new function or a common function that has been extracted sufficiently.
    Test2(name, "")
}

func Test1WithOwner(name, owner string){
    fmt.Println(name)
    if owner != "" {
        fmt.Println(owner)
    }
}

Related

Trying out skaffold

··497 words·3 mins
When developing application that are meant to be deployed to the Kubernetes platform, it involves a bunch of steps on top of your usual local development work: Writing a Dockerfile to package the application (Multi stage applications are optional here - useful for compiled based languages) Build and tagging the docker image of the application with the target repository Either use kubectl commands or use kubernetes config resource files to define the resources required for deploying the applications. Use those commands/configurations to define the resources on the staging/production application Repeat the process for each update of the application (Repeat second point onwards) As you see from above, it starts to be pain to do so after each iteration of the application development. The building of the docker containers process as well as the applying of the new images to each cluster, (sometimes with slightly changed configuration files) - the kubernetes secret and config files can change across different environments.

Lessons from Gophercon SG

··686 words·4 mins
This is the list of talks provided in the reccent Gophercon Conference held in Singapore on 4th May 2018 Go with Versions Project-driven journey to learning Go Resilency in Distributed Systems Understanding Running Go Program Go for Grab Optimize for Correctness Build your own distributed database The Scandalous Sotry of Dreadful Code Written by the Best of Us Erlang for Go developers Go and the future of offices Reflections on Trusting Trust for Go The lost art of bondage Below are some of the more interesting points raised during the talk (View the full talk to understand the context on what and why a certain point was raised.)

comments powered by Disqus