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

Да комбинация, чего уж там

1) Линтер мигает
2) Смотрим, опа, херня
3) Наказываем

Два и насрать на такую команду, которая игнорирует правила. Найдём других.

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

Он их должен определять. Иначе начнется бардак и для схожих идиом и абстракций начнут пилить разные API.
Если система очень большая, то их (архитекторов) будет несколько.

Ну вот, несколько человек-архитекторов - и тот самый бардак. А все потому, что проблему закрывать надо не "человеком", а процессом.

У меня был один программист, которому было неудобно делать fprintf(stderr, "%llu", (unsigned long long)....).
И только из-за этого он внутри всё перетащил c int32_t и int64_t обратно на long и long long.

А потом проект падал на ARM 32-бит, потому что писали его под Linux amd64 и там везде были разные sizeof.

И никаким линтером это бы не решили.

Если компания платит +30% к рынку - да.
А если нет, то поиск (кто их будет собеседовать?) растянется на месяцы, онбординг еще на месяцы и проект встанет на полгода минимум.

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

Точно так же, как для машинистов пишут про проезд на красный свет.
https://railmax.ucoz.ru/Screens/TEM2_cab.jpg

о_0
в поезде руль есть !?)

Это переключатель тяги))

Ровно потому, что люди везде одни и те же обезьяны (в биологическом смысле), и допускают они одни и те же ошибки.

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

Ну так и запишем, что в среднем по рынку работают имбецилы, которые не в состоянии просто следовать соглашениям об API. Вопрос: надо ли с такими работать?

Конструкторские проблемы процессами на закрываются.
Не было бы Дегтярева, не было бы и пулемета ДП-27 и т.д.
Главный конструктор - ключевая фигура, которую ни скрам, ни 6 сигма, ни печеньки, ни онбоардинг не заменят.

Конструкторские — нет, не закрываются. А вот производственные — вполне.
API микросервисов это в чистом виде низкоуровневые процессы, их можно сравнить со сверлением отверстий.
Вам выдали сверло на 8 мм, вот и сверлите. Главный инженер завода не может и не должен проверять, не воткнул ли какой похмельный работяга сверло на 10 мм.
Должен быть контроль на выходе. Если что-то не так, виновные наказывается. Неспособные работать по правилам - увольняются. Вот и всё

Чот вы теплое с мокрым сравниваете.

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

Это не просто дорого, это ещё и очень медленно. Я в 2006-м работал в Livejournal и по неопытности пытался писать всё API сам. Но закончилось это плохо, потому что невозможно успеть всё и везде. Правильнее создавать процессы принятия решений, алгоритмизировать действия. Тогда не приходится лазить руками в код.

Догфудингом. Будем платить себе через свою же систему.

Если цифры не совпадут с 1С, то главбух нас повесит.

И потом разрабы уволятся - а догфудинг разгребать тебе :)

Точно :)