don’t like the change, but also aren’t responsible for the project long-term
Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Этот вопрос задаёт мне человек, который считает, что называть дерьмо дерьмом — это токсичо и нужно делать намёки? Ну я наделал намёков…
Тут мне непонятно, каким образом из не называния дерьма дерьмом следует что намеки надо делать вообще всегда. Вроде, можно не называя дерьмо дерьмом явно указать способы разрешения проблемы нет?
Хотелось бы, также, уточнить что именно вы подразумеваете под "называть дерьмо дерьмом".
Какие фразы подходят под это:
"Этот код — дерьмо"
"Этот код ненадлежащего качества"
"Вот тут вот такая ошибка. Я думаю, использование X в целом приводит к появлению ошибок такого типа. Рассмотрите, пожалуйста, возможность применить подход Y по такой-то и такой-то причине."
Вариант 3 я считаю приемлемым.
Если я правильно понял, на практике вы намерено сформулировали все так, что человек не понял, что повлекло добавление в продукт большого количества ошибок. При этом вы сами устали от большого колочиства апдейтов код ревью.
А какое было конструктивное замечание при ревью? Если вы давали специально непонятные подсказки как автор мог не залить этот код? Как он мог понять, что ему делать ?
Получается вместо того чтобы просто сообщить это менеджеру напрямую вы сначала с коллегой портите отношения? Или вы это делаете в максимально вежливой форме? Это вообще работает? Как коллега реагирует обычно?
В примере американский ответ содержит чуть меньше конкретики (нет
"пусть твой конструктор принимает репозиторий и сохраняет в свойство объекта") но, наверное, это не намеренно.
В остальном по моим наблюдениям американский способ не обязан быть расплывчатым, просто он менее категоричен и содержит дополнительные вежливые формулы.
Итого, назначением Автотестов является автоматизация ручного Е2Е-тестирования. Это «внешняя» система, которая не принимает участия в процессе разработки тестируемой Системы и никак не связана с модульными или интеграционными тестами, используемыми разработчиками.
То есть вы сами не читали методички, а нам двойки ставите? Какая логика стоит за этим?
Вообще хешкоды возможно где-то внутре для чего-то используются. Но нафига их явно расчитывать если все равно надо будет репортить для красных тестов детали ошибки, чтобы было удобно?
Реальные ситуации бывают разные. В каких-то случаях проще сравнить весь объект. Например сортировку каких-то списков или копирование удобно сравнивать целиком.
И да, в продвинутых хелперах есть разные режимы сравнения, чтобы формулировать свои требования типа "все свойства должны быть такие же, кроме этого"
Разница между вашим подходом и подходом 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 в конкретном месте.
То есть вы сами не читали методички, а нам двойки ставите? Какая логика стоит за этим?
Вообще хешкоды возможно где-то внутре для чего-то используются. Но нафига их явно расчитывать если все равно надо будет репортить для красных тестов детали ошибки, чтобы было удобно?
Реальные ситуации бывают разные. В каких-то случаях проще сравнить весь объект. Например сортировку каких-то списков или копирование удобно сравнивать целиком.
И да, в продвинутых хелперах есть разные режимы сравнения, чтобы формулировать свои требования типа "все свойства должны быть такие же, кроме этого"