ApeCoder ApeCoder

но у нас сейчас нет данных, сколько попыток внятного корректного объяснения с необходимыми подсказками было сделано до того.

Даже если учеcть это, зачем специально сообщать путь разрешения проблемы специально непонятно для автора? Почему он не был понятно описан в предыдущих коммуникациях?

Это сказано не было

Теперь уточнил

Я это поддерживаю, такие проблемы должны вскрываться как можно раньше.

С моей точки зрения "как можно раньше" это во время код ревью. Я бы постарался помочь на code review — т.е. дал бы пояснение как исправить как можно понятнее, а не специально так, чтобы он не понял.

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

Т.е. капал бы на мозги начальству и команде.

Откуда это «вы сделали так, чтобы неподходящий код туда попал»?

Кто сделал «так, чтобы неподходящий код туда попал»?

khim "Пытался человеку «помочь» (давая ему ровно достаточно подсказок, чтобы они ничерта не понял, но чтобы знающий человек мог это сделать)"

То есть как я понял цель была, чтобы конкретный человек не понял соответственно не исправил косяк, косяк попал к клиенту, потом бы компания тратила время на его исправление, но не сам khim

маловероятно, что такой автор сразу заметит и исправит все ошибки

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

До такого очень редко доходит.

Для смежных компонент это нормальная ситуация, что спрашивают и других людей

Я имел ввиду не приходят на исправление. Конечно некоторое время тратится на то, чтобы выяснить в каком компоненте ошибка, да.

Всякое, конечно, бывает. Но, с моей точки зрения, попытаться хотя бы стоит.

Но при этом он не обязательно является мейнтейнером конкретно этой подсистемы или хозяином проекта в целом,

А как тогда баги к нему потом приходят?

Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.
Очень просто: в проект, за который я отвечаю пытались продавить дерьмо — как обычно через «толерантность» и «нетоксичность». Дерьмо я принял, но сказал, что этот вот компонент — он, теперь, не мой.

То есть получается, что на самом деле вы изначально вы отвечали за этот код, и определение -1 изначально не подходило, просто вы сделали так, чтобы, во-первых, неподходящий подход туда попал, во-вторых в дальнейшем не отвечать за него.

От меня такого комментария вряд ли можно услышать

Я так и не понял, что вы подразумеваете под "называть дерьмо дерьмом". Вы так и пишете или говорите слово "дерьмо" или формулируете в других терминах. Или вы указание на конкретную ошибку называете "называть дерьмо дерьмом".

Потому что кончается всё вот этим

Тут мне непонятно, какая причинно следственная связь, почему, если порекомендовать какой-то способ исправления вы будете исправлять косяки а если не порекомендовать, то не будете. С моей точки зрения, во втором случае меньше шанс получения косяков.

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

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

Это если речь идет про что-то чем владеет команда, в которую я вхожу. Если этим владеет другая команда, то мой голос совещательный, но и баги ко мне не приходят.

Разница между вашим подходом и подходом khim то, что вы предложили как исправить, а он специально сделал так чтобы его не поняли.

Спасибо за ссылку.

don’t like the change, but also aren’t responsible for the project long-term

Тут мне не очень понятно, как одновременно вы не ответственны за проект и вам приходят багрепорты на него.

Этот вопрос задаёт мне человек, который считает, что называть дерьмо дерьмом — это токсичо и нужно делать намёки? Ну я наделал намёков…

Тут мне непонятно, каким образом из не называния дерьма дерьмом следует что намеки надо делать вообще всегда. Вроде, можно не называя дерьмо дерьмом явно указать способы разрешения проблемы нет?

Хотелось бы, также, уточнить что именно вы подразумеваете под "называть дерьмо дерьмом".

Какие фразы подходят под это:

1. "Этот код — дерьмо"
2. "Этот код ненадлежащего качества"
3. "Вот тут вот такая ошибка. Я думаю, использование X в целом приводит к появлению ошибок такого типа. Рассмотрите, пожалуйста, возможность применить подход Y по такой-то и такой-то причине."

Вариант 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

.( Hello world )

Используемые конструкции: слова

Brainfuck

+[-[<<[+[--->]-[<<<]]]>>>-]>-.---.>..>.<<<<-.<+.>>>>>.>.<<.<-.

Используемые конструкции: команды, их всего 8 и больше ничего нет

Hello

h

А мне кажется работает. Потому, что тут не интеллект влияет а эмоции. Как будто у вас зуб не болел :)

Чем? Качество — это скорость в среднесрочной перспективе. Баг, обнаруженный в проде, отнимает время у многих людей

https://habr.com/ru/company/yandex/blog/475382/#comment_20901640

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

Итого, назначением Автотестов является автоматизация ручного Е2Е-тестирования. Это «внешняя» система, которая не принимает участия в процессе разработки тестируемой Системы и никак не связана с модульными или интеграционными тестами, используемыми разработчиками.

Тут я согласен с vintage единственная проблема — менее читаемое сообщение об ошибке. Будет просто NPE, но это общая проблема для всего кода на Java.

А еще есть Kotlin, который заставить в синтаксисе выразить отношение к Null в конкретном месте.

То есть вы сами не читали методички, а нам двойки ставите? Какая логика стоит за этим?

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

Реальные ситуации бывают разные. В каких-то случаях проще сравнить весь объект. Например сортировку каких-то списков или копирование удобно сравнивать целиком.

И да, в продвинутых хелперах есть разные режимы сравнения, чтобы формулировать свои требования типа "все свойства должны быть такие же, кроме этого"

А вы пытались аргументировано поговорить с руководством? Ваша работа вообще нужна кому-то?

Профессор, а какой ответ правильный-то? Какую методичку почитать и в каком месте?

А если организовать все так, что в логе будет написано?

Всякие же быстрые способы — рекурсивные рефлексии по полям, контрольные суммы и прочее приводит к тому, что нужно перезапускать, пересматривать глазами и т.п.

Почему рекурсивные рефлексии приводят к тому, что надо перезапускать?

У вас есть code review?

Рассказать начальству?

Тест должен давать понятный результат, поэтому я не использую контрольную сумму. Я использую либо проверку конкретных свойств объекта, либо сравнение на тот же самый экземпляр, либо структурную эквивалентность.

Ну как объяснить

так!

Мы обсуждаем что есть тестовая пирамида, а не какова ее цель, например:

Stick to the pyramid shape to come up with a healthy, fast and maintainable test suite: Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end. Watch out that you don't end up with a test ice-cream cone that will be a nightmare to maintain and takes way too long to run.

В тесте мы передаём M2

А если передаем M3? В некотором исключительном случае.

в вашей системе терминологии
Это не моя терминология.

Ок — в истинной системе терминологии, как ее понимают вы и другие люди, которые думают своей головой а не фанатики, читающие священные книги. Это какой тест?

А компонентный тест не подразумевает что он должен обращаться с некоторым компонентом как с целым? Т.е. это должен быть некоторый набор модулей, который именно в таком виде используется в prod и обладает каким-то общим интерфейсом, а то, о чем мы говорим здесь по вашей терминологии скорее специфический интеграционный тест.

Допустим у нас есть модули M1, M2 и M3. M2 и M3 реализуют интерфейс I. M1 используют интерфейс I.

В проде M1 всегда получает M2. В тесте мы передаем ему M3.
Тест сформулирован в терминах требований к M1.

Это в вашей системе терминологии:

1. Компонентный тест (если да, то для какого компонента чего)?
2. Модульный тест?
3. Интеграционный тест?

То есть важно не то, что "ошибка во втором модуле может завалить ваш тест." а то, что является объектом тестирования?

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

Купить дизель-генератор для проверки лампочки :)

Не поможет — в софтверной вселенной vintage это станет тестом дизель-генератора и лампочки.

Объектом тестирования выступает поведение, а не юнит.

Без спойлеров, пожалуйта, мне интересна логика vintage а вы ее можете испортить своими "священными писаниями" подобно тому как европейская фауна портит австралийскую. Давайте введем мыслекарантин!

"Вы лучше свой головой подумайте"

Как он изолирует от моей ТЭЦ? Только если он подключен к другой ТЭЦ — это маловероятно так как я обычно покупаю лампочки в ближайших магазинах. Во-вторых, даже если она изолирует от моей ТЭЦ она подключена к другой ТЭЦ. Так что если употреблять тот же принцип в реальном мире, вы должны спрашивать "разрешите протестировать вашу ТЕЦ, цоколь, провода и лампочку". Почему вы так не делаете?

Вообще, аналогии из физического мира тут не к месту.

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

Может быть разберемся почему?

Например, на основании какого принципа вы называете тестированием именно лампочки процесс который даст сбой при отказе ТЭЦ? Почему вы его не называете тестированием ТЭЦ?