Refactoring Go Programs

Guidelines and techniques for evolving your code.

Overview

• What is refactoring?
• Why do we refactor?
• Techniques for refactoring
• Obstacles
• The future

What is refactoring?

• Restructuring code while maintaining invariants.
• ... more or less.
• Every case is different.
• ... but common patterns emerge.

Small scale

• Most common form.
• Making a change to one thing
• Local changes only
• Almost always manual

Large scale

• Sweeping changes across lots of code
• The more automatic the better!
• Automatic changes can be re-applied easily

Experience

• I currently work on a code base that's about 2 million lines of Go.
• All of it has been written since I joined the company.
• Lots of refactoring!
• Go really helps.

Why do we refactor?

• Keep the code base looking decent as we add features.
• Ideally "Code should look as if it was designed that way from the start."
• Changing requirements.
• Maintaining consistency.
• Improving performance.

Examples

• Renaming
• Argument shuffling
• Method ↔ function
• Extract code into function
• Extract fields into new type
• Make a loop concurrent.
• Moving a package.

Go advantage

• Identifiers in Go code are unambiguous
• Compiler checks a lot!
• Tests are standard.

Renaming a function

func foo(x int) {
}

renaming to:

func bar(x int) {
}

• Easy, you might think, but what about...

Renaming a function

• ... this?

func Foo(x int) {
}

renaming to:

func Bar(x int) {
}

• It's exported!
• Who's calling it?

Renaming a function

• Run the compiler!
• But doesn't help with public code.
• Backward compatibility guarantees.
• That's another talk!

Leverage the compiler

• Make the compiler complain!
• Change a type when semantics change.

Factor functions into methods.

• You want to add some context to a bunch of functions.
• You could add another argument to all of them.
• Or make a new type and all the functions into methods on it.

func x(i int) string {
    return y("something", i)
}
func y(s string, n int) string {
    return s + strings.Repeat("foo", i))
}

->

type repeater struct {
    count int
}
func (r *repeater) x(i int) string {
    r.count++
    return y("something", i)
}
func (r *repeater) y(i int, s string) string {
    r.count++
    return s + strings.Repeat("foo", i))
}

Factor methods into functions

• Sometimes useful to make a method generic over an interface.
• A good reason to avoid "self" as receiver parameter name.

func x(i int, c counter) string {
    c.inc()
    return y(i, c)
}

Tools for bulk code change (1)

• gofmt -r

gofmt -w -r 'Foo(x, y) -> Foo(x, y, nil)' .

• Rewrite one expression to another.
• Single letters are wild-cards.
• No sensitivity to types.

Tools for bulk code change (2)

• sed -i

• Non-interactive regexp-based change.

Tools for bulk code change (3)

• sam -d

sam -d *.go

• My fave!
• Structural regular expressions.
• Interactive, command-line or GUI based.
• Repeated subdivision, across multiple lines.

doc.cat-v.org/bell_labs/sam_lang_tutorial/sam_tut.pdf

man.cat-v.org/plan_9/1/sam

Tools for bulk code change (3)

• govers

govers -m github.com/foo/bar github.com/me/bar

• Custom tool for changing import paths.
• Designed for versioned package paths
• ... but works well with other packages.
• Checks that dependencies are using the correct package too.

Tools for bulk code change (4)

• Alan Donovan's tools:
• gorename, gomvpkg
• Amazing tech but I haven't found them useful yet.

Tools for bulk code change (5)

• Custom code
• Easy to read Go code, change it, write it again.
• Gofix was crucial tool in early Go evolution.
• Not too hard to customise yourself.

e.g.

if err := foo(bar); err != io.EOF {
    return err
}

->

if err := foo(bar); errgo.Cause(err) != io.EOF {
    return errgo.Mask(err)
}

Obstacles

• Reflection
• Tests
• Inconsistency
• Excess interfaces

Reflection

• Reflection can access fields and methods at runtime
• But not functions or types!
• Watch out for serialisation compatibility.

Tests

• Tests are crucial.
• But they're also a liability.
• Internal "unit" tests can be a burden.

Inconsistency

• Consistent things can be changed consistently.
• Try to make things look the same if possible.

Excess interfaces

• Interface types lose direct connection with the code.
• Very useful, but...
• excess use makes code harder to change.
• Also worse for backward compatibility.
• OK to add methods to static type
• ... but not an interface.

The future?

• Type-sensitive "gofmt -r" without strict type checking
• Not restricted to expressions only.

Thank you