Julien Bordellier then proposed making it a library, which would make it much easier to integrate into our micro-service, and was compatible with keeping a user-friendly tool for the current users.

I decided to strip out the features that were initially part of Cameradar in order to fit the internal business needs of the tool but were useless for most users. The thumbnail generation, stream checks and the possibility to connect Cameradar to a database were no longer needed if it became a library. Our internal micro-service or even another tool could now handle this part of the logic, that had nothing to do with the discovery and access of camera streams.

I got to work. I was extremely surprised to have a working library and binary after only 2 and a half hours of work, despite my very basic knowledge of Go! There were bugs around and improvements to be done, but it was discovering and accessing cameras successfully. The binary basically replaces the old application and also provides an example of how to use the library’s features.

A few statistics of the code base at that time:

Reduced the number of lines of code by 95% // Without the cache management, thumbnails, and stream check features

// Without the cache management, thumbnails, and stream check features Reduced the docker image size by 85%

Added unit tests in under 2 hours

Made the CI much simpler and 90% faster

As well as other interesting facts:

Documentation is now automatically generated via godoc

The dependency management provided by glide makes my life easier

The user experience is much better than before thanks to a few awesome libraries

Adding new features to Cameradar has never been so simple and fast

the output of the app is now simple and clean

Of course it would have been possible to code unit tests for the C++ version, and also possible to give it a nice output like showed in the image below, but it would have taken much more maintenance and time than in Go, and in the case of my project it would have been for no benefit at all.

It’s been only a few weeks since the 2.0.0 version is out, but I found again the early excitement I had for working on this project, and many more people are now using it, so I’m really happy about this decision. I can’t wait to refactor the C++ micro-service that I made a year ago using the C++ Cameradar, into a Go micro-service.

I’m not the only one to report such results:

“I have reimplemented a networking project from Scala to Go. Scala code is 6000 lines. Go is about 3000. Even though Go does not have the power of abbreviation, the flexible type system seems to out-run Scala when the programs start getting longer. Hence, Go produces much shorter code asymptotically.” — Petar Maymounko

And not only is it shorter to write than most languages, but it’s also often easier to code and to test:

“I’ve spent more time coding than debugging and it’s so simple, fast and funny…” — Roberto Costumero

A final argument that made this code refactoring worthwhile in my opinion, is that the Go community has been very supportive and is actively encouraging people of every level to contribute, which is wonderful for a beginner like me.

To conclude, I would recommend to anyone who struggles to maintain a repository that feels like legacy and is full of technical debt, to give Go a try if it seems to fit your needs. You’d be surprised by how fast you would see results.