Как стать автором
Обновить

Комментарии 7

Вы бы проверили ваш код на работоспособность? А то и отступы испортились, и какой то html/css виден?

А только мне кажется, что Conventional Commits делались вообще не для людей? Поэтому IRL их особо не видать. Статья от хекслета отличная

В каком-то опенсорсном проекте краем глаза видел подобные сообщения (точно не вспомню).

Ёжики кололись, но продолжали есть кактус, потому что понятнее варианта не нашли. Когда людей в репо (да и форков) становится более одного и начинают лететь непричёсанные мержи с кучей коммитов (историю же мы не теряем), пуллреквесты и прочее, версии зафиксированные где-то кем-то у себя на коленке в файлике превращаются в тыкву. Тем более что это ещё нужно вынудить массу людей строго ставить все эти не несущие полезной нагрузки тысячи "feat:" съедающих и без того короткий заголовок. Если пробежаться вскользь по упомянутым тем же хекслетом linux, git или в какой-нибудь KeePassXC, ShareX заглянуть, то там совсем другие выстраданные годами бестпрактисы и вообще основная разработка ведётся в бранчах (которые в свою очередь именуются как feature/***, hotfix/***, если немного про git flow), а затем мержится. Как будет в этом зоопарке вести себя cz - мне вообще не понятно. А вот номер таски в конце заголовка коммита видеть хочется, его потом можно удобно глянуть через git log --oneline, git shortlog без лишних телодвижений.
Там же тянется семантическое версионирование, которое тоже заслуживает отдельных разборок. Потому что, например, version.rc для форточек требует 4 цифры, а валидаторы предложенные на semver.org радостно фейлят такое. Ещё интереснее становится когда хочешь чтобы CI на гитхабе сам собирал тебе релиз и собирал его через PyInstaller в готовую сборку, в которой идентична версия внутри приложения, в version.rc, в теге, в описании к релизу, без лишних инструментов и телодвижений.

Плюс в теге хочется видеть не только искуственно выстраданный номер (который соответствует которому форку репозитория?), но и настоящий хэш коммита.

"забавно" - единственная оценка -1 - "за личную неприязнь к автору или компании"

У кого-то ко мне личная неприязнь?! Считаю это уже популярностью )))

Поработав с питоном, для себя, пришёл к выводу, что писать тесты на стандартной библиотеке крайне не удобно. Как пример если функция имеет ветвления, сразу получается что надо написать N тестов с одинаковым вызовом функции и разными входными и (возможно) выходными данными. Код тестов превращается в злостную копипасту. Другое дело pytest с его параметризованными тестами и фикстурами. Получается что нужно написать один тест и скармливать ему разные данные, что очень удобно и просто поддерживать.

Ещё одно это сам стиль тестов при работе с unittest либой, обязательное наследование и как следствие все тесты объединены в классы. Pytest же не накладывает таких ограничений и всегда можно писать тесты без указания классов просто объеденяя их в модули и легко перенося в случае рефакторинга.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории