Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.

Т.е., таблица изначально выглядит так:

CREATE TABLE coupons (
    id  bigint primary key generated by default as identity,
    user_id bigint not null,
    created_at timestamp not null,
    valid_until timestamp not null
)

Идея упростить или абстрагировать код с помощью ORM, возможно, имеет очень ограниченный контекст применимости. По сути ORM хорош для приложений уровня простого CRUD, а дальше начинает только мешать. А CRUD-приложений в реальной жизни очень мало.

Проблемы

1. При использовании ORM мы обычно прописываем в коде сущности и их взаимосвязи, и по сути это — проектирование БД ещё раз (дублирование логики!) прямо в коде.
2. Борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Ты просто не можешь не знать, что у тебя под капотом происходит. Какие там делаются джойны и группировки.
3. Язык запросов в виде цепочки объектов и методов читается хуже, чем SQL, по сути это — особый язык, который надо учить. За себя скажу, что когда писал на PHP (Laravel), длинные запросы на Eloquent меня иногда изумляли своей сложностью чтения:

В Go 1.20 сделали возможность сбилдить приложение с флагом cover

go build -cover

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

Это, конечно, было сделано для интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но, вероятно, это можно попробовать использовать и по-другому:

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

Так можно найти недовыпиленный легаси-код, старые эндпоинты API, которые давно никому не нужны, малозначимые проверки if err != nil и прочее. Как минимум, на это интересно посмотреть, можно найти что-нибудь удивительное.

Disclaimer: разумеется, сбор статистики создает какой-то оверхед, поэтому подойдёт точно не всем. Как вариант, можно пустить туда небольшую часть трафика.

Кучу времени можно сэкономить если:

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

Тщательно проработать важные аспекты нового проекта, собрав нужных людей на встречу(и), написав понятно задачи.
Не прорабатывать тщательно то, что допустимо придумать на ходу / не особо важно / можно спросить.

Если раньше в циклах были проблемы с замыканиями, так как переменная цикла имела скоуп всего цикла, а не одной его итерации, то в 1.22 это поведение поменяют.

проще показать на примере:

 funcs := []func(){}

 for i := 0; i < 5; i++ {
  funcs = append(funcs, func() {
   fmt.Println(i)
  })
 }

 funcs[0]()

Последняя строка примера напечатает 5 в go 1.21, но в go 1.22 будет уже интуитивно понятный 0.

// теперь в Go так можно!
slices.Contains(s, v)

Год назад в блоге Каруны мы писали про дженерики в Go, и там упоминалось, что гошное сообщество разделилось на две части. Не всем это нововведение было нужно, особенно в простом продуктовом коде. И надо сказать, это до сих пор так, дженерики по-прежнему используют далеко не все проекты.

Однако для стандартной библиотеки Go это было по-настоящему царским подарком. Появились новые стандартные обобщенные функции, и, отстоявшись в экспериментальном репозитории golang.org/x/exp, теперь появятся в Go 1.21. Релиз буквально через месяц.

TLDR: появилось множество функций по работе со слайсами, мапами, а также новый логгер с (почти) всеми нужными фишечками.

Лично для меня знаковым событием стало появление возможности поиска элемента в слайсе и получение ключей мапы, потому что ну давно пора, 10 лет языку.

Но давайте обо всём по порядку.

В программировании нет вообще никаких непреложных истин. Даже самые очевидные правила могут иметь контекст, в которых их применять нельзя. К сожалению в 99% организаций есть прям заповеди, обязательные к исполнению. И есть правила, которые считаются правилами хорошего тона (как не сморкаться в занавеску). Однако всегда бывают ситуации, когда лучше все-таки сморкаться.

Вот примеры.

1) Например, DRY — don’t repeat yourself. Хорошее полезное правило, но его можно довести до маразма. Из того что я встречал на практике: есть два разных по бизнес-смыслу раздела, которые начинались с простого CRUD, и многие части (и фронта и бека) выглядели во многом абсолютно одинаково. Если их объединить с помощью общей высосанной из пальца абстракции и тем самым избавиться от небольшого дублирования кода, то потом (очень скоро) можно будет сойти с ума, потому что эти две вещи скоро разъедутся, обрастая кастомными фичами, и абстракция будет только вредить. Нельзя абстрагировать неабстрагуемое, даже если DRY нарушен.

«[Немного] дублирования обходится гораздо дешевле, чем неправильная абстракция» — Сэнди Мец

Т.е. DRY — хороший принцип, но бывают исключения.

Сроки

В разработке ПО существует неразрешимое противоречие — это оценка сроков.

С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.

С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если

• новая функциональность нетипична
• есть зависимости на другие команды
• будет задействована новая технология
• ТЗ надо сильно уточнять
• надо разобраться в логике легаси-кода

Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.

Сейчас модно обсуждать ChatGPT / Сopilot и код, который они генерируют. Может ли AI полноценно программировать? Заменит ли он меня? Имхо этот вопрос вторичен, проблема куда глубже и серьёзнее.

Одни говорят, что на сегодняшний день в Copilot нет ничего плохого — это всего лишь инструмент, устраняющий мелкую рутину. Оно напишет за тебя цикл, проверит if err != nil, но не более того. Другие — что развитие ИИ идет нелинейно, с ускорением, и по опросам специалистов появление разума, сравнимого с человеческим, неизбежно. А если можно будет тиражировать искусственных ученых и программистов, то и до сверхразума недалеко. Который, хе-хе, может решить уничтожить всех людей.

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

вероятность опасного развития событий больше нуля

и эта вероятность не то чтобы совсем иллюзорна.

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

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

Поехали.

Итак, главное — это организационная структура компании и процессы взаимодействия команд. Да-да, как всегда, не технологии, а люди. Сейчас я работаю в Каруне, до этого работал в компаниях поменьше, видел, как набивались шишки, поэтому могу сравнить.

Одна команда

Когда команда одна, не очень большая (two pizza team), то никто никому не мешает. Код ревью, рефакторинг, деплой проходят быстро и весело. Бизнес сфокусирован на цели и работает как единое целое. Целью, кстати, зачастую является проверка гипотезы, нужен ли вообще этот проект кому-то или нет.

Среди программистов не утихают споры о том, надо ли знать "алгосики" для реальной работы, или же это просто некий странный ритуал для прохождения воронки собеседований в компании а-ля FAANG (MANGA). У нас в Каруне в разных командах есть разные мнения на этот счёт. Я, например, как тимлид Go-команды считаю, что некую элементарную базу знать точно бы не помешало, но всё же главное, чтоб человек был хороший.

Мнения могут различаться, но одно я знаю точно: разгадывать загадки бывает очень интересно. Я как-то из любопытства прорешивал задачки на hackerrank, и, если для решения простых задач тупо достаточно догадаться отсортировать данные или построить map (даже не надо ничего особо знать), то для некоторых придумать решение довольно проблематично.

Одна из таких задач — нахождение самой длинной общей подпоследовательности (longest common subsequence). Подобный алгоритм используется в реальной жизни, в таких программах как diff. Скажу сразу: я не смог решить задачу самостоятельно за разумное время (т.е. пока не надоело решать) и посмотрел алгоритм в Википедии.

Но бог с ним с алгоритмом, мне стало жутко интересно, как же, блин, я должен был рассуждать, чтобы самому прийти к этому решению. В итоге эти рассуждения я решил выложить в виде статьи на Хабр.

Disclaimer: я точно не олимпиадник и не гуру алгоритмов, просто любопытствующий.

Найм профессионального программиста — это слишком дорого, да и программирование — совсем не быстрый процесс. А бизнесу всегда нужно "вчера" и желательно бесплатно. Поэтому всё более популярным становится no-code подход: вы не пишете код, а просто, используя кнопки в интерфейсе и мышку, компонуете своё приложение. Звучит красиво. Так можно создать типовое приложение, накидав туда компоненты. Вот пример рекламной статьи no-code системы Bubble, в которой, по сути, говорят, что для стартапа программисты уже не нужны, по крайней мере — на начальном этапе.

Или если у вас есть условный эксель, где вы можете выделить нужные строки и посчитать их сумму, построить график, и т.д. — вам не надо это всё программировать на каком-либо языке. Всё делается в пару кликов. Это тоже no-code.

Но что же будет, если этот подход разовьётся до небес? Можно ли будет его использовать для всё более и более сложных систем? Можно ли выкинуть программистов на улицу?

Вопрос некорректен

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

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

Проблема в том, что такая автоматика с принудительными локами подходит не для всех случаев. Например, вы массово обрабатываете файлы, предполагая, что никакой файл не будет обрабатываться одновременно двумя приложениями сразу, но при этом не хотите создавать для синхронизации полноценную таблицу в БД. В проектах Каруны такие задачи возникают довольно регулярно.

Для решения подобных проблем в PostgreSQL есть так называемые необязательные блокировки (advisory locks), т.е. локи, которые берутся, исходя из логики приложения, а не автоматики хранения/выдачи данных в БД.

В инете полно списков мудрых вдохновляющих цитат. Это всё здорово, но порой скучновато. Представляешь себе, как человек морщит лоб, изо всех сил делает одухотворённое лицо и выдаёт идеальную шедевральную мысль. Скукота.

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

Кент Бек

Кент Бек, создатель методологии "Разработка через тестирование" (TDD), как-то написал:

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

В моей практике не раз были ситуации, когда хотелось посмотреть, какие именно запросы долго тупили в базе в определённый (конкретный) момент времени. А может, запросы не тупили, но каких-то запросов было слишком много.

Ключевое слово — в конкретный момент времени. Например, база непонятно от чего напряглась на 5 минут, потом всё само рассосалось, и очень хочется знать, почему. Отчёты за сутки, присылаемые dba на основе pg_stats_statements, не всегда проясняют ситуацию. Другие графики и логи могут помочь. Но всё же хочется не гадать на кофейной гуще, а конкретно посмотреть, что такому-то запросу в такое-то время было плохо, или его было много.

Можно, конечно, подключить системы а ля okmeter, но okmeter стоит денег. Да ещё и отсылает запросы в чужое облако — что, понятно, не в каждой организации можно считать безопасным.

На удивление, сделать такой мониторинг самому занимает всего полчаса времени, буквально с помощью нескольких строк Go-кода и палок.

Всем привет, это подкаст "Цинковый прод", и у нас есть небольшой анонс. Мы решили разнообразить нашу развлекательно-познавательную программу, и сделать митап, который пройдет онлайн 29 июля в 20:00 МСК.

Участие без регистрации и смс, просто на ютубе:

У нас будет аж 5 докладов:

Про когнитивные искажения много пишут и много говорят.

Однако всегда не хватало более чёткого понимания, как именно это влияет на профессиональную деятельность, мою и моих коллег. Какие решения я как тимлид и программист принимаю неправильно. Что мне подправить, на что обратить внимание.

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

Если вам интересно, добро пожаловать под кат.

Ладно, по каждому пункту — это я погорячился, так как я нашел аж 176 видов искажений. Поэтому выберу рандомно лишь некоторые из них.

func Map[F, T any](s []F, f func(F) T) []T {
    r := make([]T, len(s))
    for i, v := range s {
        r[i] = f(v)
    }
    return r
}

Как вы уже наверняка знаете, proposal по дженерикам в Golang принят (официально это называется type parameters) и будет имплементирован в go 1.18. Бета будет доступна уже в конце этого года. А это значит, что пора разобраться, на чём в итоге остановились разработчики языка — ведь черновик type parameters постоянно менялся в течение последних лет.

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

Самостоятельно поиграться с дженериками можно здесь

Итак, поехали.

Опрос на telegram-канале Cross Join "Можно ли наследовать класс Пингвин от класса Птица?" удивил. Большая часть людей ответили вполне определённо "да" или "нет" (результаты опроса приложены в конце статьи). Не ожидал такого расклада, поэтому решил написать короткую заметку.

На самом деле, если вам зададут такой вопрос на собеседовании, знайте: тут есть подвох. Даже два.

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

Это способность построить в голове модель того, что происходит в создаваемом софте. И помнить ее долго хотя бы в общих чертах.

Вам может быть наплевать на выгоды бизнеса (привет, fillpackart ), или вы наоборот живете только работой. Вы можете знать или не знать детали реализации gc в jvm и вертеть красно-черные деревья.

Это все неважно, если вы не можете натренировать свою серую нейросеть так, чтобы более менее держать в голове систему в целом. То, что относится к той части софта, за которую вы отвечаете, и еще чуть-чуть рядом.