Семестровый проект
Семестровый проект — это публичный git-репозиторий с кодом на Python3,
- в котором есть более одного участника,
- я могу посмотреть статистику участия (оба предложенных ниже измерения неидеальны, я это знаю)
- по количество коммитов
- по объёму кода
- В котором принята и соблюдается некоторая единая дисциплина оформления коммитов
- я могу посмотреть статистику участия (оба предложенных ниже измерения неидеальны, я это знаю)
в котором flake8 (или pylint), а также pydocstyle не находят ошибок
некоторые требования анализаторов можно запрещать в config-файле
вспомогательные функции и классы, подразумевающие повторное использование, должны быть аннотированы (в частности, если ваш проект — это модуль python, т. е. его пользователь — программист, все доступные ему функции/классы должны быть по возможности аннотированы)
наличие docstrings обязательно. Если ваша дисциплина программирования использует их для технических целей (например, там хранятся обрабатываемые данные), и это не соответствует pep-0257, ошибки pydocstyle игнорируются
- в котором есть немножко тестов (с использованием любого тест-фреймворка, годится встроенный питоний)
- должны быть покрыты модульными тестами в первую очередь функции и классы, не использующие интерактивные возможности (т. е не GUI, не сетевое взаимодействие и т. п.)
- таких функций/классов должно быть не менее 5
- в котором есть немножко документации
описание проекта в README (в случае GitHub — README.md) и постановка задачи на GH
- В случае GUI — проект интерфейса
- не обязательно полностью совпадающий с тем, что получилось
- достаточно детальный, чтобы было понятно, какой блок виджетов из чего состоит и за что отвечает
- можно в виде картинки с исходниками из какого-то диаграммера, а можно и просто фоточки нарисованного от руки
- В случае GUI — проект интерфейса
- программной (с использованием любого фреймворка, годится встроенный питоний, но можно и sphinx)
- пользовательской (либо sphinx, либо прямо на GH)
- в котором есть немножко локализации (с теми же оговорками по части фреймворков)
- с использованием gettext или babel
обратите внимание на то, что, например, -.mo файлы надо сгенерировать и положить в дистрибутив вашего проекта (например, в wheel, как в лекциях)
- в котором есть немножко автоматизации сборки / деплоймента.
- в частности, в репозитории не хранятся никакие генераты (в том числе дистрибутивные)
- каждый дистрибутивный генерат (переводы, документация, иное) должны побираться одной командой средства автоматизации
Если вы делаете приложение или модуль, он должен быть оформлен в виде wheel, который можно установить в произвольном окружении (например, на моём компьютере)
Немножко — это реально немножко, чтобы я видел, что работа проделана. Например, если вы задумали какое-то приложение из реал лайфа, и в нём довольно много логики, обмазать всю её тестами будет долго. Но пяток должен быть.
Методика проверки:
- показать сборку, выгонку техдокументации, запуск тестов
- показать документацию
- сформировать дистрибутив
- задеплоить в чистое окружение
- показать работу и перевод
Оценка:
- По сумме баллов каждого из пунктов требований. То есть набрать 5 баллов из 6, что, с учётом претензий по каждому из пунктов, не так уж просто)
В случае значимо неравномерного участия в проекте водится КТУ — есть шанс получить оценку меньше, чем товарищи
Регистрация проекта
Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2022. В issue указать:
- Короткую формулировку сути проекта
Ссылку на публичный репозиторий проекта
- Список участников проекта в виде:
- ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
- ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории