Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля. Тезисы: * Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит. * Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку. * Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию. * Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом). * Где производить проверки? Есть несколько возможных этапов: - IDE разработчика - Локальная VCS (working copy) - Общая VCS - Сервер Continous Integration. В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды. * Если же нет достаточных ресурсов или проект находится

1. Здравствуйте :)

3. Контроль за
стилем кода
Борисов Кирилл, IT Global Meetup 2015

4. Контроль за
стилем качеством кода
Борисов Кирилл, IT Global Meetup 2015

5. Теория

6. Типичная ситуация
Команда разработчиков (3-5 человек)
Общий репозитарий
Что-то покрыто тестами
Жизнь потихонечку идет

7. Возникающие проблемы
Каждый пишет по-своему
…знает, что его код - правильный
…верит, что остальные это понимают
…думает, что нет смысла беспокоиться

8. Растет время code review
Сложно править чужой код
Споры о вкусах
Рабочее время тратится зря
Возникающие проблемы

9. Все плохо.

10. Чем спасаться?
Создайте style guide
Учитесь разрешать конфликты
Проводите сode review
“Автоматизируйте это!”

11. Практика

12. Как это делается в Python?
PEP8 - базовый свод рекомендаций по
оформлению кода.
PEP257 - набор рекомендаций по
оформлению docstring’ов
Множество инструментов:
pep8, pep257, pyflakes, pylint, pychecker…

13. Следим за стилем
pep8
https://github.com/jcrocholl/pep8
Проверка стиля исходного кода.
pep257
https://github.com/GreenSteam/pep257
Проверка форматирования docstring’ов.
isort
https://github.com/timothycrosley/isort
Сортировка импортов.

14. Следим за кодом
Статический анализ кода:
pylint
pyflakes
frosted

15. Готовимся к релизу
pyroma
https://bitbucket.org/regebro/pyroma
Соответствие setup.py стандартам PyPi.
dodgy
https://github.com/landscapeio/dodgy
Проверяем на забытые ключи, токены и т.д.

16. “N в одном”
flake8
https://gitlab.com/pycqa/flake8
pep8 + pyflakes + mccabe
prospector
https://github.com/landscapeio/prospector
pylint + pyflake + pep8 + pep257 + mccabe

17. Где проверять?
Пользователь: style guide
IDE: плагины + встроенные средства
Локальная VCS: pre-commit hooks
Общая VCS: pre-receive hooks
Continuous Integration

18. Онлайн-сервисы
Интегрируются с GitHub/Bitbucket
Бесплатны для open source проектов
Платные планы для приватных репозиториев
Результаты могут варьироваться со временем

20. Внешние средства: landscape.io
https://landscape.io
Онлайн-версия prospector
Учет особенностей фреймворков
Отслеживание версий зависимостей
Только для Python

23. Внешние средства: codacy.com
https://codacy.com
Полноценный инструмент поддержки кода
Поддержка различных языков
Большая база паттернов
Интеграция с баг-трекерами и HipChat/Slack

26. Внешние средства: quantifiedcode.com
https://quantifiedcode.com
https://github.com/quantifiedcode
Свой DSL для задания анти-паттернов
Возможность задавать свои анти-паттерны
Немного сырой :(

29. Case study

30. Яндекс.Паспорт
Интегрированный в IDE pep8

31. Яндекс.Паспорт
Интегрированный в IDE pep8
Git pre-commit hooks:
Сортировка импортов
flake8 (+ поиск print / pdb.set_trace)
Поиск TODO/FIXME

32. Яндекс.Паспорт
Интегрированный в IDE pep8
Git pre-commit hooks:
Сортировка импортов
flake8 (+ поиск print / pdb.set_trace)
Поиск TODO/FIXME

33. На что ещё обратить внимание?
Сложность кода
Совместимость с разными версиями Python
Copy-paste
Зависимости

34. A foolish consistency is
the hobgoblin of little
minds.

35. Вопросы?

36. Спасибо!
@lensvol borisov.kir@gmail.com

37. Собственные инструменты
forgetmenot
<однажды на GitHub>
Поиск TODO/FIXME
Определение автора, момента добавления
Подсветка и оформление

38. Инструменты
autopep8
https://github.com/hhatto/autopep8
Автоматически правит ошибки PEP8
Может быть не тем, что вы ожидали :(
Очень консервативен

39. Инструменты
frosted
https://github.com/timothycrosley/frosted
Форк pyflakes
Больше проверок
Python 2.6 - 3.4

40. Инструменты
pyroma
https://bitbucket.org/regebro/pyroma
Проверка стандартов упаковки кода:
PyPi, Distribute, pip…
Ставит оценку вашему коду, сравнивает его с
сыром

41. Инструменты
isort
https://pypi.python.org/pypi/isort
Сортировка импортов
Автоматически правит код
Git-хук в комплекте

42. Инструменты
prospector
https://github.com/landscapeio/prospector
pylint + pep8 + pyflakes + mccabe + dodgy
Машинно-читаемый вывод
Адаптируется под Django и Celery

43. Наш выбор
flake8
https://gitlab.com/pycqa/flake8
Три в одном: pep8, pyflakes, mccabe
Легко расширяется
Много готовых плагинов