Moscow Python Meetup №86. Денис Аникин (Райффайзен банк, Community Lead). Базовый кодовый стиль хорошего Python-бэкенда

Расскажу о том как эволюционировало представление о кодовом стиле у меня и у нашего внутрибанковского комьюнити и к чему мы пришли. Покажу свод правил, конфигурацию и опции настройки для того, чтобы относительно расслабленно систематически достигать очень хорошего качества исходного кода.

Здесь не будет срыва покровов, взрывных правил, неожиданных утилит, крутых разработок, скорее собранное вместе руководство. Пригодится тем, кто не заморачивался на кодстайл; тем, кого не устраивает их кодстайл; тем, кого по какой-то причине не устроили существующие гайды.

Видео: https://youtu.be/G3JKtB8tgvg

Moscow Python: http://moscowpython.ru
Курсы Learn Python: http://learn.python.ru
Moscow Python Podcast: http://podcast.python.ru
Заявки на доклады: https://bit.ly/mp-speaker

Transcript

1. Денис Аникин https://xfenix.ru Базовый кодовый стиль хорошего python бекенда
2. Я опять придумал хорошее название
3. Денис Аникин 3 Что я делаю — работаю в Райфе — teamlead в 3 командах — community lead в Python Community — fullstack: typescript, python, devops — много раз выступал на конференциях и митапах https://xfenix.ru
4. Немного слов в начале 4 —Я расскажу о том какой codestyle сейчас у нас (а мы работаем над ним постоянно, поэтому он может быть полезен) в community —Расскажу о том каким он был ранее —На основе этого расскажу как вам самостоятельно писать код по качеству лучше, чем в большинстве проектов, что существуют вокруг, как защититься от типовых ошибок —Даже если вы уже работаете в крупной организации, некоторые решения могут быть для вас новыми
5. Этот доклад местами немного ДУШный
6. Что я понимаю под codestyle? 6 Это может быть не очевидно —Стандартные соглашения по тому как писать код —Стандартные способы предовтращения появления ошибок —Стандартные способы улучшения вашего кода —Стандартные инструменты, помогающие всего этого достигать —Типовые настройки для всего вашего рабочего процесса (от локальной среды до CI/CD конвейера) —И не только
7. Зачем нам нужен codestyle — Снижение когнитивной нагрузки — Ускорение восприятия информации — Как следствие, возможность проще и легче поддерживать (делать новые части и не позволять старым «гнить») ваши проекты — Унификация (многие вещи понятны, даже если не вы их писали) — Устранение многих ошибок ещё до момента их возникновения
8. Итак, сказочка! 8
9. Знакомьтесь! 9
11. Трицератослав. Древнерусский тимлид 11
12. А это его команда — 12
13. Junior у него свой меч в спине застрял Middle у него всё норм Senior именно он сжег деревню
14. Они любят жечь деревни 14
15. Как же с ними делать продукт? 15
16. Договориться о правилах — code style, иначе… 16
18. А если не выйдет? 18
19. Трицератослав тимлид, сейчас микроменеджер
20. Вы знаете рецепт — мы просто берем линтеры и размещяем их в пайплайнах 20
21. И вот теперь поговорим о том, что и как размещать 21
22. black 22
24. PEP8 и не только 24 Вместе c black —Стандартный кодовый стиль для питон проектов —Разработчики часто путают PEP и PEP8 —Имеет смысл использовать его как стандарт по-умолчанию и не искать ничего лучшего
25. Многие его не помнят. Я считаю, что это ошибка и PEP8 стоит заучить 25
26. Black 26 Если вы его еще не используете —Имеет мало опций настройки и это правильно (я не очень поддерживаю grey) —Можно конфигурировать длину линии, у нас стандарт 120 —Проверяет, что код продуцирует валидное AST —За более чем 4 года работы в качестве автоматического инструмента у очень большого количества людей показал себя как действительно надежный инструмент
27. А ещё вы можете сказать: our code is blacked 27
28. isort 28
29. И вновь PEP8 29 https://peps.python.org/pep-0008/#imports —Импорты надо разбивать на 3 группы: встроенные, сторонние библиотеки и свой код —Разделять стоит 1 пустой строкой —После этого блока 2 пустых строки
31. Открытие 1: большинство нарушает это правило 31
32. Открытие 2: isort по-умолчанию настроен просто ужасно! 32
33. Типовая конфигурация isort 33 Ну и где здесь pep8? —FUTURE —STDLIB —THIRDPARTY —FIRSTPARTY —LOCALFOLDER
34. isort default 34 from __future__ import absolute_import import os import sys from third_party import (lib1, lib2, lib3, lib4, lib5, lib6, lib7, lib8, lib9, lib10, lib11, lib12, lib13, lib14, lib15) from my_lib import Object, Object2, Object3 print("Hey") print("yo")
35. isort default — нормальные импорты 35 from __future__ import absolute_import import os import sys from third_party import (lib1, lib2, lib3, lib4, lib5, lib6, lib7, lib8, lib9, lib10, lib11, lib12, lib13, lib14, lib15) from my_lib import Object, Object2, Object3 print("Hey") print("yo")
36. isort default — а вот так вообще хорошо 36 from __future__ import absolute_import import os import sys import third_party import my_lib print("Hey") print("yo")
37. Дополнительные соглашения по импортам 37 —Импортируйте встроенные модули целиком (особенно typing) —Если у вас 2 и более импортов из модуля — импортируйте его целиком —Стандартный pep8, но все таки: не импортируйте «звездочку»
38. Конфигурация isort pyproject.toml 38 Для соблюдения PEP8 [tool.isort] line_length = 120 multi_line_output = 3 include_trailing_comma = true lines_after_imports = 2 lexicographical = true sections = ["FUTURE", "STDLIB", "FIRSTPARTY", "THIRDPARTY", "LOCALFOLDER"] no_lines_before = ["STDLIB", "THIRDPARTY"] known_third_party = [] known_local_folder = []
39. docformatter 39
40. Оказывается, одного PEP8 недостаточно. Нужен ещё PEP257 40
43. У этого инструмента есть режим inplace исправления кода 43
44. autoflake 44
45. autoflake 45 —Удаляет неиспользуемые переменные —Удаляет мертвые импорты —Тоже умеет inplace
46. Если настроить автоматом, у вас никогда не будет мертвого кода 46
47. pyupgrade 47
48. Что представляет из себя pyupgrade 48 —Умеет переписывать код под новые версии python —Все так же умеет inplace —В постоянную работу, все же, взять его проблематично (если у вас больше 1 проекта)
49. Я зову эту штуку «вечно свежий python» 49
50. pybetter 50
51. Код ещё лучше 51 —Внедряет некоторые хорошие практики написания кода (их всего 10, но они важные) —И тоже умеет inplace —Увы, слабо развивается
52. 52 Пример 1
53. 53 Пример 2
54. eradicate 54
55. Все тоже 55 —Берет комментарий, eval’ит его и если тот eval’ится, то удаляет такой комментарий —Тоже умеет inplace
58. Всё просто: при наличии git нет необходимости захламлять код 58
59. Last but not least: Pylint 59
60. Битва pylint vs flake8 60 Плюсы —На мой взгляд pylint содержит нереальное количество хороших практик и советов из коробки —Этот инструмент сразу даёт возможность писать как минимум хорошо —Для тех, кто устал от пачек линтеров, решение «всё в одном»
61. Битва pylint vs flake8 61 А вот дальше идут минусы —Нереально медленный —Очень сложная конфигурация —Fix режима нет (а так можно было?)
62. Картинка по запросу «конфигурация pylint»
63. Аннотации типов 63
64. Лучший тайп чекер — mypy 64 Альтернатива ему — pyright —Сейчас, в 2023 году, имеет смысл включать strict по-умолчанию —Не забывайте о mypy . --install-types —Для pydantic можно подключить комплектный плагин —У моего коллеги, Миши Гурбанова, вышел доклад с подробным исследованием текущих тайпчекеров: https://pycon.ru/da-kto-takie-ehti-vashi- tajp-chekery
65. Свежайшие решения (2023 год) 65
66. Мы выкинули все линтеры! 66
68. …и взяли Ruff 68
70. 70 Ruff из Байкала помогает древним разработчикам писать хороший код!
71. 71 Деревни больше не горят!
72. Что заменил собой ruff? 72
73. Это впечатляет 73 У вас есть почти всё, что вы вообще могли бы хотеть. И это на космической скорости —pylint —isort —около 30 плагинов flake8 —perflint (устраняет некоторые анти-паттерны, убивающие производительность) —refurb (но частично) —pyupgrade —eradicate —pydocstyle —numpy, airflow, pandas-vet, flynt, mccabe, pep8-naming, pycodstyle —свои правила
74. А теперь кое-что очень важное 74
77. Ruff исправляет. Ошибки. За вас! 77
79. Но если только вы включите все правила по-умолчанию 79
80. А теперь небольшой прикол 80 —Ruff недавно представил ruff formatter —Drop-in replacement для black —НО, есть отличия https://docs.astral.sh/ruff/formatter/black/ —НО (2), есть несовместимые правила линтера https://docs.astral.sh/ruff/formatter/#conflicting-lint-rules
81. Да, они решили заменить black… 81
82. Как ruff сконфигурировать? 82
83. Пример CLI 83 ruff check .\ --ignore=I,EM,FBT,TRY003,S101,D1,FA,ANN101\ --line-length=120\ --fixable=ALL\ --select=ALL \ --unsafe-fixes
84. Пример CLI 84 ruff check .\ --ignore=I,EM,FBT,TRY003,S101,D1,FA,ANN101\ --line-length=120\ --fixable=ALL\ --select=ALL \ --unsafe-fixes
85. Пример CLI с black 85 Да, это не совсем пакетное предложение ruff format .
86. Таким образом, мы делаем ваш код потрясающим автоматически 86
87. Некоторые правила мы все же отключаем 87 Лишь небольшую часть —I (возможно) так как передать конфигурацию глобально невозможно. Если вы индвидуально запускаете ruff в каждом проекте, то можно использовать pyproject.toml и отказаться ещё и от isort! —TRY003 писать message в exception это нормально —D1 можно пропускать все докстринги —ANN101 можно отключать, если вы не хотите везде подписывать typing.Self, так как он нормально выводится mypy сейчас автоматически —EM если вы любите добавлять сообщения в ваши эксепшены —FBT довольно спорный набор правил, запрещающий bool аргументы —(помним) про несовместимую простыню исключений для format https://docs.astral.sh/ruff/formatter/#conflicting-lint-rules
88. Как pyproject.toml может выглядеть 88 Для конфигурации ruff (в бонус пресет для тестов) [tool.ruff] fix = true line-length = 120 select = ["ALL"] ignore = ["D1", "D203", "D213", "FA102", "I”, “ANN001”] [tool.ruff.extend-per-file-ignores] "tests/*.py" = ["S101", "S311"]
89. Как pyproject.toml может выглядеть 89 Для конфигурации ruff (в бонус пресет для тестов) [tool.ruff] fix = true unsafe-fixes = true line-length = 120 select = ["ALL"] ignore = ["D1", "D203", "D213", "FA102", "ANN101"] cache-dir = "/tmp/ruff-cache/" [tool.ruff.isort] no-lines-before = ["standard-library", "local-folder"] known-third-party = [] known-local-folder = ["whole_app"] [tool.ruff.extend-per-file-ignores] "tests/*.py" = ["ANN401", "S101", "S311"]
90. Некоторые правила для тестов 90 Лишь небольшую часть —S101 (вы наверняка хотите ассерты в тестах) —S311 (random в тестах — приемлимо) —ANN401 (иногда хочется any)
91. И это не всё 91
92. Скорость! 92 И это не обман
93. Другие интересные нюансы 93 —Более 600700 правил и число растет быстро —Есть кеширование —Дружит с монорепами
94. Еще не перешли на ruff? 94
96. Я уже ставлю RUFF!
97. Поставил pylint случайно :(
98. Документация 98
99. 99 Показал подруге объем документации на проекте
102. Я раскрыл заговор 102
104. Документация 104 —Все считают, что она должна быть —Почти у всех её либо нет, либо она не актуальная (что хуже её отсутствия) —Всем всегда стыдно, что её нет и, почему-то, менее стыдно, что она не актуальная —Нет хороших подходов, есть спорные —Автодокументация не работает, её почти не читают —Спеки выглядят хорошо в начале дороги, после сотой в них не разобраться
105. Может быть, нам не писать документацию? 105
107. Не переключайте канал! 107
108. Я предлагаю вам самодокументируемый код 108
110. Основные принципы 110 Они довольно простые —Вербозные названия всего: переменных, классов, функций, констант —Не используйте слово get в большинстве случаев —Меньше магических методов (лучше вообще без них) —Никаких чисел кроме 0 и 1 в коде, все остальное — только константы с человеческими именами —Используйте enum для константных перечислений —Функция должна именоваться глаголом, а не существительным. Она что-то делает! —Зен питона — не набор правил
111. Полу-автоматический кодинг 111
112. Принцип 1: все что может быть сделано автоматом, должно быть сделано автоматом 112
113. Как этого достичь? 113 —Вам нужен vscode —Вам понадобятся стандартные плагины mypy и ruff (black и isort, считай, мы уже выселяем)
114. 114 Как выглядит конфигурация? "python.linting.mypyEnabled": true, "python.formatting.provider": "black", "python.formatting.blackArgs": [ "--line-length=120", ], "[python]": { "editor.formatOnPaste": true, "editor.formatOnType": true, "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll": true, }, }, "ruff.args": [ "--line-length=120", "--ignore=I,EM,FBT,TRY003,S101,D101,D102,D103,D104,D105,G004,D107,FA102", "--fixable=ALL", "--select=ALL" ], "emeraldwalk.runonsave": { "commands": [ { "match": ".py", "cmd": "isort --line-length 120 --lines-after-imports 2 --no-lines-before stdlib,localfolder ${file}", "isAsync": true, } ] }
115. 115 Как выглядит конфигурация? "[python]": { "editor.defaultFormatter": "charliermarsh.ruff", "editor.formatOnPaste": true, "editor.formatOnType": true, "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll": true, "source.organizeImports": true } },
116. Принцип 2: как можно больше AI утилит 116
117. Некоторые полезные решения 117 —Sourcery (правил меньше, чем у ruff, но несколько раз он находил что-то дополнительно). Пока пилотируем. Правил около 200 —Tabnine —Или Code whisperer —Copilot пока лучше всех, но не работает без VPN и аккаунта за 100$ —Можно использовать ChatGPT 3.5, Bard, GigaChat, TheB.AI
118. Аннотации типов 118
119. Как стартануть? 119 Я знаю, может быть не просто —Берете ruff —Берете mypy —Включите режим strict в mypy —Включаете все правила в ruff —Они вас заставят ☺
120. Стремитесь к покрытию кода в 100% и strict в mypy Аннотации tips & tricks 120 —Освойте не только стандартные типы, но и Literal и особенно Final —Final имеет смысл аннотировать все переменные вообще по-умолчанию (чаще всего изменение переменных и ведет к ошибкам) —Примитивные типы можно не аннотировать (a = 5 не надо расписывать как a: int = 5) —Дженерики —Annotated помогает в валидации —сast, overload, final, never, noreturn, typealias, newtype, classvar, typeguard, unpack, Protocol, assert_type, assert_never, TYPE_CHECKING — полезные инструменты
121. 121 Пример с Final: до some_value = 5 some_another_value = 'kek’ for one_element in range(100): some_another_value = some_another_value * some_value some_value += 1
122. 122 Пример с Final: после import typing some_value: typing.Final = 5 # <- тут само выведет typing.Final[typing.Literal[5]] some_another_value: typing.Final = 'kek' for one_element in range(100): some_another_value = some_another_value * some_value # <- тайпчекер поймает some_value += 1
123. 123 TYPE_CHECKING
124. 124 Как победить coverage [tool.coverage.report] exclude_also = [ "if typing.TYPE_CHECKING", ]
125. Тонкое эстетическое восприятие отдельных людей 125
126. Мне не нравится как форматирует black… 126
127. 5 групп импортов в isort — достаточно логичны… 127
128. Я многое погашу в ruff/pylint, потому что не согласен… 128
130. Легко намекну вам — 130
132. Серьезные советы 132 Правда (тм) —Успокойте свое чувство эстетики —Общий кодовый стиль и подход стоят гораздо больше, чем «красивые» кавычки или более веселые переносы —Если гасите правила в линтерах, то обязательно записывайте в глобальные командные установки почему вы это делаете —Ваши аргументы должны быть адекватными («мне не понравилось» — не такой аргумент)
133. Дополнительно 133
134. Набор стандартных советов 134 —Всегда «сужайте» try-except блок до минимального количества строк (если возможно, до 1) —Всегда «сужайте» класс ошибки в except (не все знают, но это крайне полезная графическая иллюстрация стандартной иерархии ошибок https://docs.python.org/3/library/exceptions.html#exception-hierarchy) —Делайте ретраи, ограничивайте количество раз, делайте умный интервал и jitter (библиотека backoff поможет) —Храните всю конфигурацию линтеров в pyproject.toml —Избегайте вложенных и сложных условий с помощью инверсии —Используйте композицию и меньше наследования
135. И кое-что ещё 135 —https://github.com/regebro/pyroma позволяет оценить «дружелюбность» вашего пакета —https://github.com/jendrikseipp/vulture ищет мертвый код по всему проекту —https://github.com/dropbox/pyannotate выводит аннотации для вашего кода (но работа довольно ручная) —https://github.com/JelleZijlstra/autotyping добавляет типовые аннотации (не идеально) —https://github.com/bndr/pycycle обнаруживает циклические импорты (тесты?) —https://github.com/Instagram/Fixit любопытный фреймворк для автоисправлений кода (!) —https://github.com/lyz-code/autoimport сам добавляет нужные импорты —https://github.com/pyupio/safety проверяет безопасность проектов —https://github.com/fpgmaas/deptry ищет неиспользуемые, пропущенные, транзитивные зависимости
136. Что по поводу SOLID & GRASP 136 —https://github.com/mschwager/cohesion проверяет связанность вашего кода —Mypy проверяет принцип Liskov substitution principle —Если вы хотите достичь DIP принципа, попробуйте паттерны IoC и DI: на pycon 2023 были посвященные этому доклады. Так же есть неплохие DI фреймворки, мне нравится dependency injector по своему, так же можно посмотреть di, rodi, lagom —Для некоторых других архитектурных линтеров советую доклад Коли https://pycon.ru/arhitektura-knuta-i-pryanika
139. Теперь качества кода станет значительно лучше 139
141. Денис Аникин https://xfenix.ru https://github.com/xfenix/ Вопросы? Поставьте лайк на гитхабе, пожалуйста