Логически «правильно» — типы проставлены верно. Но поведение изменилось: null теперь рендерится как строка "null" вместо пустой строки. В продакшене это сломало отображение имён пользователей у которых не заполнено поле.
Это говорит о том, что у вас не хватает юнит тестов.
Создание юнит тестов даже казалось бы тупых это важный шаг для улучшения контекста и принятия более правильных решений в миграции.
Занимаюсь типизацией больших проектов на Python. Без предварительного покрытия тестами всяких граничных случаев получаем много ошибок. Плюсом получаем дополнительные проверки и более надёжный код.
Там нужен другой подход. Совсем не так как ожидается в теории. Вроде как никакого вмешательства в программу, а наделе баг на баге находишь у всех, в общем наелись сполна :)
Добро пожаловать в дивный мир. Там всё гораздо сложнее. А ещё приложения любят падать потому, что кто-то с ними общается и хочет узнать как они выглядят.
Процент это да метрика просто надо правильно работать.
Покрытие 50% это хорошо, 70% отлично, а если ниже 30% это повод задуматься, скорее всего, и обычно так, у нас мало проверок.
А что такое некачественно?
Положим у нас JS функция sum(a,b) ожидает объект.
По вашему проверки на null, undefined,NaN не нужны ведь этого никогда не произойдёт?:)
Очень рад, что к вам в команду пришло поднимание.
У меня пока это не встречается с большим энтузиазмом.
Покрытие простых случаев до сих пор считается как ненужные проверки.
Хотя тоже какая разница. Это бежит миллисекунды и требует 0 времени на поддержку сегодня.
Что действительно хорошего принесли нам модели это за секунды получить все эти тесты которые никто не хочет писать и отнимают уйму времени.
Раньше делали спеки со всеми граничными случаями , потом начали забивать на это.
А сегодня это всего лишь вопрос желания и понимания.
Это говорит о том, что у вас не хватает юнит тестов.
Создание юнит тестов даже казалось бы тупых это важный шаг для улучшения контекста и принятия более правильных решений в миграции.
Занимаюсь типизацией больших проектов на Python. Без предварительного покрытия тестами всяких граничных случаев получаем много ошибок. Плюсом получаем дополнительные проверки и более надёжный код.
😁
Автокорректор видимо уже тоже ИИ использует вовсю.
Потому что это не входит в KPI.
До недавнего было важно отметить как помогал разнообразию (DEI), теперь критерий успешности это сколько токенов потратил и где вредил ИИ.
Баги и проблемы это лишний шум и не помогает продвигаться вот и никто не занимается.
Так и есть не вспаханное минное поле.
Мышка это не проблема, а вот как понять на что мы кликаем.
Ну или узнать, что такое-то окно открылось с таким-то текстом.
Принцип , который я привёл будет работать на практически все случаи.
Только надо это кому-то сделать.
Тут зависит от задачи и для работы или для души.
В идеале нужны фильтры куда не лезть чтобы не упало.
При чём фильтры на уровне win32, UIA отдельно. Проверку winAPI не ломают программу точно, всё остальное на откуп программе.
Фильтры это кто родительское окно кто процесс ну и там усложнять надо.
Далее этого мало.
Если делать проверки из отдельного процесса то всегда есть риск напороться на баги программы.
Идеальным вариантом было бы использовать IAccessibleEx изнутри.
Тогда мы всегда бежим в UI потоке и уменьшаем гонки до нуля.
Но это всё прямо очень сложная система получается .
Там нужен другой подход. Совсем не так как ожидается в теории.
Вроде как никакого вмешательства в программу, а наделе баг на баге находишь у всех, в общем наелись сполна :)
Добро пожаловать в дивный мир. Там всё гораздо сложнее.
А ещё приложения любят падать потому, что кто-то с ними общается и хочет узнать как они выглядят.
В своё время пришёл к https://github.com/TestStack/UIAComWrapper , и даже там есть ошибки , которые не внесены в код увы.
Тесты это хороший подход. Проверено на практике.
Чем больше количество и чем больше покрытие тем лучше.
Ещё лучше проверять все пограничные значения там вроде NaN, Infinity, null, undefined, None и т.п.
Поведение вряд ли задокументировано, а вот при изменении технологии важно знать все мелкие детали для воспроизведения точного подобия.
для нового кода как раз подходит ненавистный TDD.
https://www.aihero.dev/skill-test-driven-development-claude-code
И получаем как раз то, что и хотели изначально.
Тесты не знают как устроено, код пишется пол тесты. Тесты создаются в соответствии со спецификацией.
За короткое время можно сделать довольно много рутиной работы , а дальше правим как нам надо.
Кстати, модельки и C++, а если к нас шаблоны и макросы и прочее, это ещё та затея :)
Что такое правильный ?
И цель то не создать новое, а тупо зафиксировать текущее положение вещей, чтобы любое изменение было зафиксировано.
Положим у нас есть
def sum(a,b): return a-b
Пишем тест, который проверяет там sum(1,1)==0
Зафиксировали текущее положение.
Далее, скажем, поняли мы, что надо исправить. Изменяем “-“ на “+” и получаем падающие тесты.
Без тестов мы бы не знали вообще как изменение влияет !
Ну и в конце обновляем тесты: sum(1,1)==2.
Я не утверждаю, что модельки сделают всё идеально за нас
Зато помогают здорово экономить время на некоторых вещах.
Это смотря какую работу.
Например простую работу как покрыть код тестами моделька делает на ура.
Берём старый код за пару минут получаем тесты. Гарантировано находятся баги.
На и дальше можно развивать код гораздо спокойнее.
Увы мир C++ настолько разнообразен , что в 2026 лучше с нуля учить Rust или что угодно не C++.
У нас есть проекты где до сих пор C++17, есть где запрет исключений, есть где запрет RTTI, есть где запрет ranges, лямбда и т.д.
Вопрос в том стоит ли тратить своё время на это сегодня когда модельки худо бедно сделают работу лучше чем кто-то с небольшим опытом плюсов.
У VSCode есть приятная возможность внедрить в веб сайты.
А Zed может таким похвастаться ?
Что-то можно если очень нужно.
https://msfn.org/board/topic/183352-proxhttpsproxy-and-httpsproxy-in-windows-xp-for-future-use/
https://browser.360totalsecurity.com/
Проблема и преимущество goto это возможность прыгнуть куда угодно, а не только выйти из цикла.
А здесь мы ограничиваем себя и упрощаем понимание кода.
Это в мире где все обновились.
А на деле только вот сейчас работают над переходом на 17 с 11.
Так что Kotlin вари таком раскладе здоров облегчает жизнь.