Category Golang
Programs should be written for people to read, and only incidentally for machines to execute - Abelson and Sussman
It is one of the most popular questions. You can find on the Internet attempts to answer this question. I’ve had concerns if I’m designing my packages or even the whole project correctly. Today, I’m not 100% sure about that!
Some time ago, I had the pleasure to meet Robert Griesemer (one of Go’s authors) in person. We asked him this question: “How to structure Go code?”. He said: “I don’t know.” - It’s not satisfying, I know. When we asked him about how he designs his code Robert said that he always starts with a flat structure and creates packages when he has to. That’s much more concrete.
Some time ago, I found a Stack Overflow question. The author had a problem with understanding why the context from the request he’s using is canceled. I remember that I had a similar situation in the past: I used the context from the HTTP request and tried to use it in background operation and return the response to the user before it was finished. This issue comes from not understanding how the context is used in the http.Server struct. I want to save you from similar surprises. I described it in this article.
You can find a lot of articles about Go that describe general aspects of it. Including the content on this blog. Today, I decided to prepare something different. I’ll tell you about one of my tasks and I’ll show you how I resolved it using Go. I thought it’d be useful to show the exec package and to tell a bit about the ssh command and learn AWS EE2 a bit better.
Writing linters is simple. I was surprised how it’s easy to write a Go linter. Today, we’ll write a linter that will calculate the cyclomatic complexity of the Go code.
What is cyclomatic complexity?
Cyclomatic complexity is a software metric used to indicate the complexity of a program. ref
The idea is simple - every time we find any control flow statements we increase the complexity by one. I know I oversimplified it a bit but I don’t want to overwhelm you with unnecessary details.
In the last article, we wrote a few tests for a project to make sure that our refactoring won’t break anything. To understand the project better, we will separate the part of the domain and add a test to it. This will make the test more authentic.
There is a problem with the end-to-end (e2e) tests: database under the hood. This attitude is not carefree. Firstly, those tests are rather slow. It might be an issue when the number of tests will increase. We use a real database connection that has an overhead.
When we talk about software design we very often use very generic and abstract words. But, how about the practice? How does it look in a real-world project? Today, you and I will start refactoring a small to-do app for better testability and maintainability. In this article, we will make the application testable. We’ll write black-box tests that will prevent from some bugs and make future refactoring easier and safer.
In this article, I explain how you can detect if the interface you’re using is getting too big and requires splitting into smaller ones. Smaller interfaces help to improve the maintenance and readability of the code. What’s more, it helps with understanding the code.
Interfaces in Go are different than those known in Java, c#, PHP etc. In those languages you define interfaces up-front. In other words, at the moment of creating a class you need to know how the class will be used. In Go things are different. You can create a struct with as many functions you want and the user of if can define only a sublist of methods he needs. It’s very powerful tool. But sometimes we still can create too big interfaces. The list above should help you find interface segragation issues in your code.
The context package in Go is quite simple and well-known. On the other hand, there are some misunderstandings while using it. Today, I’ll try to explain all the most popular concerns and make more clear when and how use the Context.
Let’s start with what the context is.
Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes. ref: https://golang.org/pkg/context/
Go has plenty of different web frameworks. When you are faced with choosing a framework for the first time, it may turn out to be quite a challenge to choose the best one. This article is intended to help you choose the best one. It is full of personal judgments that you may disagree with. However, I believe you will find it most helpful.
Martini
The first framework is Martini. Honestly, it shouldn’t be here as it’s been under development since 2017. However, I added it because I found it on other compilations. Just don’t use it :)
In Go, we can refer to variables using value or pointers. Sometimes, it’s hard to answer which approach is more suitable.
At the first place, you should learn about general rules. Value semantic should be used every time when copying the value make sense in the logic of your code. For example, every value object should be passed by value. If you have a struct Money then it’s possible (and also make sense) to have, at the same time, multiple 10$ in your code. There’s no such requirement that only one person can have the same amount of money.