Я думаю, те кто даёт задачи с leetcode, выбирают их не случайным образом, а ориентируется на какие-то критерии, вроде топ-N задач на тему X. Вызубрить первые M <= N решений задач по сильно ограниченному набору тем, существенно проще, чем вызубрить всё.
В ситуации, когда в коде есть проблема, на первый раз с небольшими изменениями я заверну ревью на доработку, на второй найду тим-лида и попрошу присоединится к ревью, ибо ситуация требует эскалации. Если это не поможет, то будет инициирован разговор 1-to-1 для объяснения, почему так делать не стоит. Если всё ещё не понятно, то заберу на себя задачу и доработаю (первый и последний раз с данным разработчиком). При повторении ситуации с другой задачей, буду поднимать вопрос о том что делать с таким разработчиком, с описанием всех мер, которые были предприняты, для того чтобы проблема не возникала.
Это касается ситуаций, когда в коде разработчика очевидно есть проблема. Вопрос о форматировании устраняется автоматизированными средствами и Вы просто не сможете залить неотформатированный как требуется код в CVS.
P.S> Если разработчик отправляет откровенный бред на код-ревью своим коллегам, а потом ещё и игнорирует обоснованные замечания, то он не уважает ни себя ни своих коллег.
Ну так это уже не проблема код-ревью, верно? Это проблема подхода команды разработки, которая точно также (спустя рукава) может подойти к любой проблеме.
P.S. Это я к тому, что это не повод избавляться от практики ревью, а повод повысить культуру разработки, чтобы применяемые для повышения качества кода инструменты давали нужный эффект.
Если ревью скатывается к обсуждению "надо ли ставить пустую строку в конце файла", то ревьювер не отвечает за код, ревью которого проводит, либо ССЗБ и в какой-то момент в 3 часа ночи будет в срочном порядке его дебажить, потому что на проде стреляет, а тесты не отловили такой кейс.
Как описали выше, ревью нужно для:
синхронизации знаний о коде между разработчиками.
убедиться, что техническое решение в целом корректно и соответствует требованиям решаемой задачи.
А форматирование и прочее оставьте линтерам и SAST.
Ситуация "стреляет на проде" неизбежна, если Ваш проект живёт дольше недели. Вопрос только в том, как часто такое будет происходить. И юнит-тесты Вас от этого не спасут, потому что также зависят от того, как хорошо разработчики понимают требования. E2E тесты здесь куда лучше, пусть и дороже.
>>И каждый что-то да продолбает - и вот здесь опять нормально составленные юнит-тесты (которые ваш "опытный разработчик" должен быть в состоянии писать и поддерживать) подстрахуют вас от "стрельбы на проде"
Не подстрахует, а потенциально снизит вероятность стрельбы на проде. Тесты тоже нужно уметь писать так, чтобы от них была польза.
Плохо спроектированный код видно и без юнит-тестов, либо взглядом опытного разработчик либо по тому, что на проде стреляет. И может быть стоит просто рефакторить с умом, чем прибегать к юнит-тестам? Банально, проектировать контракты так, чтобы либо недопускать несогласованных состояний системы либо ловить их как можно раньше и что-то с ними делать.
>>Баги на проде не потому что юнит-тесты, а потому что люди плохо понимают как это должно работать и не прописали тест на этот кейс вообще, никакой.
Вот именно поэтому, юнит-тесты и не решают проблемы, можно приучить себя задумываться о сценариях работы и без написания юнит-тестов, а необходимость писать юнит-тесты никак не гарантирует отсутствие плохого понимания требований, не говоря уже о том, что нередко и сам постановщик задачи плохо понимает, что же он хочет.
Тесты часто пишут весьма посредственно, а ещё из-за тестов нередко приходится менять код, и сами тесты тоже нередко ломаются в результате доработок по коду и/или архитектуре. Имхо, юнит-тесты из-за этого можно сразу в утиль, если речь о сложных и больших проектах. Имеет смысл реализовать только интеграционные тесты для критически важных сценариев, в остальном, гораздо лучше полагаться на статическую типизацию и технологии вроде ORM. В шарпе мне нравится работать с linq2db, он невероятно облегчает работу и в большинстве случаев мне даже нет необходимости запускать код, чтобы быть уверенным, что он будет работать как мне нужно.
Я вообще не понимаю вот этого тесты тесты тесты, обмажутся юнит-тестами с ног до головы, а на проде всё равно баг на баге. Вероятно, конечно, что это предвзятое мнение на основе частного опыта, но уж больно часто приходилось подобное слышать/видеть.
Жить не может тоже.
Я думаю, те кто даёт задачи с leetcode, выбирают их не случайным образом, а ориентируется на какие-то критерии, вроде топ-N задач на тему X. Вызубрить первые M <= N решений задач по сильно ограниченному набору тем, существенно проще, чем вызубрить всё.
А почему суд в режиме закрытого заседания не может получить доступ к полной переписке с обоих сторон и оценить согласованность?
Если эти скриншоты переписки ложь, то Маск может подать иск о клевете.
В ситуации, когда в коде есть проблема, на первый раз с небольшими изменениями я заверну ревью на доработку, на второй найду тим-лида и попрошу присоединится к ревью, ибо ситуация требует эскалации. Если это не поможет, то будет инициирован разговор 1-to-1 для объяснения, почему так делать не стоит. Если всё ещё не понятно, то заберу на себя задачу и доработаю (первый и последний раз с данным разработчиком). При повторении ситуации с другой задачей, буду поднимать вопрос о том что делать с таким разработчиком, с описанием всех мер, которые были предприняты, для того чтобы проблема не возникала.
Это касается ситуаций, когда в коде разработчика очевидно есть проблема. Вопрос о форматировании устраняется автоматизированными средствами и Вы просто не сможете залить неотформатированный как требуется код в CVS.
P.S> Если разработчик отправляет откровенный бред на код-ревью своим коллегам, а потом ещё и игнорирует обоснованные замечания, то он не уважает ни себя ни своих коллег.
Ну так это уже не проблема код-ревью, верно? Это проблема подхода команды разработки, которая точно также (спустя рукава) может подойти к любой проблеме.
P.S. Это я к тому, что это не повод избавляться от практики ревью, а повод повысить культуру разработки, чтобы применяемые для повышения качества кода инструменты давали нужный эффект.
Если ревью скатывается к обсуждению "надо ли ставить пустую строку в конце файла", то ревьювер не отвечает за код, ревью которого проводит, либо ССЗБ и в какой-то момент в 3 часа ночи будет в срочном порядке его дебажить, потому что на проде стреляет, а тесты не отловили такой кейс.
Как описали выше, ревью нужно для:
синхронизации знаний о коде между разработчиками.
убедиться, что техническое решение в целом корректно и соответствует требованиям решаемой задачи.
А форматирование и прочее оставьте линтерам и SAST.
Если мне на ревью принесут такой код и на обоснованные замечания ответят в том же стиле, то я такой код в прод просто не пущу.
UPD: Какой там прод, даже на тестирование не пущу. Ибо время тестировщиков можно потратить более полезным образом.
Мои вопросы как бы намекают на то, что не хватило бы никаких денег, потому что дело вовсе не в объёме выделенных денег. Но да ладно.
А куда дели те млрд рублей, которые выделяли на замену множества труб отопления в предыдущие 10-15 лет и почему их не хватило?
JB Rider конечно! Имхо, отличная IDE.
А если это ещё и опечатка в каком-нибудь merge into или большом update, то это уже и не птичка, а здоровый такой птеродактиль.
linq2db/linq2db: Linq to database provider. (github.com) пробовали?
Ситуация "стреляет на проде" неизбежна, если Ваш проект живёт дольше недели. Вопрос только в том, как часто такое будет происходить. И юнит-тесты Вас от этого не спасут, потому что также зависят от того, как хорошо разработчики понимают требования. E2E тесты здесь куда лучше, пусть и дороже.
>>И каждый что-то да продолбает - и вот здесь опять нормально составленные юнит-тесты (которые ваш "опытный разработчик" должен быть в состоянии писать и поддерживать) подстрахуют вас от "стрельбы на проде"
Не подстрахует, а потенциально снизит вероятность стрельбы на проде. Тесты тоже нужно уметь писать так, чтобы от них была польза.
Плохо спроектированный код видно и без юнит-тестов, либо взглядом опытного разработчик либо по тому, что на проде стреляет. И может быть стоит просто рефакторить с умом, чем прибегать к юнит-тестам? Банально, проектировать контракты так, чтобы либо недопускать несогласованных состояний системы либо ловить их как можно раньше и что-то с ними делать.
>>Баги на проде не потому что юнит-тесты, а потому что люди плохо понимают как это должно работать и не прописали тест на этот кейс вообще, никакой.
Вот именно поэтому, юнит-тесты и не решают проблемы, можно приучить себя задумываться о сценариях работы и без написания юнит-тестов, а необходимость писать юнит-тесты никак не гарантирует отсутствие плохого понимания требований, не говоря уже о том, что нередко и сам постановщик задачи плохо понимает, что же он хочет.
Тесты часто пишут весьма посредственно, а ещё из-за тестов нередко приходится менять код, и сами тесты тоже нередко ломаются в результате доработок по коду и/или архитектуре. Имхо, юнит-тесты из-за этого можно сразу в утиль, если речь о сложных и больших проектах. Имеет смысл реализовать только интеграционные тесты для критически важных сценариев, в остальном, гораздо лучше полагаться на статическую типизацию и технологии вроде ORM. В шарпе мне нравится работать с linq2db, он невероятно облегчает работу и в большинстве случаев мне даже нет необходимости запускать код, чтобы быть уверенным, что он будет работать как мне нужно.
Я вообще не понимаю вот этого тесты тесты тесты, обмажутся юнит-тестами с ног до головы, а на проде всё равно баг на баге. Вероятно, конечно, что это предвзятое мнение на основе частного опыта, но уж больно часто приходилось подобное слышать/видеть.
Есть мнение, что как только винду повсюду начнут заменять на linux, то количество эксплойтов для уязвимостей в оном тоже начнёт расти.
А любой медик конечно же занимается тем, что и операцию на мозге проводит и анализы делает и любой орган твой обследует.
Значит требования к нему у Вас не менялись никогда, такое бывает далеко не всегда и не со всеми.
Ну вперёд Минцифры, и с песней. С экономикой ведь всё хорошо, никаких проблем нет, можно на бизнес и посильнее надавить.