В статье показано, как в Go реализовать обработку ошибок и логирование по принципу "Сделал и забыл". Способ расчитан на микросервисы на Go, работающие в Docker-контейнере и построенные с соблюдением принципов Clean Architecture.

• Go-разработчиков — тех, кто уже давно сидит на Go, кому интересно обсудить новинки, поговорить о производительности и «кишках», узнать, что меняется в Go, похоливарить о дженериках, например.
• Кроме того, поскольку Go-общество расширяется, мы ждем программистов, которые только-только переходят на Go или даже только подумывают об этом. Покажем им истории успеха, реализовавшегося с переходом на Go, или истории провала. Узнаем, что не получается, почему, какие их первые чувства, мнения, впечатления.
• Третья категория посетителей — пользователи инструментов, написанных на Go. Это популярные в рамках Cloud Native инфраструктур: Kubernetes, Docker, Terraform, Consul и другие продукты Hashicorp. На Go-конференции гости, с одной стороны, узнают, какие у этих инструментов есть проблемы, связанные с особенностями языка, а с другой — увидят, какие в Go есть вызовы и задачи, чтобы начать, например, контрибьютить в эти проекты.

Предлагаю ознакомиться с расшифровкой доклада Дениса Исаева jirfag "Линтеры в Go. Как их готовить."

В go 50+ линтеров: в чем их профит и как эффективно встроить их в процесс разработки? Доклад будет полезен как тем, кто еще не использует линтеры, так и тем, кто уже применяет их: я раскрою малоизвестные трюки и практики работы с линтерами.

Кому интересно, прошу под кат.

Состояние

Мы вовсю работаем над Go 1.13, релиз которого, надеюсь, состоится в начале августа этого года. Это первый релиз, который будет включать в себя изменения конкретно в языке (а не просто незначительные правки спецификации) после длительного моратория на любые такие изменения.

Чтобы прийти к этим изменениям в языке, мы начали с нескольких жизнеспособных предложений (proposals), отобранных из гораздо большего списка предложений по Go 2, в соответствии с новым процессом оценки предложений, описанным в посте "Go 2, here we come!". Мы хотели, чтобы первичный отбор предложений нами играл относительно малую роль и, по большей части, не вызывал споров, чтобы с большой вероятностью они бы прошли весь этот процесс. Предложенные изменения должны были быть обратно совместимыми, чтобы сломать как можно меньше, поскольку модули (которые в будущем позволят выбрать версию языка для конкретного модуля) пока еще не являются режимом сборки по умолчанию. Коротко, текущий начальный этап изменений был больше направлен на то, чтобы снова сдвинуться с мертвой точки и получить опыт, а не на решение больших проблем.

В тестах A/B мы попытались замедлять выдачу страниц с шагом 100 миллисекунд и обнаружили, что даже очень небольшие задержки приводят к существенному падению доходов. — Грег Линден, Amazon.com

• Операции, которые хорошо выполняются в небольших масштабах, становятся нежизнеспособными с ростом числа пользователей. Обычно это операции O(N) или O(N²). Когда база пользователей мала, всё работает отлично. Продукт спешат вывести на рынок. По мере роста базы возникает всё больше неожиданных патологических ситуаций — и сервис останавливается.
  
• Много отдельных источников неоптимальной работы, «смерть от тысячи порезов».

Почему Go?

Что я хотел и к чему стремился

Контроллеры (controller)

import mggo

type News struct{
   ID int
   Title string
   Text string 
}
func NewNews() *NewNews{
   return &NewNews{}
}
func init() {
    // регистрируем контроллер
   mggo.RegisterController("news", NewNews)
}

func(n *News) Read(ctx *mggo.BaseContext) News{
   return News{1, "First News", "Text first News"}
}

func(n *News) IndexView(ctx *mggo.BaseContext, data *mggo.ViewData, path []string){
   data.View = "news/news.html"
   data.Data["News"]
   data.Data["News"] = n.Read()
}

Пришло время заняться контейнерами

В процессе знакомства с Golang я решил сделать каркас приложения, с которым мне в дальнейшем будет удобно работать. В результате получилась на мой взгляд хорошая заготовка, которой я решил поделиться, и заодно обсудить моменты, которые возникли по ходу создания каркаса.

В принципе, дизайн языка Go как бы намекает, что на нем не надо делать масштабных приложений (я про отсутствие генериков и не очень мощный механизм обработки ошибок). Но мы-то все равно знаем, что размер приложений обычно не уменьшается, а чаще совсем наоборот. Поэтому лучше сразу сделать каркас, на который можно будет нанизывать новые функции без ущерба для поддержки кода.

Освоение прагматической обработки ошибок в вашем Go-коде

В динамических языках, вроде python и javascript, возможно прямо во время работы заменять методы и классы в модулях. Это очень удобно для тестов — можно просто ставить "заплатки", которые будут исключать тяжёлую или ненужную логику в контексте данного теста.

Но что делать в C++? Go? Java? В этих языках код не получится модифицировать для тестов на лету, а создание заплаток требует отдельных инструментов.

В таких случаях стоит специально писать код так, чтобы он тестировался. Это не просто маниакальное стремление увидеть в своём проекте 100% покрытие. Это шаг к написанию поддерживаемого и качественного кода.

В этой статье я попробую рассказать об основных идеях, стоящих за написанием тестируемого кода и показать, как их можно использовать на примере простой программы на языке go.