Магия создания проекта на python

Я скопил целую кучу начатых проектов и чтобы остановить это безумие, я разработал этот манифест.

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

Магическим образом это определит весь процесс вашей работы. Постарайтесь одним-двумя предложениями описать то, к чему Вы стремитесь. Отмечу, что название проекта не обязано точно совпадать с названием продукта.

Примеры названий и девизов известных библиотек:

• requests – A simple, yet elegant HTTP library.
• tqdm – A Fast, Extensible Progress Bar for Python and CLI
• python-telegram-bot – We have made you a wrapper you can't refuse
• redis – Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.
  

Подробно о лицензиях смотрим тут.

А надо ли? Надо! Вспомним библию – "Явное лучше, чем неявное".

Мы говорим о старте открытого продукта, поэтому, долго не думая, выбираем `MIT` или `Apache2.0`.

Я выбираю лицензию Apache2.0, так как она требует добавления в каждый файл следующего заголовка:

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

По-русски - это диздок. Это некромант, но он кастует воскрешение забытых идей. Бывает и так.

Необходимо описать словами свое видение продукта и поместить его в файл `DESIGN.md` в корне проекта.

Что написать в диздоке? Опишите причину создания проекта и вектор его развития.

Почему не в `README`? Потому что Ваша история не нужна случайному пользователю. Диздок в первую очередь защищает Вас от выстрела себе в ногу.

Да, Вы потратите полчаса (а то и час) на изложение своей идеи в письменном виде, но к Вашему проекту будет легко вернутся. В случае с личным проектом это очень важно, так как Вы его чаще НЕ делаете, чем делаете. В долгосрочной перспективе это перерастет в wiki Вашего проекта.

Огромным плюсом является то, что Вы можете обсуждать изменение дизайна продукта прямо в репозитории и изменять гранулярно – коммитами.

У Вас на рабочей машине наверняка стоит супер крутая IDE или фантастически настроен vim, которые автоматически удаляют нежелательные пробелы и пустые строки после сохранения. Однажды вы пропустите такой файл в репозиторий, может быть, сами закоммитите с удаленной машины и случайно пропустите пробелы. Когда Вы решите изменить этот файл на рабочей машине, Ваша замечательная IDE после сохранения перелопатит весь файл. Поэтому обязательно настраиваем линтер для репозитория. Это поможет всегда быстро заметить проблему и решить её ребейзом.

Настроить Workflow на GitHub с литером займет 10 минут, но может спасти от краха истории изменений. А если вы не знакомы с GitHub Actions , то прямо сейчас займитесь этим.

Обзор линтеров тут.

Создайте тест с проверкой базовой функциональности продукта. Пусть тест будет самый простой, но будет!

К чему писать тесты! Продукта же нет!? А это самое удачное время (вспоминаем разработку через тестирование TDD). Здесь мы соединяем наши фантазии об интерфейсе с результатами.

Пока вы его пишите Вы соберете интерфейс на бумаге. Дело в том, что вы с большой вероятностью напишете корявый интерфейс и в последствии измените его, зафиксировав соответствующим комитетом. Изменения в этом тесте будут ценнейшей информацией о продукте, если, конечно, описания Ваших коммитов будут сложнее `FIX design.md` :)

Нужно хитрым образом сделать минимальный ценный продукт и поскорее перейти к следующему шагу.

Определить границу почти невозможно, но возьмите за правило не писать фичи, в которых нет строгой необходимости. Достаточно проходить 50% системного теста.

Системный тест Вы перестали писать, когда устали выдумывать фичи. Тут устали, когда задолбались их реализовывать.

Естественно, написание внутренних модулей сопровождается написанием юнит тестов. Без этого никуда!

Остаток недостающего функционала оставьте хорошо задокументированными пустышками.

Очевидно, что это морда проекта. Как построить продуманный readme смотрите тут.

Тут не о чем говорить, просто сделайте ее! Используйте readthedoc для хостинга.

Настройте CI/CD! После пункта с линтерами Вы уже сечете! У вас не будет времени делать релизы вручную, но захотите пользоваться последней версией своего продукта.

#selectel_инструкция