Для замены код-ревью очевидно. :)

Это был ответ не вам.

Сорян

Вы противоречите сами себе. Все эти инструменты являются элементами обеспечения надёжности системы, и к принципу zero trust отношения не имеют, как и к понятию "команда".

Что-то звучит как-будто ревью - это наказание какое )

Потому что тесты при рефакторинге/апдейтах помогут лучше любого код ревью. Ценность кодревью мимолётна и растворится завтра как дымка , а тесты и хорошая команда это отличная инвестиция

Никакой мониторинг не обеспечит надежность. Он только покажет где система оказалась ненадежной и обкакалась. 🙂

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

А код ревью полгода назад при развитии проекта поможет намного лучше, чем гипотетическая "хорошая команда" сегодня (что такое, кстати, "хорошая" команда, каковы критерии?)

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

Современные SRE оперируют метрикой "time to mitigate", а не "time without incidents".

Для этого есть линтеры

SRE не оперируют одной метрикой.

Просто самый крупный проект Сергея похоже 100-150 тыс строк, отсюда и соответствующее понимание. Хотя конечно, количество строк всего проекта особо не интересно, просто потому, что хорошо спроектированная ИС должна быть модульна и компоненты должны быть слабо связаны. В такой системе ее размеры не особо важны для любого программиста, он все равно в каждый момент времени видит только кусок. А если есть система которая требует знания "всей системы", то это лишь намекает на кривой дизайн

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

Я понимаю, что вам сложно аргументировать и очень хочется перейти на личности, но прошу вас этого не делать.

Действительно, те "горячие" части кодовой базы, которые часто меняются, как правило хорошо знакомы команде, но это не отменяет необходимости содержать в порядке всю кодовую базу, просто потому, что новые вводные от бизнеса могут поступить с любой стороны и в любой момент. Например: внедрение GDPR, и всей команде надо ознакомиться со всем неймспейсом, работающим с персданными, и дописать туда кучу функционала по архивации и удалению PD по запросу.

Вы же первый на личности перешли 😅

Я этого и не утверждал.

Я вас просто отзеркалил, но при этом привел аргументацию, попробуйте ее опровергнуть и уже отвечайте на мой вопрос скорее

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