Я считаю, что есть компании лучше, чем FAANG. И, конечно, если ты работаешь не в самой идеальной компании, это не повод что-то менять. Изменения всегда имеют цену и совершенно не факт, что выгода от изменений превысит эту цену. Наконец, в человеческом мире ни цену, ни выгоду нормально не измеришь не только заранее, но и постфактум. Остаётся лишь гадать. Иногда лучше не гадать, а сидеть на попе ровно. На идеальной работе свет клином не сошёлся, в мире есть много других интересных дел, куда можно направить свою энергию. Возможно, вы из тех людей, которым карьера важнее всего. Но не все люди таковы, и обобщать не следует.
Верно, на структуру зарплаты (сколько оклад, сколько премия) обязательно обращать внимание при устройстве на работу. По-хорошему это должно быть прописано в изначальном оффере.
Я думаю, ML не должен заменять традиционный статический анализ, а должен усиливать его слабые стороны. Слабые стороны — это эвристические инспекции. Иногда нормально не заскриптуешь ошибочную ситуацию и абстрактной интерпретацией её не решишь. Например, пользователь в коде обработки графики передаёт в какой-то метод x там, где параметр называется y, и наоборот. Выглядит подозрительно. Давайте ругаться, если имя формального параметра y, а фактически передаётся переменная с именем x (или x1, или xx, или boundX). Окей, работает, нашли пару багов. Релизнули, пользователи начали жаловаться:
System.out.println(y);
Собака, метод PrintStream#println почему-то обозначил свой параметр буквой x! Добавляем исключение. Далее видим такой код:
return new Point(y, -x);
Здесь речь действительно о координатах, и действительно где ожидается x, передаётся y. Вот только полный код:
if(rotate90DegreesClockwise) {
return new Point(y, -x);
}
Понятно, что никакой ошибки нет. И так далее. Получается очень хрупкая инспекция, у которой большой процент FP/FN и нужно скриптовать кучу случаев. Причём часто вокруг не стандартные методы API, а какие-то сторонние библиотеки или вообще классы пользовательского приложения. И это только про перепутанные x и y, а можно ведь и многие другие имена путать. В таких случаях, мне кажется, натравить ML на кодовую базу, чтобы моделька обучилась с учётом контекста какие комбинации формального и фактического параметра верные, а какие ошибочные, было бы вполне разумно.
Мозги напрягать, придумывать хорошие тесты, ревьювить свой же код перед коммитом, изучить лучшие практики программирования на вашем языке, инструменты для рефакторинга. Если всего этого раньше не делалось или делалось нерегулярно, то производительность легко вырастет вдвое в том смысле, что будет меньше багов.
Несложно с заменой. Дают контроффер, но прибавку дают в виде премии, сказав, что менять сетку зарплат посреди года — сложно и муторно. Когда находят замену, нанимают нового человека на новую ставку, вам премию срезают, сказав, что ничего не было. Вы от такой наглости сами уходите, вашу ставку закрывают.
Давненько вы нас покинули :-) Понятие КЗоТ исчезло в 2002-м году, сменившись на ТК. Сейчас многие компании платят в белую, оформляют официально, уважают отпуска, больничные и прочее. Ну и подпортить компании карму, накапав в налоговую, стало гораздо проще.
А можно просто уметь это делать и находить сотни подобных интересных срабатываний, как это делает PVS-Studio
Я согласен, что это интересное срабатывание для вас, и вы наверняка гордитесь таким межпроцедурным анализом, это всё понятно. Вопрос в том, есть ли от него польза пользователям. Где-то в другом месте может быть и есть, но здесь это кажется лишним шумом.
Довольно очевидно, что серьёзной ошибки здесь нет. Во-первых, перепутанные x и y поменяют направление вращения. Если бы что-то вращалось не в ту сторону, то либо это бы сразу заметили, либо в принципе направление вращения здесь не важно (в играх такое вполне бывает). Я могу предположить, что автор действительно не разобрался, какие аргументы принимает Atan2, но потом добавил приседания с минусом и вычитанием 90 градусов, чтобы подогнать под требуемый результат. То есть формулу можно упростить, но понятно, что ошибки тут нет. Вообще когда речь идёт о вращениях на плоскости, x и y могут запросто переставиться. Такое эмпирическое предупреждение всегда шито белыми нитками.
Ну такой межпроцедурный анализ — это, конечно, круто, но кажется, что вместо всего этого надо просто выдать один варнинг внутри updateResult:
return Judged; // value is always false
Ну можно на весь метод updateResult ругнуться, что он всегда возвращает false. Но протаскивать эту информацию на каждую точку вызова кажется довольно нелепо. Программирование — это про абстракцию и инкапсуляцию. Поведение updateResult инкапсулировано, по контракту (возвращаемый тип bool — это контракт) он может возвращать разное значение. Неочевидно, что стоит выдавать какие-то варнинги в точках вызова, это только шум. Точки вызова должны быть готовы к любой допустимой контрактом реализации метода.
Интересны слова с второстепенным ударением. Например, syntax. Тут не просто сИнтэкс, как многие русские произносят, а /ˈsinˌtaks/, ударение на втором слоге отчётливо слышно.
После установления точной границы интересное предложение исследования — сделать хотя бы один свитч по этому енаму. Хоть бы и пустой. Сработает? Или придётся лимит ещё снижать?
Я отжимал отвёрткой такой замок как на последней картинке в статье. Комбинацию так и не узнал (пробовали перебирать, безуспешно). Теперь просто навесным закрываем. После этой статьи можно попробовать, конечно. Но отвёрткой отжать реально несложно.
Думаешь, мы подрались бы? Вряд ли :-)
Я считаю, что есть компании лучше, чем FAANG. И, конечно, если ты работаешь не в самой идеальной компании, это не повод что-то менять. Изменения всегда имеют цену и совершенно не факт, что выгода от изменений превысит эту цену. Наконец, в человеческом мире ни цену, ни выгоду нормально не измеришь не только заранее, но и постфактум. Остаётся лишь гадать. Иногда лучше не гадать, а сидеть на попе ровно. На идеальной работе свет клином не сошёлся, в мире есть много других интересных дел, куда можно направить свою энергию. Возможно, вы из тех людей, которым карьера важнее всего. Но не все люди таковы, и обобщать не следует.
Верно, на структуру зарплаты (сколько оклад, сколько премия) обязательно обращать внимание при устройстве на работу. По-хорошему это должно быть прописано в изначальном оффере.
Интересненько, хоть и много букв.
Я думаю, ML не должен заменять традиционный статический анализ, а должен усиливать его слабые стороны. Слабые стороны — это эвристические инспекции. Иногда нормально не заскриптуешь ошибочную ситуацию и абстрактной интерпретацией её не решишь. Например, пользователь в коде обработки графики передаёт в какой-то метод
xтам, где параметр называетсяy, и наоборот. Выглядит подозрительно. Давайте ругаться, если имя формального параметраy, а фактически передаётся переменная с именемx(илиx1, илиxx, илиboundX). Окей, работает, нашли пару багов. Релизнули, пользователи начали жаловаться:Собака, метод PrintStream#println почему-то обозначил свой параметр буквой
x! Добавляем исключение. Далее видим такой код:Здесь речь действительно о координатах, и действительно где ожидается
x, передаётсяy. Вот только полный код:Понятно, что никакой ошибки нет. И так далее. Получается очень хрупкая инспекция, у которой большой процент FP/FN и нужно скриптовать кучу случаев. Причём часто вокруг не стандартные методы API, а какие-то сторонние библиотеки или вообще классы пользовательского приложения. И это только про перепутанные
xиy, а можно ведь и многие другие имена путать. В таких случаях, мне кажется, натравить ML на кодовую базу, чтобы моделька обучилась с учётом контекста какие комбинации формального и фактического параметра верные, а какие ошибочные, было бы вполне разумно.Либо не замираешь, с компанией ничего не происходит, а если происходит, находишь другую работу и не паришься.
Мозги напрягать, придумывать хорошие тесты, ревьювить свой же код перед коммитом, изучить лучшие практики программирования на вашем языке, инструменты для рефакторинга. Если всего этого раньше не делалось или делалось нерегулярно, то производительность легко вырастет вдвое в том смысле, что будет меньше багов.
Несложно с заменой. Дают контроффер, но прибавку дают в виде премии, сказав, что менять сетку зарплат посреди года — сложно и муторно. Когда находят замену, нанимают нового человека на новую ставку, вам премию срезают, сказав, что ничего не было. Вы от такой наглости сами уходите, вашу ставку закрывают.
Давненько вы нас покинули :-) Понятие КЗоТ исчезло в 2002-м году, сменившись на ТК. Сейчас многие компании платят в белую, оформляют официально, уважают отпуска, больничные и прочее. Ну и подпортить компании карму, накапав в налоговую, стало гораздо проще.
Откуда статистика?
Что подтверждает тезис о том, что большинство сотрудников уходит через 6-12 месяцев после выставления контроффера.
Почему "в любом случае"? Я считаю, что не в любом.
Нет-нет, один пустой свитч :-) А чего ты гадаешь вообще? Кодогенератор тривиально написать и установить граница экспериментально.
Я согласен, что это интересное срабатывание для вас, и вы наверняка гордитесь таким межпроцедурным анализом, это всё понятно. Вопрос в том, есть ли от него польза пользователям. Где-то в другом месте может быть и есть, но здесь это кажется лишним шумом.
Довольно очевидно, что серьёзной ошибки здесь нет. Во-первых, перепутанные x и y поменяют направление вращения. Если бы что-то вращалось не в ту сторону, то либо это бы сразу заметили, либо в принципе направление вращения здесь не важно (в играх такое вполне бывает). Я могу предположить, что автор действительно не разобрался, какие аргументы принимает Atan2, но потом добавил приседания с минусом и вычитанием 90 градусов, чтобы подогнать под требуемый результат. То есть формулу можно упростить, но понятно, что ошибки тут нет. Вообще когда речь идёт о вращениях на плоскости, x и y могут запросто переставиться. Такое эмпирическое предупреждение всегда шито белыми нитками.
Ну такой межпроцедурный анализ — это, конечно, круто, но кажется, что вместо всего этого надо просто выдать один варнинг внутри updateResult:
Ну можно на весь метод updateResult ругнуться, что он всегда возвращает false. Но протаскивать эту информацию на каждую точку вызова кажется довольно нелепо. Программирование — это про абстракцию и инкапсуляцию. Поведение updateResult инкапсулировано, по контракту (возвращаемый тип bool — это контракт) он может возвращать разное значение. Неочевидно, что стоит выдавать какие-то варнинги в точках вызова, это только шум. Точки вызова должны быть готовы к любой допустимой контрактом реализации метода.
Тут тоже второстепенное ударение, как в syntax.
Интересны слова с второстепенным ударением. Например, syntax. Тут не просто сИнтэкс, как многие русские произносят, а /ˈsinˌtaks/, ударение на втором слоге отчётливо слышно.
После установления точной границы интересное предложение исследования — сделать хотя бы один свитч по этому енаму. Хоть бы и пустой. Сработает? Или придётся лимит ещё снижать?
Почему от таможни? От случайных прохожих. Таможня-то понятно что откроет, если надо.
Я отжимал отвёрткой такой замок как на последней картинке в статье. Комбинацию так и не узнал (пробовали перебирать, безуспешно). Теперь просто навесным закрываем. После этой статьи можно попробовать, конечно. Но отвёрткой отжать реально несложно.