Данная статья будет неполной без упоминания, что в Питоне тоже есть `Result`, `Maybe` и тд.
И типизация замечательно работает: github.com/dry-python/returns
Не нужно таким людей пугать. Тем более на собеседованиях.
Нужно использовать хороший статический анализатор, который не допустит ни одной ситуации из списка: github.com/wemake-services/wemake-python-styleguide
> У них сохраняется профессиональная гордость за результат труда как это было с ремесленниками до возникновения капитализма.
Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).
Тут возникает важный вопрос «но бизнесу же неважно качества кода, ему важно Х!»
На что могу сказать, что нам в свою очередь не интересен такой бизнес. Потому что есть большое число компаний, которые хотят получить именно то, что мы предлагаем.
> Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Не могу сравнивать, потому что почти ничего про них не знаю. Плюс, меня немного отталкивает их способ маркетинга и заявленные цели. Для меня звучит абсурдно, что люди идут работать программистами из-за денег. Тогда, было бы логично пойти в рекламу ставок, например, там значительно больше денег.
Александр, привет! Большое спасибо за статью — прочитал с большим удовольствием. Мне особенно нравится, что ты ссылаешься на философию и выстраиваешь цепочки не от бизнеса, а от «духовности». Такой подход мне близок.
Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.
В моем случае, микротаскинг — пример того, как можно структурировано общаться, думать об архитектуре, сроках поставки, соблюдении качества и блокировках.
И самый главный мой аргумент:
> Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.
Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.
К сожалению, данный процесс почти не освещен в публичном поле. Да и скажу честно, запроса на освещение тоже нет.
И последнее:
> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.
В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Я не пользовался `zally`. По описанию, они делают очень разное. Насколько я понял, он используется для валидации и «лучших практик». А `schemathesis` используется для тестирования.
Для тех, кто интересуется темой работы с `ast` в Python, можно посмотреть на пример реализации преобразований в реальном проекте: мы делаем самый строгий линтер для Python.
Любителям функционального стиля и python – предлагаю посмотреть на замечательную библиотеку returns, где реализованы основные монады (+типизация) и разные полезные вспомогательные штуки для работы с ними. Очень помогает делать простые вещи – просто.
Там есть все из списка, но и еще куча дополнительных ништяков вроде: `wemake-python-styleguide`, `mypy`, правильный набор плагинов для `pytest`, `poetry` для управления зависимостями, куча всего для безопасности (`bandit`, `safety`, `snyk`)
Плагины, которые такое проверяют:
— github.com/wemake-services/wemake-python-styleguide
— github.com/PyCQA/flake8-bugbear `B012`
И типизация замечательно работает: github.com/dry-python/returns
Нужно использовать хороший статический анализатор, который не допустит ни одной ситуации из списка: github.com/wemake-services/wemake-python-styleguide
Да! Ровно та идея, которая является для меня ключевой. Когда я начинал, я решил отталкиваться от своих ценностей при построении бизнеса. На вопрос «что же я люблю в своей работе?» — главным ответом было «я люблю писать качественный код». Без данной установки — все остальное вообще не имеет смысла. Следовательно, нам было важно создать такую систему, где данная установка работала бы. От нее отталкиваются все остальные идеи: FFF (мы практикуем активно, без него микро-таски не выходят), полная автоматизация всего (оттуда растет весь наш open-source), DDD и программныые средства выразительности для него (без него вообще ничего не работает).
Тут возникает важный вопрос «но бизнесу же неважно качества кода, ему важно Х!»
На что могу сказать, что нам в свою очередь не интересен такой бизнес. Потому что есть большое число компаний, которые хотят получить именно то, что мы предлагаем.
> Было бы интересно узнать больше о твоей системе микротаскинга, например, в сравнении с Zerocracy, так как меня эта тема по настоящему трогает.
Не могу сравнивать, потому что почти ничего про них не знаю. Плюс, меня немного отталкивает их способ маркетинга и заявленные цели. Для меня звучит абсурдно, что люди идут работать программистами из-за денег. Тогда, было бы логично пойти в рекламу ставок, например, там значительно больше денег.
Но про свою компанию я рассказываю, как могу: sobolevn.me/talks/teamleadconf-2020
Полная коллекция тут: sobolevn.me
Для независимого наблюдателя есть возможность сравнить.
Как большой фанат и практик микро-таскинга, хочу сделать несколько комментариев. Во-первых, его действительно можно использовать во зло. Если дать нерадивому «менеджеру» (собирательный образ) любой инструмент — он умудрится его испортить. Например тотальным контролем, недоверием, алчностью или глупостью.
В моем случае, микротаскинг — пример того, как можно структурировано общаться, думать об архитектуре, сроках поставки, соблюдении качества и блокировках.
И самый главный мой аргумент:
> Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.
Напротив, я вижу и слышу, что люди становятся «счастливы» от такой формы организации работы. Потому что результат видно сразу. Ты сделал что-то – и вот оно! Уже в проде, работает! Еще очень многих мотивирует прозрачность и «понятность» процесса.
Я основываю свои практики на том, как ведется разработка в open-source. Где люди *добровольно* организовывают работу похожим образом (с некоторыми допущенями, что open-source пилится урывками раз в неделю перед сном). Вот тут есть хорошее демо: github.com/wemake-services/wemake-python-styleguide Сотни людей, тысячи задачек. Работает как часы. А главное, приносит людям кучу удовольствия. От процесса и результата.
К сожалению, данный процесс почти не освещен в публичном поле. Да и скажу честно, запроса на освещение тоже нет.
И последнее:
> Команды должны состоять из небольшого числа самомотивированных и высокопродуктивных профессионалов.
Имея такую вводную, можно использовать почти любую организацию процесса. Хоть листочки на доске, хоть микро-таски, хоть #NoEstimates. Людям главное не мешать. Проблема возникает, когда такой вводной нет. А её нет в большом количестве случаев. Что делать в таких случаях – я не знаю.
В итоге, можно сказать, что к счастью ведут разные дороги. Главное, понимать, по какой нужно идти именно тебе.
Там есть:
— Типизированные пайплайны: returns.readthedocs.io/en/latest/pages/pipeline.html
— Типизированный `partial` и `curry`: returns.readthedocs.io/en/latest/pages/curry.html
Внезапно оказалось, что разработчикам на Python слова вроде «Монада», «Функтор» и уж тем более «Апликативный функтор» – не знакомы совсем.
Потому мы пришли к другому решению: выкинуть все сложные слова. И заменить их более интуитивно понятными. Монада = контейнер. Функтор = Mappable.
А все объяснения «зачем?!» строить через решение понятных практических задач. Например:
— Монады можно использовать для обработки ошибок вместо исключений
— А еще для внедрения зависимостей
— Ну и чтобы писать асинхронный код!
На мой взгляд — сработало отлично! Многие только потом узнали, куда они ввязались.
Вот тут наши преобразования: github.com/wemake-services/wemake-python-styleguide/tree/master/wemake_python_styleguide/transformations
— github.com/wemake-services/wemake-django-template
— github.com/wemake-services/wemake-vue-template
Любителям функционального стиля и python – предлагаю посмотреть на замечательную библиотеку returns, где реализованы основные монады (+типизация) и разные полезные вспомогательные штуки для работы с ними. Очень помогает делать простые вещи – просто.
Там есть все из списка, но и еще куча дополнительных ништяков вроде: `wemake-python-styleguide`, `mypy`, правильный набор плагинов для `pytest`, `poetry` для управления зависимостями, куча всего для безопасности (`bandit`, `safety`, `snyk`)
Кстати про Python. Туда тоже начинают проникать похожие идеи и подходы: habr.com/ru/company/oleg-bunin/blog/445234