В чем сложность поддержки проектов на Go?

Question

[Михаил Р.]

Приветствую!

Не первый раз встречаю высказывания в стиле "на Go сложно поддерживать проекты", приводятся разные аргументы, чаще всего "нет ООП", "нет нормальной проверки ошибок" итп.

Подскажите, по Вашему мнению, действительно ли на go сложно поддерживать проекты, если да, то в чем это выражается?

Comments

[Lynn «Кофеман»]

Если заменить «сложно» на «непривычно», то фраза имеет право на существование.

А так это стандартные отмазки неосиляторов

Answer 1

[Евгений Мамонов]

Более четырёх лет пишу на Go, лично для меня поддерживать проекты на других языках сложнее ))
До Go много лет писал на Perl/PHP/Python/Java/C/Ruby on rails/JavaScript и "крутил" еще не мало чего.
Сейчас пишу только на Go и Python.

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

Про обработку ошибок - это да, это, пожалуй, единственное что мне не нравится в Go.
Для себя я решил эту проблему за 1-2 часа :) и больше меня это не беспокоит.

По ООП - в Go оно есть, лично мне оно нравится намного больше, чем ООП в других языках ))
Всё, что реально нужно - всё есть, но при этом ничего лишнего нет.
Интерфейсы - просто прекрасны :)) Каналы, горутины - это просто "счастье" :))

А если объективно - то я бы не стал говорить о сложности поддержки проекта применимо к какому то конкретному языку.

Как правило сложность поддержки возникает там, где нормальная архитектура не заложена в проект.
Т.е. проект как могла так и писала куча людей плюс, как обычно, сделать нужно было побыстрее )), от этого никто вообще не думал об архитектуре и получилось то, что получилось :))
Про покрытие тестами и документацию мы вообще не говорим )))

А когда в таком проекте нужно что-то доработать или исправить ошибку, то почти всегда очень не просто найти то место, где нужно править, и после правок в одном месте, как правило, что-то ломается в другом :)

Как минимум, нужно соблюдать принципы SOLID, иначе код получается, мягко говоря, не поддерживаемым.
Но понимание этих принципов так же приходит с опытом, их нельзя научиться соблюдать просто прочитавши книгу или статью. Нужно сделать несколько проектов используя эти принципы, написать криво, понять как было бы правильно, всё переделать и так несколько раз.
Тогда, со временем, начнёт получаться понятный и легко поддерживаемый код.

Так мы приходим к тому, что если опыта нет - тогда проект поддерживать будет достаточно тяжело не взирая на язык и т.д.

Хочется добавить, что как бы не писали про Go, что он простой и т.д. - он явно сложнее Python/PHP и т.д.
Это еще один повод сказать, что поддерживать код на Go сложно ))

Также стоит учитывать, что проекты которые пишут на Go зачастую сложнее, чем проекты для которых выберут скриптовый язык. Go выбирают когда планируются большие нагрузки, параллельная обработка чего-либо и т.д., а это, в свою очередь, дополнительно усложняет проект.

Comments

[Rerurk]

Каким образом обработка ошибок решена, не поделитесь? Сечас я скидываю всё в а-ля error collector, с описанием места возникновения

[Евгений Мамонов]

У меня в этом плане сделано попроще, как мне кажется :)
Подобный подход я использовал еще когда писал на C.

Фактически есть структура вида, которая реализует интерфейс error

type Error struct {
    Code       uint64   `json:"code"`
    Message string    `json:"message"`
}

Все функции, которые могут вернуть ошибку - возвращают именно эту структуру.

При реализации я ставил себе такие задачи:
- иметь возможность однозначно идентифицировать ошибку
в папке core в проекте есть файл где константами описаны общие коды ошибок

- иметь возможность однозначно понимать сервис, в котором произошла ошибка
все сервисы также возвращают информацию об ошибке этой же структурой, за каждым сервисом закреплён диапазон кодов ошибок, так я понимаю в каком сервисе была ошибка

- иметь возможность изменять текст ошибки в ответе пользователю для низкоуровневых ошибок, например при запросе к базе

Вот почти полная реализация

// Error тип ошибки, который содержит сообщение и код ошибки
type Error struct {
    Code       uint64   `json:"code"`
    Message string `json:"message"`
}

// Alias алиас для json маршалинга
type Alias Error

// New создаёт структуру Error
func New(code uint64, message string) *Error {
    return &Error{
        Code:    code,
        Message: message,
    }
}

// Newf создаёт структуру Error, для формирования сообщения вызывает Sprintf
func Newf(code uint64, format string, args ...interface{}) *Error {
    return &Error{
        Code:    code,
        Message: fmt.Sprintf(format, args...),
    }
}

// NewIfNotNil создаёт структуру Error если err != nil
func NewIfNotNil(code uint64, err error) *Error {
    if err == nil {
        return nil
    }

    return New(code, err.Error())
}

// Error реализация интерфейса error
func (e Error) Error() string {
    return e.Message
}

// String реализация интерфейса Stringer
func (e Error) String() string {
    return e.Message
}

// MarshalJSON реализует интерфейс json.Marshaler
func (e Error) MarshalJSON() ([]byte, error) {
    return json.Marshal(Alias(e))
}

// UnmarshalJSON реализует интерфейс json.Unmarshaler
func (e *Error) UnmarshalJSON(data []byte) error {
    if data == nil || string(data) == "null" {
        return nil
    }
    err := (*Alias)(e)
    return json.Unmarshal(data, &err)
}

А дальше что-то типа такого

func myFunc1() *errno.Error {
    err := doSomthing(...)
    if err != nil {
        return errno.New(core.ErrCodeDBError, err.Error())
    }
}

// или тоже самое, но в одну строку
func myFunc2() *errno.Error {
    // если функция doSomthing вернёт nil - вернёт nil
    // если doSomthing вернёт ошибку - создаст структуру с кодом ошибки core.ErrCodeDBError и сообщением
    // и вернёт *errno.Error
    return errno.NewIfNotNil(core.ErrCodeDBError, doSomthing(...))
}

Есть еще обёртка, которая отправляет мне оповещение, когда происходит ошибка, ну... конечно кроме 401 и т.д.
Если что-то происходит не так, как надо - я об этом узнаю до того, как кто-то об этом скажет :)

Отдельно есть еще обработка panic.
Если где-то вылетает panic мне отправляется письмо с дампом:
- настроек/переменных окружения
- параметров HTTP запроса
- cookies
- stack trace

Пока такой подход мне полностью подходит.
Если у вас есть случаи, когда такой подход не подходит - напишите пожалуйста, мне будет очень интересно о них узнать.

[Rerurk]

Евгений Мамонов, аналогичная структура, только я в файл сразу пуляю

[Rerurk]

Евгений Мамонов, ваш подход очень логичен. Сообщения в телеграмм? У меня просто проблеммы отправки с почты. И да. ООП кончечно в go по началу ломает мозг. Хотелось бросить) Но node не нравилась больше))

[Евгений Мамонов]

> Сообщения в телеграмм?
В каких то случаях да, в каких то почта.

NodeJS - это да :))

[Andrew Zarey]

>>Сейчас пишу только на Go и Python.

Скажите, пожалуйста, эти языки вы используете вместе в комплекте?
Или просто каждый из языков нравится, но в проектах они между собой не связаны?

[Евгений Мамонов]

Тут просто зависит от задачи, требований, наличия ресурсов.

Если предполагается нагрузка или большой/сложный проект - использую Go.

Если нужно сделать что-то простое, легко дорабатываемое (легко найти специалиста) - использую Python + FastAPI/SQLAlchemy, иногда Python + Django (если что-то совсем простое).

PHP, Ruby on rails тоже, в целом, для таких проектов подойдут. Я с ними тоже работал, но по итогу остановился на Python, т.к. код хорошо читается (лучше PHP, JS, Ruby) на мой взгляд, библиотек хороших много, людей, которые его знают очень много, популярность растёт - значит и дальше будет развиваться.

PHP использую когда нужно сделать лендинг, идеально для этого подходит )))

Answer 2

[javedimka]

В том что нет разработчиков.
Если вы решили пилить продукт на Go - у вас возникнут проблемы. После создания - начинается поддержка. А если разработчик выбрал Go - поддержка ему не интересна, ему нравится модно, ново, молодёжно, он уйдёт и вы останетесь у разбитого корыта, с открытыми по пол года вакансиями и даже зарплата сильно выше рынка особо не поможет.

Comments

[Rerurk]

Вы пробывали писать на go? Это не модно, это красиво лаконично и быстро действенно

[javedimka]

Rerurk, Конечно пробовал, кто не пробовал писать на хайповом языке то? Это очень модно и это очень дорого.

[Евгений Мамонов]

Выбор всегда должен быть осознанный, иначе проблем не избежать.

Если вы заказываете выполнение проекта, например, с оплатой за проект или у вас в штате один программист - в этом случае нужно рассматривать только самые популярные языки в связке с самыми популярными фреймворками, например Python + Django/Flask, PHP + Laravel и т.д.
Иначе вы неизбежно получите именно ту проблему о которой вы написали.

Плюс нужно требовать документацию и покрытие тестами без этого новый программист будет обречён на создание новых проблем и будет настаивать на том, что всё надо переписать :)
Но на это нельзя соглашаться если проект хоть как то работает, иначе вы получите опять тот же самый результат. Исключение только то, что переделывать будут уже под Python Django/Flask, PHP + Laravel.

Когда бюджет небольшой - я бы советовал привлечь консультанта по архитектуре до начала работ, чтобы он помог подготовить требования к вакансии, объяснил программисту как нужно делать и чтобы он же принял работу, чтобы проверил наличие и качество документации и авто-тестов. Это самый бюджетный вариант (из известных мне) получить сносный результат по минимальной цене.

Если у вас уже есть рабочий продукт, который не справляется с нагрузками или вы сразу понимаете что у вас будут большие нагрузки (например вы Ozon/Avito/Yandex и т.д.) или по каким то другим причинам вам не можете использовать скриптовые языки с популярными фреймворками - несомненно Go будет хорошим выбором.

[javedimka]

Если вы заказываете выполнение проекта, например, с оплатой за проект или у вас в штате один программист - в этом случае нужно рассматривать только самые популярные языки в связке с самыми популярными фреймворками, например Python + Django/Flask, PHP + Laravel и т.д.

Евгений Мамонов,
А что делать, если команда продуктовая, нанимает команду из много Go разработчиков, из которых больше половины сливается после того как продукт прошёл стадию MVP, а фиксить баги людям не интересно? Как искать людей на поддержку? Да никак.

[Ev Gen]

Согласен, на C# толкового программиста найти сложно работодателю, а тут Go.