Я бы пересмотрел вообще всё

Нормальные сервисы позволяют вливать автоматически при успешной сборке и наличии необходимого количества аппрувов: просто уменьшите требуемое количество аппрувов до нуля и внезапно и ревью всё ещё возможно (пожеланию разработчика - можно пометить PR флагом драфта) и отвлекать никого не нужно и пайплайн сборки при этом общий.

Но ведь код ревью относится только к новым правкам. Старый легаси код ( Богом забытый раздел.. ) относится уже к рефакторингу, решение о проведении которого принимается обычно +- архитектором, но точно не обычным "тимлидом" который проводит код ревью.

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

Аппрув зачастую часть процессов безопасников и регулярного аудита выкатываемого

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

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

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

На мой взгляд ревью полезен в любом проекте. Но есть нюансы:

• Упомянутое Вами блокирование. Нет такой проблемы, если правильно поставлен процесс ревью: у него должен быть достаточно высокий приоритет, чтобы долго ждать ревью никому не приходилось, плюс количество ревьюверов необходимо свести к минимуму (в идеале - к одному человеку).

• Если это срочный хотфикс - можно мержить без ревью, но ревью этому PR стоит сделать всё-равно, уже после мержа.

• Если адекватное ревью объективно делать некому - напр. разработчик один на проекте или он один владеет этой технологией или предметной областью - точно придётся обойтись без ревью.

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

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

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

Код ревью помимо функции "линтера на стероидах" так же добавляет возможность команде быть в курсе новых фич / багофиксов, быть так сказать в курсе жизнедеятельности проекта.

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

У меня есть контраргумент и я им буду кидаться) Как-то работал сисадмином и одной из рабочих обязанностей было - наполнение нашего раздела на сайте, основанном на самописном движке, застывшем во времени с вечной "0.1" версией. Очередное задание: разместить срочное важное объявление в установленные сроки (это было важно). Проверять результат как-то даже не стал: а какой смысл? С веб-технологиями знаком, а тут всего лишь несильно форматированный блок текста, тем более через админку движка добавленный. Увидел что-то вроде "сохранено" и успокоился.

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

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

О да! Оставляйте "богом забытые углы" без ревью! Скрипт-кидди тоже хотят новый смартфон на рождество и вкусно кушать каждый день :-)

Это особенности внедрения code review.
При правильной организации процедура может быть полезной - найти слабые места, обсудить решение, обменяться мнениями.
Думаю, атмосфера в команде играет роль, чтоб review воспринимался конструктивно.

Опытного тимлида отличает понимание инструментов и стоимости тех или иных решений. В частности стоимость пересмотреть все это очередное бунтарство и перестройка ценой времени, комфорта и удобства многих сотрудников. Вот и выходит, что любые изменения нужно проводить постепенно с оглядкой на всю команду, процессы и прочее. Так сейчас многие толковые компании с PHP плавно переходят на Golang, но и там не всегда все хорошо, так как такой переход сопряжен с переучиванием персонала, вылезанием специфики языка и возникновению колосального технического долга. Так вот я к тому, что тут конечно может "наболело", но в любом случае все эти изменения очень сложные.

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

Речь о идёт о принципе или об аббревиатуре? Если о принципе, то даже книжка есть где рассказано, что он означает, от создателей так сказать.

Исключительно буквальная трактовка - это либо карго-культ в исполнении идиотов, либо симптом аутизма (та или иная форма психологической ригидности), либо характерная когнитивная черта представителей Gen-Z и молодых миллениалов.

Вы с кем из них спорите?

Тайпскрипт вполне себе типизированный язык, компилятор проверяет типы при компиляции.

Да не сказал бы про проще рефакторить. Одно дело когда функция возвращает any, другое - было T, стало T | array<T> , но массив только для какого-то нового юз кейса. Тут пахнет тем, что рефакторинг вообще лучше не затевать, а сделать новую функцию с новым возвращаемым типом и потом поддерживать обе (привет DRY)

например в PHP array_search возвращает строку (значение) если значение найдено, и false если нет

О боже мой. Я, конечно, слыхал в инторнетах, что PHP супер кривой, но вот чтоб прям так. Как до такого вообще можно было додуматься? oO

Мне один товарищ из бека на php присылал JSON следующего вида, если массив пустой был:

{
  "property": "[]"
}

И следующего, если там что-то лежало:

{
  "property":
  {
    1: "first element",
    2: "second element"
  }
}

Я уже несколько лет никак не могу понять, зачем и почему оно такое, а самое главное - что ему мешало сделать нормально

Кажется, перманентно.

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

Дайте угадаю, на сцену выходит $$$mol_query?

В каких случаях смена СУБД может помочь не выбирать между нормализацией и быстродействием?

Дело не в СУБД. Она достаточно мощная и достаточно быстрая. Дело в объемах обрабатываемых данных и требованиями к скорости обработки.

Вот представьте - пишете вы запрос. Правильный со всех точек зрения. И план запроса хороший и все индексами покрывается... Но... выполняется он 3 секунды. А вам говорят что это допустимо. Требования - не более 300мсек. И тут начинаются пляски с бубном - высокоселективные предвыборки, создание (и поддержка актуальности) витрин, денормализация каких-то таблиц...

И часто речь не идет о задачах, которые можно решить одним запросом. Например, писк совпадений по нескольким параметрам в двух БД - одна ~50млн записей, вторая ~300-500тыс записей. Тут уже без распаралллеливания не обойтись. Головное задание делает отбор по одной БД и выкладывает отобранное на конвейер. Откуда данные разбираются 10-ю обработчиками и каждый из них ищет что по какому параметру где совпало (там важна классивкация совпадений - тут совпадение по параметрам 1 и 3, там по параметрам 2 и 5, здесь по параметру 4 и т.п.). Причем, совпадение может быть не прямым - две строки по 250 символов. Но одна на кириллице, вторая на латинице в транслитерации... Или паспорта - 66 09 345876, 6609 345876 и 6609345876 - это одно и то же. Или даты рождения - 12.08.1970, 12 авг 1970, 12-08-1970, 12081970... Т.е. просто сравнить А=Б нельзя, требуется предварительная "нормализация".

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

А дальше работает - не трогай. Первая заповедь связиста

Каждое категоричное утверждение - ложно, включая и это.