Итоги: полный путь проекта от идеи до релиза
От идеи до первого релиза — весь путь пройден один раз целиком, на настоящем проекте.
Полный путь проекта
В начале этой главы SafeSort был только идеей. Теперь это настоящий репозиторий на GitHub — Cartesian-School/safesort — с 14 закрытыми Issues, реальными Pull Request, зелёной проверкой CI и опубликованным релизом 0.1.0. Вот весь путь целиком, с тем, что появилось на каждом шаге:
Что уже умеет SafeSort
| Команда | Что делает | Меняет файлы? |
|---|---|---|
| scan | находит и подсчитывает файлы по категориям | нет |
| plan | показывает план перемещений | нет |
| duplicates | находит файлы с одинаковым содержимым | нет |
| apply | выполняет перемещения из плана | да, только по явной команде |
| undo | отменяет последнюю выполненную операцию | да, только восстановление |
Что дальше
Версия 0.1.0 сознательно не покрывает всё, что в принципе возможно: самый первый раздел этой главы заранее очертил границы. Дальнейшее развитие SafeSort — за рамками этой главы, но некоторые направления естественно продолжают уже сделанное: публикация пакета в PyPI, классификация не только по расширению, а с осторожной проверкой содержимого файла, интерфейс для настройки, отличный от редактирования TOML-файла вручную.
Приложение к этой главе повторяет тот же самый путь — от задачи до Pull Request — ещё шесть раз, уже самостоятельно, на шести небольших проектах: Дополнительная практика: шесть мини-проектов для GitHub.
Что мы узнали в этой главе
- Прежде чем писать код, требования проекта описывают не только то, что программа делает, но и то, что она сознательно не делает.
- Разделение на read-only планирование и две явные операции, прямую apply и обратную undo, защищает от случайных изменений файлов пользователя.
- Поиск дубликатов дорогую операцию — хеширование — делает только там, где она действительно может изменить ответ: после отбора файлов по размеру.
- Автоматические тесты работают только во временных каталогах — ни один тест не должен касаться настоящих файлов пользователя.
- Git и GitHub — часть разработки с самого начала, а не финальный шаг: Issue формулирует задачу, ветка изолирует работу, Pull Request открывает её для проверки, GitHub Actions проверяет тесты автоматически.