Добро пожаловать!

vmkteam labs – ресурс, посвященный программированию на Go и около.

У нас есть Github, куда мы выкладываем проекты https://github.com/vmkteam/ и философия, которую мы используем при разработке.

Простая архитектура

В разделе про архитектуру вы найдете описание “простой архитектуры”, которая подойдет многим (исключая бигтех).

Работа с API

В разделе про API вы найдете хорошие практики.

Onboarding

В данном разделе мы попробуем пройти создание проекта с чистого листа и его модификации в будущем. Познакомимся с нашими инструментами.

Тулинг

JSON-RPC 2.0

  • zenrpc – JSON-RPC 2.0 сервер через go generate
    • zenrpc-middleware – полезные мидлвари для zenrpc
    • rpcgen – генератор клиентов на различных языках (Go/Dart/PHP/TypeScript/Swift)
    • smdbox – UI для zenrpc
  • rpcdiff – дифф для CI между разными схемами OpenRPC (через rpcgen)
  • brokersrv – сервис для асинхронного взаимодействия через JSON-RPC 2.0

Библиотеки

  • embedlog – обертка над slog c плюшками
  • cron - реализация крона с поддержкой middleware & ui
  • vfs – библиотека/сервис для работы с файлами самым простым образом

Инструменты

Заметки: Архитектурный репозиторий
Заметки: Архитектурный репозиторий На этапе зарождения нового проекта будет хорошо, если в какой-либо базе знаний сохранится описание примерной архитектуры, и куда мы с ней должны прийти. Но практика показывает, что на это обычно не хватает времени. В данной статье представлена попытка описания минимального архитектурного репозитория (Architecture as Code). Или как жить без выделенного архитектора в команде.
Философия разработки от vmkteam
Философия разработки от vmkteam Лучший код тот, который не написан. Если нужно все-же писать код, то попробуйте сначала его сгенерировать (все еще без LLM). Если сгенерировать не удалось – пишите максимально простой понятный код. Пишите код для того, кто посмотрит его через полгода и все поймет. Через полгода – это про Вас (из будущего). Пишите код так, чтобы никто не понял, кто его написал (речь про общий стиль). Связывайте код с задачами (номер задачи в начале commit message, через полгода скажете себе спасибо). Не пишите тот код, которого не просили (а то это еще нужно будет поддерживать). Экономьте время тех, кто будет использовать ваш код (понятный контракт и документация). Ставьте себя на место QA, когда тестируете свой код. Ставьте себя на место другого разработчика, когда используете свой код. Проектируйте на внезапное падение (не найдетесь, что ваш сервис всегда завершится корректно). Проверяйте все, что пришло извне (пользовательский ввод особенно опасен). Деплойте в пятницу (если научились; если нет – то учитесь). В программировании все еще две проблемы, избегайте их до последнего (кешируйте от безысходности). Прочитайте книжку по постгресу (сэкономите себе время при разработке). Используйте чаще мозг, чем LLM (LLM отупляет). Не забывайте программировать для души (но не тащите это в продакшн, см пункт 3). Неудачное планирование – запланированная неудача. Берите только отгрумленные и расписанные задачи в спринт. Не берите не отгрумленные задачи в спринт (еще раз для закрепления материала). Спрашивайте у PO, что будет через полгода и год при обсуждении задачи (можно заложить фундамент, но в разумных пределах). Программирование в “ворде” все еще дешевле (распишите в текстовом виде нижний и верхний слой).
Работа с API
Работа с API Предпочтительный формат В своей практике мы используем JSON-RPC 2.0 как при внешнем, так и при внутреннем взаимодействии. Современные приложения и сервисы работают в RPC парадигме, нежели в ресурсной.
Claude review for colgen.go
Code Review: colgen.go Overall Assessment The code is generally well-structured and follows many Go idioms. However, there are several areas where improvements can be made for better readability, maintainability, and adherence to Go best practices.
DeepSeek review for colgen.go
Here’s my code review with recommendations for improvements: General Observations The code is well-structured and follows many Go idioms. However, there are some areas that could be improved for better readability, maintainability, and idiomatic Go practices. Documentation Improvements Several exported functions and types are missing documentation. Here are the recommended additions: