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

В конце каждого файла должен быть перевод строки. А если не будет, то кто умрёт?

Многие Linux дистрибутивы поумирают. И многие программы сломаются. Конфиги часто разбиваются на отдельные файлы и складываются в /etc/что-нибудь.d/ и дальше обычной склейкой генерируется полный конфиг.
Или если есть препроцессинг исходного кода (в случае объединения файлов).
У меня на реальном java-проекте ребята имели 10+ properties файлов, которые объединялись в разных комбинациях. И в каждом файле в конце стояли дурацкие коменты «оставьте здесь пустую строчку». Пустая строка, кстати, не нужна, если бы разобрались в проблемах

Нельзя делать несколько statements на одной строке. Если я напишу $x = 1; $y = 1; $z = 1;, то читабельность ухудшится на 0.00001% и можно закрывать техотдел?

Давайте быть честными. Не «x y z», а
«size_t keyword_scan_len = GetScanKeyword(h, keywords); size_t keyword_scan_index = 1; TYPE *pi = (TYPE *)(void *)(parmi)». А когда прелетит изменение в этой строке, надо ещё всматриваться и искать, что конкретно поменялось? index? pi? len? А еслиGetScanKeyword надо было после поставить? Даже если есть строгая практика отделения объявления от присвоения, всё равно, названия переменных и их типов могут быть многобуквеннымми, а их значение константой " int c = THE_SEVENTY_EIGHT_PRIME_NUMBER".

Declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1). Ох, как всё серьёзно. Ни одного пробела, причем слово MUST капсом, чтобы все понимали степень ответственности. Если вставить где-нибудь пробел, то на код ревью никто код же прочесть не сможет!

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

— Современные ide оснащены автоформатированием кода и если не будет стандарта во всём, то каждый коммит будет порождать тонны мусора.
— Когда оформление стандартизировано, я могу выполнять массовые исправления кода (по паттерну), рефакторинг в лоб и т.п.

Ну и наконец, вы подменили понятия. Не дресскод с людьми надо сравнивать, а с чем-нибудь таким же массовым или бумажным:
1. Представьте, что все официальные документы пишутся не от шаблона а от балды: заявление, договоры. А вы тут бухгалтер — разбирайтесь.
2. Вы купили 10 гаек на 12 но они все под разные ключи. А у некоторых не та резьба. А вы крутите эти гайки — наслаждайтесь.
3. Деньги печатаются в разных цветах, разных размеров и форм. И с разным расположением надписей. И вы работаете кассиром — добро пожаловать в персональный ад.

При строительстве кирпичного дома вы не хотите знать, что каждый кирпич — индивидуальность, личность и «он так себя видит». Вы обложите процесс изготовления кирпича максимальным набором правил. И неважных правил там не будет. Вы не станете проверять то, что не важно. Если правил слишком много и это доставляет хлопоты — то вы будете стремиться упростить проверку и сделаете процесс таковым, чтоб он легче проходил её.

Не понимаю, за что минусанули человека.
Как раз сам вышел на эту же проблему: cdn.github.com недоступен.
Пару месяцев всё работало и вот опять. Причём traceroute не проходит, а чистый tcp пропускает ack и syn. Остальное нет. И всё на белтелекоме обрывается. ByFly, Beltelecom, Mts.

но, позвольте! у вас тут три пробле… oh shit!!!

Для тех, кто не хочет читать статью целиком:

Линукс, терминал, курсы!

apt-get install -y xvfb

Ну купи

docker build .

Ну почти девопс уже ж… ну купи,
ну ннада

Вот ещё: noyaml.com

Думаю минусуют за грубость, а не за смысл

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

Меня от геррита останавливает только одно — кроме дженкинса не могу прикрутить никакого вменяемого ci (наподобии gitlab-ci или github actions). Кто бы подсказал как это сделать — уже бы ушёл на него.

Gerrit так и задумывался, чтоб работать над коммитами, а не над ветками.
Каждый коммит — логически законченное изменение.
Видеть в истории 50 коммитов «хождения по граблям» и потом «кусок говна, который ноканец-то заработал merged to master» — не очень приятное зрелище.
Увидеть 3 patchset-а в стиле «Add feature 1», «Add test for feature 1», «Update docs» — намного приятнее и проще ревьюить. У вас есть пачт или серия патчей. Всё.

Чего не хватает в gitlab ce:
1. Approves — плати
2. Auto Reviewers — если и есть — скорее всего плати
3. Проверка каждого коммита, а не ветки. На вопрос «зачем?» оставлю время подумать
4. Скорость ui — gitlab тормозит. Ну вот реально тормозит. Просто мы отвыкли уже от по-настоящему быстрых вещей
5. Сделал ревью, оставил комментарии. Пришёл новый пуш и все комменты outdated. Как было и как стало — иди ищи, открывай старое, вспоминай где оставил коммент, открывай новое, смотри как стало. Может доработают
6. Review имён файлов как?
7. Review commit message как?
8. Хуки и валидация commit-ов — плати/получи админские права на инстанс.

Но тут как сравнивать. Gitlab как code review system пока никакой.
Gerrit как project management system — тоже никакой.

Мониторинг вас не спасёт. Картинка будет такая:
1. всё хорошо, ни что не предвещало беды
2. всё хорошо, ни что не предвещало беды
3. всё хорошо, ни что не предвещало беды
4. Мы упали, ошибки, данные потеряны
5. всё хорошо, ни что не предвещало беды
6. всё хорошо, ни что не предвещало беды

Имею определённый опыт и взрастил уже много людей с джуна до уверенных сеньоров. Конечно, это их заслуга, кто хочешь/может — растёт.

Но вот что я вижу постоянно: человек сначала джун, уже через 3 месяца научился тыкать кнопку и хочет быть мидлом, а через полгода уже «ну когда сеньор и ЗП в $2500?». А вон Вася из конторы ХХХ умеет меньше, а уже сеньор и прочие радости.

И это большая проблема. Банально, запутались в SSL/TLS сертификатах, какой там куда? Где CA, где private key, куда dhparam класть и работа встаёт на 2 дня из-за глупостей и отсутствия базовых знаний. Научились в кубике ямл писать без понимая и любое нестандартное поведение — застряли на неделю.

Как это всё получается? Прочитал очень хороший пример про абстракции. Вот у нас есть железо, машинный код, над ним язык более высокого уровня, над ним ещё более высокого, над ним библиотека, над ней фреймворк, над фреймворком ещё IDE. Абстракции имеют свойство «течь», когда в 15% случаев поведение абстракции неожиданно.

// псевдокод
int main() {
  int fac = 1;
  for (int i=1;i<=10000000; i++) {
    fac = fac * i;
  }
  std::cout << fac; // почему не работает?
}

Имеем вероятность того, что написанная система будет работать 0.85^N (если 15% течёт, конечно), где N — количество абстракций. Прилага в кубике, которая ранает докер, который крутится на хосте, который ранает непосредственно бинарник, который на фреймворке, в котором куча библиотек, которые используют язык высокого уровня, которые интепретируются… ну да хватит. 0.85^8 = 0.2724905250390625 — вероятность, что будет работать без проблем.

И тут начинают сыпаться «сеньоры», которые просто проскочили базу. Всё меньше и меньше людей заглядывают под капот. А надо хотя бы на 2-3 абстракции вниз разобрать. А это в школах часто пропускается. И опыт показывает, что те, кто лазил под капот — быстрее и лучше понимают и решают проблемы.

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

А мне вот интересно, на сколько легальна «схема», которую я встречаю:

1. Делаем некий тул bicycle
2. Открываем это под opensource свободно
3. Собираем коммьюнити, развиваем проект
4. Пользуемся балагами сервисов, который предоставляют опенсорсным проектам плюшки бесплатно (ci/bugtracker/wiki/tools/etc)
5. Покупаем торговую марку «My Bicycle» и вешаем на бинарники коммерческую лицензию.

Как результат: исходники вот они, все «белые и пушистые». Но как только ты эти исходники собрал — бинарник под лицензией. И тут тонкая грань, что сам по себе бинарник может и не быть под лицензией, но его имя — трейдмарк и просто так пользоваться этим нельзя. Толку от исходников, если на выходе «тыква»? Форкать и бегать sed-ом…

Я бы начал с того, что убрал гит из уравнения. У вас должен быть некий проект. Он живёт где-то в каталоге и как-то организован и понятен. Если внутри него есть какие-то фичи (которые являются полностью самостоятельными) — то они то же как-то лежат в этих папках. Всё. Если у вас 10 проектов — значит 10.

Теперь добавляем гит. Это как «вселенная проекта» — каждый коммит — состояние вселенное на определённый момент времени. Вы можете двигаться вперёд и назад по времени. Фича бранчи в данном случае — альтернативное состояние вселенной, которое не влияет на основную.

Когда большая команда разрабатывает проект, фича бранч создаётся, чтобы разрабатывать и проверять новую фичу, не мешая проекту. Если фича не стабильна, ломает всё или не совместима — можно продолжать её разрабатывать, в то время как основная ветка (часто master) выходит в прод. Предполагается, что каждая такая ветка рана или поздно будет «влита» в мастер. Т.е. в мастере будут все фичи, который условно стабильны.

В действительности ансибл вообще не декларативный.
Пример выше про «state=restarted» — это раз.
И любое действие — это императивный вызов, он просто с идемпотентностью в лучшем случае: поставь если не стоит, создай если нету и т.д. На ансибле ты не описываешь конечное состояние, ты пишешь «сделай а, сделай б»
И вот декларативный пример, который, конечно же не будет работать:

# псевдо-код
- service: httpd
  state: started
- package: httpd
  state: installed

Тем, что чел явно хотел делать chmod ;)

> Допустим под 20
сколько РАЗЛИЧНЫХ контейнеров ранается в проекте. Возможно, у вас действительно 20. Но если у вас кластер эластика на 15 машин — считайте это за 1.

>унифицированные интерфейсы конфигурирования
нет. Переменные окружения? У всех всё по-разному, а некоторые аппы, пока файл не положишь — не заработают. Либо приложение можно удобно конфигурировать, либо нет. Докер тут никак не помогает. И если завтра дедлайн, а конфигурить через файл — будешь монтировать файл.

>Не зависит особо от докера
О том и моя мысль, что плюсы, которые приписывают докеру, вовсе не его

> Да, можно понаписать башскриптов
Не так. «нужно понаписать пачку башскриптов». Entrypoint более-менее непростого контейнера видели? Init перед entrypoint-ом и прочее весёлости. там много скриптов получается. Благо, это не всегда плохо.

> Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80
Это тоже не про докер.

> они начинают больше думать головой
они начинают больше копипастить со stackoverflow в стиле

apt-get install 200 пакетов которые я хз зачем

или

chmod 777 -R /usr # потому что без этого, почему-то не работает

И мой любимчик:

chown 775 /home/app

Внесу свои 6 копеек.
Я тоже недолюбливаю докер, хотя, начал использовать его до того, как это стало мейнстримом.
И мои мысли о тех преимуществах, про которые рассказывают следующие:
1. Безопасность — разработчику плевать, это не то, ради чего он рад пользоваться докером. admin/admin глубоко в коде и прочие радости. Пока разраба не пнут — не пофиксит
2. Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать? Другое дело, если вы — public ci cluster. Может быть.
3. Удобство запуска — НЕТ. Да, выполнить docker run легко. Но прилага на дефолтах. Только «на посмотреть». Когда надо сконфигурить — поехали тонна переменных окружений, монтирование папок, конфиг-файлов и т.д. А entry-points под это дело писать на 2000 строк — то ещё удовольствие.
4. Сетка — стало только сложнее. А когда речь идёт о траблшуте, почему порт из контейнера внутри hyper-v на хост систему не пробросился — почему-то теряются даже сеньоры.

И вот мы подобрались к тому, из-за чего контейнеры стали популярны:
5. Запаковать all-in-one. Современный разработчик — это модный чувак, который сидит под вендой, тыкает пальцем в кнопочку в ide, нихрена не понимает как устроена его ОС, не умеет в линукс, не умеет упаковывать и распространять дистрибутив своей же программы (tar.gz/npm/deb/rpm/gem/whatever). Но при этом разрабатывает, конечно-же, под линукс. И как же ему бедненькому всё что он локально сделал запустить? Правильно, используя stack overflow наустанавливать не пойми чего, скопировать всё подряд и через 30 баш скриптов запустить без особого понимания в докере. Зато работает. А потом на прод.
Docker — это современная package management система.

Ну и, пожалуй, есть ещё один удобный пункт — который близок к 5ому:
6. создание окружения для сборки. Собрал себе в контейнере всё, что нужно, компиляторы, тулы, и т.д. — и собирай себе на здоровье. Кстати, это же можно было делать и в chroot, но да — docker удобнее будет.

Альтернативы: разобраться в пакетной системе. Например, deb трекает каждый файл при установке и гарантировано удалит это за собой во время удаления. Есть жизненный цикл пакета — pre/post-install/rm, pre/post-configure и т.д.

Однако, текущие пакетные системы тоже имеет проблемы, например, нельзя или очень сложно иметь сразу несколько версий пакетов в системе. И тут на сцену выходят следующие ребята, которые решают и это: nix, guix, flatpack, snap, chef habitat.

Предположу, что так сделано из-за идеи в гите с переписыванием истории коммитов. В английском варианте:
If I (merge|cherry-pick|rebase|use|...) this commit it will (commit message):
If I use this commit it will «Add logout button to home page».

Это позволяет мейнтейнерам буквально по кусочкам собирать нужную цепочку из сотен коммитов и веток.

По-русски, наверное, стоит перефразирвать, т.к. слова меняются из-за склонения и времени.

И ещё чего-нибудь из этого списка (конечно, не всем нужен какой-нибудь gtk):

Я смотрел из статьи:
openjdk 8 db77212ffe05 13 days ago 737MB
openjdk jre e956268fd4ed 13 days ago 538MB

Alpine меньше, но не из-за того что «alpine vs debian», т.к. между ними разница в 95 мб
Могу только осторожно предпложить, что не каждый java проект заведётся на этом alpine образе