Max Home IndustryУ всех нас есть свое мнение о статической сильной типизации по сравнению с динамической или даже вообще без реальной типизации, но убедительных доказательств того, что работает, на земле мало. Теперь некоторые новые исследования дают нам некоторые факты для обсуждения.
Как вы можете доказать или, по крайней мере, приблизиться к истине о том, уменьшает ли конкретная техника ошибки или нет? Вы не можете действительно сравнивать базы кода, созданные с помощью техники и без нее, а затем подсчитывать ошибки, потому что слишком многое другое варьируется — программисты, задача. частота обнаружения ошибок. и так далее.
Чжэн Гао и Эрл Т. Барр из Университетского колледжа Лондона и Кристиан Берд из Microsoft Research имеют хорошее представление о том, как выполнить эту работу. Поскольку большинство проектов используют какую-либо систему управления исходными кодами, должна быть возможность вернуться к коду непосредственно перед исправлением ошибки и посмотреть, обнаружит ли включение проверки типов ошибку в незафиксированном коде.
Единственная проблема с этим заключается в том, что для большинства языков вы не можете включать и выключать строгий ввод — это функция языка, которую вы не можете отключить. Однако такие языки, как JavaScript, в основном не содержат типов, но к ним можно добавить системы проверки типов. Например, поток Facebook будет проверять тип программы JavaScript, а также компилятор Microsoft TypeScript. Есть некоторые сложности, вам придется добавлять аннотации типов вручную, но с небольшими усилиями, кажется, можно создать справедливый тест.
Таким образом, метод примерно:
найти ошибку
вернитесь к кодовой базе непосредственно перед ошибкой
добавление аннотаций типов в код
посмотрите, помечена ли ошибка используемым инструментом системы типов.
Эта основная идея заключается в том, что если ошибка помечена инструментом проверки типов, то она была бы обнаружена программистами до того, как она попала в базу кода, и никогда бы не существовала.
Так к какому же выводу пришли?
Оба подхода к проверке типов, Flow и TypeScript, обнаружили 15% ошибок. То есть из 400 ошибок Поток обнаружил 57, а TypeScript обнаружил 3, которые поток пропустил, и наоборот.
Это может показаться не очень большим, но, как отмечается в статье, это консервативная оценка ошибок, которые может обнаружить сильная типизация. 400 ошибок выдержали тестирование и проверку кода и поэтому были немного сложнее, чем ошибки, которые были удалены ранее в этом процессе. Тем не менее исследователи цитируют неназванного инженера в ответе Microsoft:
— Это шокирует. Если бы вы могли внести изменения в то, как мы занимаемся разработкой, которые уменьшили бы количество ошибок, регистрируемых в течение ночи на 10% или более, это не проблема. Если бы это не удваивало время разработки или что-то в этом роде, мы бы это сделали.”
Ну, в этом-то все и дело. У нас есть некоторые неопровержимые факты, которые можно добавить в дискуссию, но вопрос не в том, сколько ошибок обнаруживает сильная типизация, а в том, насколько это увеличивает усилия по созданию кода. Существует также вопрос о том, можем ли мы лучше использовать эти возросшие усилия.
Существует также точка зрения, что Flow, в частности, является инструментом статической проверки типов, который может использовать вывод типов для проверки базы кода. Язык не обязательно должен быть строго типизирован, чтобы быть проверенным на тип в этом смысле. Кроме того, проверка типов-это всего лишь одна из форм статического анализа кода, и вы можете задать вопрос, почему просто проверьте тип?
Например, гистограмма ошибок, которые не были обнаружены в зависимости от типа, показывает типы ошибок, которые могли бы быть показаны при статическом анализе кода:
Похоже, нам все еще нужно больше данных, и споры могут продолжаться.
В мире, где по-прежнему респектабельно утверждать, что код в текстовом редакторе, каким бы умным он ни был, и использовать компилятор из командной строки, кажется, что многое можно сделать для улучшения среды программирования.
Нам нужно больше инструментов, а не обязательно более ограничительные языки.