Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Очень просто: в проект, за который я отвечаю пытались продавить дерьмо — как обычно через «толерантность» и «нетоксичность». Дерьмо я принял, но сказал, что этот вот компонент — он, теперь, не мой.
То есть получается, что на самом деле вы изначально вы отвечали за этот код, и определение -1 изначально не подходило, просто вы сделали так, чтобы, во-первых, неподходящий подход туда попал, во-вторых в дальнейшем не отвечать за него.
От меня такого комментария вряд ли можно услышать
Я так и не понял, что вы подразумеваете под "называть дерьмо дерьмом". Вы так и пишете или говорите слово "дерьмо" или формулируете в других терминах. Или вы указание на конкретную ошибку называете "называть дерьмо дерьмом".
Потому что кончается всё вот этим
Тут мне непонятно, какая причинно следственная связь, почему, если порекомендовать какой-то способ исправления вы будете исправлять косяки а если не порекомендовать, то не будете. С моей точки зрения, во втором случае меньше шанс получения косяков.
Я обычно в таком случае подробно объясняю почему именно я хочу другой подход, желательно со ссылками на какие-то авторитетные источники, потом переключаюсь в режим когда последущий апдейт код ревью должен стоить больше автору чем мне. Например, находить один косяк за апдейт и репортить его и прекращать дальнейшее ревью на этом. После какого-то количества итераций или я говорю с начальником или автор код ревью и мы аргументируем свою позицию.
Если указана возможность переделки, то начальство обычно на моей стороне, а если говорить "Тут все плохо, но я не знаю, как хорошо", то тут сложнее потому, что непонятно, что делать.
Это если речь идет про что-то чем владеет команда, в которую я вхожу. Если этим владеет другая команда, то мой голос совещательный, но и баги ко мне не приходят.
don’t like the change, but also aren’t responsible for the project long-term
Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Этот вопрос задаёт мне человек, который считает, что называть дерьмо дерьмом — это токсичо и нужно делать намёки? Ну я наделал намёков…
Тут мне непонятно, каким образом из не называния дерьма дерьмом следует что намеки надо делать вообще всегда. Вроде, можно не называя дерьмо дерьмом явно указать способы разрешения проблемы нет?
Хотелось бы, также, уточнить что именно вы подразумеваете под "называть дерьмо дерьмом".
Какие фразы подходят под это:
"Этот код — дерьмо"
"Этот код ненадлежащего качества"
"Вот тут вот такая ошибка. Я думаю, использование X в целом приводит к появлению ошибок такого типа. Рассмотрите, пожалуйста, возможность применить подход Y по такой-то и такой-то причине."
Вариант 3 я считаю приемлемым.
Если я правильно понял, на практике вы намерено сформулировали все так, что человек не понял, что повлекло добавление в продукт большого количества ошибок. При этом вы сами устали от большого колочиства апдейтов код ревью.
А какое было конструктивное замечание при ревью? Если вы давали специально непонятные подсказки как автор мог не залить этот код? Как он мог понять, что ему делать ?
Получается вместо того чтобы просто сообщить это менеджеру напрямую вы сначала с коллегой портите отношения? Или вы это делаете в максимально вежливой форме? Это вообще работает? Как коллега реагирует обычно?
В примере американский ответ содержит чуть меньше конкретики (нет
"пусть твой конструктор принимает репозиторий и сохраняет в свойство объекта") но, наверное, это не намеренно.
В остальном по моим наблюдениям американский способ не обязан быть расплывчатым, просто он менее категоричен и содержит дополнительные вежливые формулы.
Итого, назначением Автотестов является автоматизация ручного Е2Е-тестирования. Это «внешняя» система, которая не принимает участия в процессе разработки тестируемой Системы и никак не связана с модульными или интеграционными тестами, используемыми разработчиками.
То есть вы сами не читали методички, а нам двойки ставите? Какая логика стоит за этим?
Вообще хешкоды возможно где-то внутре для чего-то используются. Но нафига их явно расчитывать если все равно надо будет репортить для красных тестов детали ошибки, чтобы было удобно?
То есть получается, что на самом деле вы изначально вы отвечали за этот код, и определение -1 изначально не подходило, просто вы сделали так, чтобы, во-первых, неподходящий подход туда попал, во-вторых в дальнейшем не отвечать за него.
Я так и не понял, что вы подразумеваете под "называть дерьмо дерьмом". Вы так и пишете или говорите слово "дерьмо" или формулируете в других терминах. Или вы указание на конкретную ошибку называете "называть дерьмо дерьмом".
Тут мне непонятно, какая причинно следственная связь, почему, если порекомендовать какой-то способ исправления вы будете исправлять косяки а если не порекомендовать, то не будете. С моей точки зрения, во втором случае меньше шанс получения косяков.
Я обычно в таком случае подробно объясняю почему именно я хочу другой подход, желательно со ссылками на какие-то авторитетные источники, потом переключаюсь в режим когда последущий апдейт код ревью должен стоить больше автору чем мне. Например, находить один косяк за апдейт и репортить его и прекращать дальнейшее ревью на этом. После какого-то количества итераций или я говорю с начальником или автор код ревью и мы аргументируем свою позицию.
Если указана возможность переделки, то начальство обычно на моей стороне, а если говорить "Тут все плохо, но я не знаю, как хорошо", то тут сложнее потому, что непонятно, что делать.
Это если речь идет про что-то чем владеет команда, в которую я вхожу. Если этим владеет другая команда, то мой голос совещательный, но и баги ко мне не приходят.
Разница между вашим подходом и подходом khim то, что вы предложили как исправить, а он специально сделал так чтобы его не поняли.
Спасибо за ссылку.
Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Тут мне непонятно, каким образом из не называния дерьма дерьмом следует что намеки надо делать вообще всегда. Вроде, можно не называя дерьмо дерьмом явно указать способы разрешения проблемы нет?
Хотелось бы, также, уточнить что именно вы подразумеваете под "называть дерьмо дерьмом".
Какие фразы подходят под это:
Вариант 3 я считаю приемлемым.
Если я правильно понял, на практике вы намерено сформулировали все так, что человек не понял, что повлекло добавление в продукт большого количества ошибок. При этом вы сами устали от большого колочиства апдейтов код ревью.
А какая у этого была цель?
А какое было конструктивное замечание при ревью? Если вы давали специально непонятные подсказки как автор мог не залить этот код? Как он мог понять, что ему делать ?
Что такое неполно реагирует — перестает быть сложные задачи? Если менеджер уже видит почему он не назначении нему задачи полегче?
Получается вместо того чтобы просто сообщить это менеджеру напрямую вы сначала с коллегой портите отношения? Или вы это делаете в максимально вежливой форме? Это вообще работает? Как коллега реагирует обычно?
А как это работает? Вы говорите коллеге "не пиши код" и он перестает его писать? А да что деньги получает?
С моей точки зрения это перпендикулярные понятия.
Например, если вы будете бить кого хочется и не сдерживаться это будет токсичная прямота.
Если вы будете от души благодарить того, кого хочется, это будет нетоксичная прямота.
Из словарей:
...causing you a lot of harm and unhappiness over a long period of time:
toxic parents
a toxic relationship
...extremely harsh, malicious, or harmful
toxic sarcasm
Либо заставляет уйти в программирование от некомфортного взаимодействия с людьми.
В примере американский ответ содержит чуть меньше конкретики (нет
"пусть твой конструктор принимает репозиторий и сохраняет в свойство объекта") но, наверное, это не намеренно.
В остальном по моим наблюдениям американский способ не обязан быть расплывчатым, просто он менее категоричен и содержит дополнительные вежливые формулы.
Это ваше впечатление или результат каких-то расчетов?
Что вот прям ни на секунду не не приводит?
Такое переживание для вас целесообразно и приводит к чему-то конструктивному или вы просто так сами себя мучаете?
А так как большинство людей до конца вообще не взрослеет...
Мне кажется, по вашим критериям лучше подойдут следующие языки:
Forth
Используемые конструкции: слова
Brainfuck
Используемые конструкции: команды, их всего 8 и больше ничего нет
Hello
А мне кажется работает. Потому, что тут не интеллект влияет а эмоции. Как будто у вас зуб не болел :)
Чем? Качество — это скорость в среднесрочной перспективе. Баг, обнаруженный в проде, отнимает время у многих людей
https://habr.com/ru/company/yandex/blog/475382/#comment_20901640
Я так понял, что есть, но пишутся другими людьми
Тут я согласен с vintage единственная проблема — менее читаемое сообщение об ошибке. Будет просто NPE, но это общая проблема для всего кода на Java.
А еще есть Kotlin, который заставить в синтаксисе выразить отношение к Null в конкретном месте.
То есть вы сами не читали методички, а нам двойки ставите? Какая логика стоит за этим?
Вообще хешкоды возможно где-то внутре для чего-то используются. Но нафига их явно расчитывать если все равно надо будет репортить для красных тестов детали ошибки, чтобы было удобно?