Продвинутый пайтон для аналитики?
Или как же разобраться с бардаком в своих юпитер-блокнотах?

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

В результате через полгода такой практики обнаружил себя посреди кодового бардака:

какие-то куски кода я оборачиваю в функции, а что-то остаётся просто в теле программы (или как это будет по-питонячьи?)

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

Когда в очередной раз мне нужна функция, я не могу найти файлик, где она в последней-самой-хорошей версии. Беру другую версию, дорабатываю её — и вот у меня ещё одна «последняя» версия.

Думал выделить в отдельный модуль общие функции и развивать там. Увидел такое в открытом коде вастрик.клуба — там есть специальная папочка-модуль Common и там всё «общее», что может потребоваться в нескольких местах
https://github.com/vas3k/vas3k.club/tree/master/common

кажется, если углубиться в пайтон, то там ещё много таких приёмников, которые могли бы сильно упростить жизнь аналитикам (и тем, кто потом релизит их код на прод!).

решил углубить свои знания в питоне — уделю этому сентябрь. Пробую сервис от JetBrains: маленькие кусочки теории, обложенные практическими задачами.
https://hyperskill.org/

а вот Фёдор Борщёв для изучения питона рекомендует прочитать от корки до корки Марка Лутца и сделать все «домашки» оттуда (пост и подкаст)

#python

нужны ли алгоритмы программистам?

холиварный выпуск Moscow Python подкаста: Григорий Петров и Злата Обуховская накидывали на вентилятор, направленный на Асю Воронцову из Яндекса.

Тезис №1: знание алгоритмов нужны только тем, кто работает с высоконагруженными сервисами, где важна эффективности. Типа ядра Линукса или поисковика Яндекса. (важно отметить: даже в самом Яндексе не все работают с хайлоадом)

Тезис №2: внедрение алгоритмов в код ухудшает его читаемость. Это важно, т.к. код больше читается, чем пишется.

Тезис №3: времязатраты на написание эффективного кода не всегда окупается. Можно потратить две недели на код, который даёт всего 5% в сравнении с уже готовой библиотекой.

Тезис №4: профилировщик — лучший друг программиста. Это снимает большинство вопросов с эффективностью. Например, он подскажет, если вдруг код зайдёт в цикл.

Тезис №5: в больших компаниях спрашивают знание алгоритмов (и умение их писать на бумажке) не только ради самого знания, но и просто как ещё один фильтр, чтобы отсеять людей, которые уже приложили усилия и вызубрили редко используемую информацию.

#data_podcast в iTunes и overcast

#python
#algorithms

Software Craftsmanship — рецепт хорошего кода от Григория Петрова
(цитата из подкаста про алгоритмы)

вместо того, чтобы учиться писать на бумажке сортировку Ахо-Корасик,
Григорий предлагает учиться писать код, который потом будет легко читать и поддерживать.

Как можно улучшить свой код:
⁃ писать читаемый код
⁃ рассказывать историю через код
⁃ давать понятные имена идентификаторам
⁃ пользоваться гитом
⁃ включать профилировщик
⁃ настроить себе Continuous Integration

#software_engineering
#python