Алексей Голобурдин - Типизированный Python для профессиональной разработки

типизацией. Что означает
динамическая типизация? Что тип переменной определяется не в момент создания
переменной, а в момент присваивания значения этой переменной. Мы можем
сохранить в переменную строку, потом число, потом список, и это будет работать.
Фактически интерпретатор Python сам выводит типы данных и мы их нигде их не
указываем, вообще не думаем об этом — просто используем то, что нам нужно в
текущий момент.

user = "Пётр"
user = 120560
user = {
"name": "Пётр",
"username": "petr@email.com",
"id": 120560
}
user = ("Пётр", "petr@email.com", 120560)

Так зачем же вводить type hinting в язык с динамической типизацией? А я напомню,
что в Python сейчас есть type hinting, то есть подсказки типов, они же есть в PHP, а в
JS даже разработали TypeScipt, отдельный язык программирования, который
является надстройкой над JS и вводит типизацию. Зачем это всё делается, для чего?
Вроде скриптовые языки, не надо писать типы, думать о них, и всё прекрасно, а тут
раз — и вводят какие-то типы данных.
Зачем в динамически типизированном языке вводить явное указание типов?

Раннее выявление ошибок
Первое — это ранее выявление ошибок. Есть у нас некая программа и есть в этой
некой программе ошибка. Когда мы можем её выявить? Мы можем выявить её на
этапе написания программы, мы можем выявить её на этапе подготовки программы

к разворачиванию на сервере, или мы можем выявить её на этапе runtime, то есть
когда программа уже опубликована на сервере, ей пользуются пользователи.
Как вы думаете, на каком этапе лучше выявлять ошибки? Очевидно — чем раньше,
тем лучше. Если ошибки долетают до пользователей, то это максимально плохо.
Почему?
Во-первых, потому что пользователи недовольны, а раз пользователи недовольны,
то много денег мы с нашим программным продуктом не заработаем, так как люди не
будут охотно его покупать и рекомендовать другим. К тому же очень неприятно, что
мы занимаемся любимым делом, активно трудимся, реализуем сложные алгоритмы,
а результатом нашего труда пользователи недовольны. И винить-то объективно
некого, кроме нас самих. Непорядочек, непорядочек!
Во-вторых, недовольные пользователи обращаются в техподдержку, создают
тикеты, которые спускаются потом на разработку — это всё тратит деньги компании.
Если ничего не ломается, то обращений в поддержку мало, тикетов мало, а
разработчики заняты разработкой новых фичей продукта, а не постоянными
правками отвалившейся старой логики. Постоянные поломки это постоянные
финансовые потери.
В-третьих, из-за ошибок, которые видят пользователи, компания несёт
репутационные потери. Пользователи пишут негативные отзывы, они легко гуглятся
другими потенциальными пользователями, СМИ, инвесторами, всё это в конечном
итоге негативно влияет и на капитализацию компании, и на возможности
привлечения инвестиций, и на чистую прибыль компании, если она вообще есть.
Если мы хотим быть профессиональными высокооплачиваемыми специалистами, то
наша задача — генерировать через результаты нашей работы радость и прибыль, а
не поток проблем и убытков.
Поэтому важнейшая задача для нас — сделать так, чтобы до пользователей не
доходило ни одной ошибки. Для достижения этой цели нужен системный подход,
одной внимательности в процессе программирования мало. Нужна выверенная
система, алгоритм действий, инструментарий, который не позволит ошибкам дойти
до пользователей.
Какой это может быть инструментарий? Это могут быть автотесты. Однако первый
принцип тестирования гласит, что тестирование может показать наличие дефектов в
программе, но не доказать их отсутствие. Тесты это хорошо, но не на одних только
тестах всё держится. Чем больше капканов для разных видов ошибок расставлено,
тем надёжнее программа и крепче сон разработчика. А что, в конце концов, может
быть важнее крепкого, здорового сна разработчика?

Помимо автотестов (и ручного тестирования людьми) можно проверять
корректность использования типов специальными инструментами. Например,
компилятор Rust — прооосто красавчик! Он на этапе компиляции выявляет огромное
количество проблем и попросту не даёт скомпилировать программу, если видит в
ней места с ошибками. Какая-то функция может вернуть успешный результат или
условный null и вызывающая функция не обрабатывает сценарий с null? Вот тебе
потенциальная серьёзная ошибка. --">