Это проблема границ кодовой базы, там где она соприкасается с другой кодовой базой посредством API. Если код на разных языках или API использует сериализацию, то такое компилятор естественно не найдёт. Однако, в пределах одной кодовой базы компилятор проверит согласованность.
Согласованность API между кодовыми базами – всегда было и остаётся обязанностью разработчиков. С компилятором мне достаточно проверить только стыки, это заметно проще, чем надеяться, что я ничего не упустил в рамках всей базы.
Без ошибок компиляции – да, если речь о коде, который попадает в remote branch. Я думаю о бизнес-логике, а о том, чтобы я не передал метры, там где ожидаются футы - заботится компилятор.
Нет ошибок компиляции, говорит о том, что в рамках того, что способен проверить компилятор - типы данных согласованы. Если писать на статически типизированном языке игнорируя типы, то толку конечно не будет, но если использовать систему типов по прямому назначению, то можно отсеять некоторые классы ошибок уже на этапе компиляции.
Если вы не собираетесь заниматься поддержкой проекта в перспективе 5-10 лет или получить по лбу от тех, кто будет заниматься поддержкой проекта после вас, то стоит использовать TS.
А если вы пишете write-only код для proof-of-concept, то конечно можно и JS обойтись.
Вы употребляете фразы вроде "Здешние шавки", делаете категоричные заявления, и жалуетесь, что вас минусуют? Вы странный.
Что касается проекта, который вы поддерживали в течение 2-х лет и деплоящийся за 400 мс, то складывается впечатление, что это не серьёзный проект, а одностраничник с парой кнопок. А сколько релизов было за эти 2 года?
На серьёзных проектах, проблемы начинают ощущаться на горизонте либо 5 лет либо при интенсивной разработке уже до 5 лет. Либо вы помимо этого проекта должны заниматься ещё минимум 3-4 проектами, чтобы в голове не умещалась вся модель оного.
Я думаю, те кто даёт задачи с leetcode, выбирают их не случайным образом, а ориентируется на какие-то критерии, вроде топ-N задач на тему X. Вызубрить первые M <= N решений задач по сильно ограниченному набору тем, существенно проще, чем вызубрить всё.
В ситуации, когда в коде есть проблема, на первый раз с небольшими изменениями я заверну ревью на доработку, на второй найду тим-лида и попрошу присоединится к ревью, ибо ситуация требует эскалации. Если это не поможет, то будет инициирован разговор 1-to-1 для объяснения, почему так делать не стоит. Если всё ещё не понятно, то заберу на себя задачу и доработаю (первый и последний раз с данным разработчиком). При повторении ситуации с другой задачей, буду поднимать вопрос о том что делать с таким разработчиком, с описанием всех мер, которые были предприняты, для того чтобы проблема не возникала.
Это касается ситуаций, когда в коде разработчика очевидно есть проблема. Вопрос о форматировании устраняется автоматизированными средствами и Вы просто не сможете залить неотформатированный как требуется код в CVS.
P.S> Если разработчик отправляет откровенный бред на код-ревью своим коллегам, а потом ещё и игнорирует обоснованные замечания, то он не уважает ни себя ни своих коллег.
Ну так это уже не проблема код-ревью, верно? Это проблема подхода команды разработки, которая точно также (спустя рукава) может подойти к любой проблеме.
P.S. Это я к тому, что это не повод избавляться от практики ревью, а повод повысить культуру разработки, чтобы применяемые для повышения качества кода инструменты давали нужный эффект.
Если ревью скатывается к обсуждению "надо ли ставить пустую строку в конце файла", то ревьювер не отвечает за код, ревью которого проводит, либо ССЗБ и в какой-то момент в 3 часа ночи будет в срочном порядке его дебажить, потому что на проде стреляет, а тесты не отловили такой кейс.
Как описали выше, ревью нужно для:
синхронизации знаний о коде между разработчиками.
убедиться, что техническое решение в целом корректно и соответствует требованиям решаемой задачи.
А форматирование и прочее оставьте линтерам и SAST.
del
Это проблема границ кодовой базы, там где она соприкасается с другой кодовой базой посредством API. Если код на разных языках или API использует сериализацию, то такое компилятор естественно не найдёт. Однако, в пределах одной кодовой базы компилятор проверит согласованность.
Согласованность API между кодовыми базами – всегда было и остаётся обязанностью разработчиков.
С компилятором мне достаточно проверить только стыки, это заметно проще, чем надеяться, что я ничего не упустил в рамках всей базы.
Вы боитесь транспиляции, как я понял. Почему?
Без ошибок компиляции – да, если речь о коде, который попадает в remote branch. Я думаю о бизнес-логике, а о том, чтобы я не передал метры, там где ожидаются футы - заботится компилятор.
Нет ошибок компиляции, говорит о том, что в рамках того, что способен проверить компилятор - типы данных согласованы. Если писать на статически типизированном языке игнорируя типы, то толку конечно не будет, но если использовать систему типов по прямому назначению, то можно отсеять некоторые классы ошибок уже на этапе компиляции.
А в чём проблема транспиляции?
Если вы не собираетесь заниматься поддержкой проекта в перспективе 5-10 лет или получить по лбу от тех, кто будет заниматься поддержкой проекта после вас, то стоит использовать TS.
А если вы пишете write-only код для proof-of-concept, то конечно можно и JS обойтись.
Вы употребляете фразы вроде "Здешние шавки", делаете категоричные заявления, и жалуетесь, что вас минусуют? Вы странный.
Что касается проекта, который вы поддерживали в течение 2-х лет и деплоящийся за 400 мс, то складывается впечатление, что это не серьёзный проект, а одностраничник с парой кнопок. А сколько релизов было за эти 2 года?
На серьёзных проектах, проблемы начинают ощущаться на горизонте либо 5 лет либо при интенсивной разработке уже до 5 лет. Либо вы помимо этого проекта должны заниматься ещё минимум 3-4 проектами, чтобы в голове не умещалась вся модель оного.
Как долго вы поддерживали эти 5 проектов и какого рода поддержку выполняли?
Жить не может тоже.
Я думаю, те кто даёт задачи с leetcode, выбирают их не случайным образом, а ориентируется на какие-то критерии, вроде топ-N задач на тему X. Вызубрить первые M <= N решений задач по сильно ограниченному набору тем, существенно проще, чем вызубрить всё.
А почему суд в режиме закрытого заседания не может получить доступ к полной переписке с обоих сторон и оценить согласованность?
Если эти скриншоты переписки ложь, то Маск может подать иск о клевете.
В ситуации, когда в коде есть проблема, на первый раз с небольшими изменениями я заверну ревью на доработку, на второй найду тим-лида и попрошу присоединится к ревью, ибо ситуация требует эскалации. Если это не поможет, то будет инициирован разговор 1-to-1 для объяснения, почему так делать не стоит. Если всё ещё не понятно, то заберу на себя задачу и доработаю (первый и последний раз с данным разработчиком). При повторении ситуации с другой задачей, буду поднимать вопрос о том что делать с таким разработчиком, с описанием всех мер, которые были предприняты, для того чтобы проблема не возникала.
Это касается ситуаций, когда в коде разработчика очевидно есть проблема. Вопрос о форматировании устраняется автоматизированными средствами и Вы просто не сможете залить неотформатированный как требуется код в CVS.
P.S> Если разработчик отправляет откровенный бред на код-ревью своим коллегам, а потом ещё и игнорирует обоснованные замечания, то он не уважает ни себя ни своих коллег.
Ну так это уже не проблема код-ревью, верно? Это проблема подхода команды разработки, которая точно также (спустя рукава) может подойти к любой проблеме.
P.S. Это я к тому, что это не повод избавляться от практики ревью, а повод повысить культуру разработки, чтобы применяемые для повышения качества кода инструменты давали нужный эффект.
Если ревью скатывается к обсуждению "надо ли ставить пустую строку в конце файла", то ревьювер не отвечает за код, ревью которого проводит, либо ССЗБ и в какой-то момент в 3 часа ночи будет в срочном порядке его дебажить, потому что на проде стреляет, а тесты не отловили такой кейс.
Как описали выше, ревью нужно для:
синхронизации знаний о коде между разработчиками.
убедиться, что техническое решение в целом корректно и соответствует требованиям решаемой задачи.
А форматирование и прочее оставьте линтерам и SAST.
Если мне на ревью принесут такой код и на обоснованные замечания ответят в том же стиле, то я такой код в прод просто не пущу.
UPD: Какой там прод, даже на тестирование не пущу. Ибо время тестировщиков можно потратить более полезным образом.
Мои вопросы как бы намекают на то, что не хватило бы никаких денег, потому что дело вовсе не в объёме выделенных денег. Но да ладно.
А куда дели те млрд рублей, которые выделяли на замену множества труб отопления в предыдущие 10-15 лет и почему их не хватило?
JB Rider конечно! Имхо, отличная IDE.