​​🤔 Про личную эффективность и как все успевать?

Недавно в телеграм-канале Федора Борщева, предпринимателя и программиста, поднимался вопрос личной эффективности. Федор делился собственным опытом и нам показалось это интересным, ведь такая проблема стоит у любого IT-специалиста.

✅ Вот, что пишет Федор:


12 дел в день

Одна из областей жизни, которая радикально поменялась у меня при переходе в предпринимательство — это продуктивность. Вернее даже не поменялась, а развалилась нахрен — ГТД в чистом виде не справляется с неопределённостью, которую дают два моих бизнеса. В тяжёлые моменты показатели продуктивности выглядели страшно — каждый новый день в things начинался с 10-15 незакрытых вчера задач. Потупил полдня — лови ещё 20 задач в очереди. Количество встреч тоже зашкаливало — 8 встреч в день было нормой.

К счастью, мне хватило ума не искать новую методику продуктивности, не уезжать в Тибет и не нанимать тренера личной эффективности, а ввести ограничения, которые сильно сократили количество переработок — делать за день не больше 12 дел и проводить в неделю не больше 15 встреч.

Когда жёстко ограничиваешь количество работы, начинаешь более тщательно относиться к выбору задач. К примеру, я почти перестал делать задачи просто ради того, чтобы их сделать. Если уж я и пишу код — я его пишу не чтобы зарелизить фичу, а чтобы показать команде новую технологию или подход. Если я прихожу на встречу с клиентом — я прихожу, чтобы сократить себе, команде и клиенту объём работы, а не послушать отчёт о статусе проекта.


В комментариях писали разное: что отдыхать надо больше; что количество встреч не зависит от нас - как руководство скажет, так и будет; что максимум, сколько можно сделать: 3-4 дела в день и так далее.

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

❓Поделитесь своим опытом в комментариях - какие методики вы используете? Как распределяете время и соблюдаете work-life balance?

🔥 Как правильно писать документацию для кода на Python?

Есть несколько основных способов задокументировать свой код и сделать его более понятным:

→ Обычные комментарии
→ Докстринги
→ Полноценная документация

Давайте рассмотрим каждый способ в отдельности.

✅ ОБЫЧНЫЕ КОММЕНТАРИИ

Обычные комментарии - части кода, которые начинаются в Python с решетки # и содержат небольшие пояснительные сообщения.

Например:

 # проверяем тип полученного ответа
 if isinstance(response): …

Такие комментарии нужны для того, чтобы ваш код было проще читать и понимать. Полноценной документацией они не являются.

✅ ДОКСТРИНГИ

Докстринг (строка документации) - это однострочный или многострочный строковый литерал, разделенный тройными одинарными или двойными кавычками """<denoscription>""" в начале модуля, класса, метода или функции, который описывает, что делает функция.

Только в случае, если это первый оператор в функции, он может быть распознан Python и доступен как атрибуты с помощью метода doc или функции help().

Пример смотрите в карточках 👆🏻


❗️Докстринги могут быть как однострочными, так и многострочными.

Однострочные докстринги обычно дают саммари - кратко описывают: что функция делает и что возвращает. Для шаблона используйте фразу «делает то, возвращает это».

В многострочных докстрингах принято описывать:

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

Примеры однострочного и многострочного докстринга ищите в карточках!


✅ SPHINX

Последнее, про что мы хотим рассказать - Sphinx. В сущности, это те же многострочные докстринги, просто организованные по некоторым правилам. Этакий общепринятый эталон.

Этот стиль является стандартом в Python.

‼️Основные ключевые слова Sphinx:

→ param и type: значение параметра и тип его переменной
→ return и rtype: возвращаемое значение и его тип
→ :raises: описывает любые ошибки, которые возникают в коде
→ .. seealso::: информация для дальнейшего чтения
→ .. notes::: добавление заметки
→ .. warning::: добавление предупреждения

Общая структура документации Sphinx подробно расписана, как вы уже поняли, в карточках 😉


Пользоваться документацией Sphinx в повседневной жизни очень просто.

✅ В IDE PyCharm от JetBrains это идет по умолчанию - достаточно начать писать докстринг и нажать Enter.

✅ Чтобы использовать Sphinx в VS Code, сделайте так:

1. Установите расширение Python Docstring Generator

2. Как только вы начнете набирать докстринг, IDE предложит вам Generate Docstring. По умолчанию генерируется Sphinx. Поменять тип можно в настройках расширения