Comments 12
Статьи сгенерированные из вывода N сообщений статического анализатора натравленного на какойто проект имхо скучные и друг от друга ничем не отличаются. Их можно генерировать без участия человека с помощью чатгпт и написать об этом статью. А все остальные прекрасны.
Скорее эти статьи одно-двухразовые. Первые было интересно, потом читал "как быстро я найду ошибку сам", потом просто пролистывал "а вдруг за что глаз зацепится". То есть те, кто еще их не видел -- даже с интересом прочтут.
А так, хотелось бы больше жЫру про внутренности логики. Какие фишки для паттерн матчинга деревьев взяли? Как сохранили выравнивание в AST но не набрали сложности в матчинге? Как поддерживаете скорость работы для действительно сложных случаев?
И прочие вещи, которые очевидны пока за них не берёшься, потом кажутся невозможными, но ты их все равно делаешь и тогда понимаешь что они были не очевидны -- но разгрызаемы. Вот такое я люблю!
Согласен: у таких статей есть проблема однообразия. Мы стараемся как-то обыгрывать ошибки, экспериментируем с подачей материала и так далее. Но не всегда получается. С другой стороны, такие регулярные статьи про проверку проектов всё равно нужны.
Они вновь и вновь демонстрируют пользу анализаторов кода. Иначе возникнет ощущение, что проблема багов решена и тема анализаторов не актуальна. Мол компиляторы/среды разработки/AI-тулы и так всё уже находят. Или программисты наконец научились писать без ошибок :). Можно расслабиться :).
На самом деле ничего не меняется. По-прежнему нужны продвинутые инструменты анализа кода, дополняющие другие методологии борьбы с ошибками (обзоры кода, динамический анализ, юнит-тесты и так далее). Способ убедительно это продемонстрировать – найти ошибки в проекте. Поэтому писали, пишем и будем писать про найденные баги :)
Спасибо! Хорошее дело делаете!
Как донести [не техническому] руководству преимущества хотя бы минимального архитектурного планирования и следования стандартам разработки? Какие метрики можно подготовить? Как объяснить что цена доработки фичей или багфикса растёт экспоненциально?
Я понимаю, что эти вопросы не имеют универсального ответа, но возможно есть какие-то интересные кейсы.
Мне было бы интересно про реализацию службы windows на с#.
А в чём проблема? Навалом документации же.
Нет проблемы. Есть интерес.
Кейс такой:
Excel хостит COM (MSScriptСontrol), в котором исполняется скрипт. Скрипт общается с Excel через COM Excel. Скрипт должен работать сутками. Скрипт управляется и мониторится из меню Excel.
Для удобства и стабильности нужно перевести MSScriptСontrol на хостинг в службе и сохранить для юзера управление ч/з меню Excel.
Я далек от с# и реализация такой службы для меня не очевидна.
Истории из жизни по интеграции pvs в билд-систему.
Какой подход был реализован в плане обработки сообщений от pvs? Например сообщения интерпретировать как ошибки и для начала большинство сообщений подавили, и по мере правки кода расширяли разрешенных. Или просто интерпретировать как предупреждения.
Насколько сложно подключить к анализатору новый язык. Например Rust вместо C. Или это равносильно тому что все переписывать?
Какую статью хочется прочитать в нашем блоге на тему C++, C# или Java?