Привет всем! Сначала я хотел отразить в заголовке что-то про личную эффективность, но потом решительно отверг эту идею. Заранее хочу отметить, что речь здесь пойдет не столько о достигаторстве и правильной постановке цели (хотя это немаловажно), а скорее о личном опыте и о событиях, которые привели меня прямиком в объятия этого вопроса (причем случилось это довольно спонтанно). Также я отмечу базовые способы упрощения работы, они настолько просты, насколько и эффективны.
Предыстория
Большую часть своей девелоперской карьеры (как фронтенд, так и фулстэк), я задумывался о немаловажной задаче: о производительности кода. Однако личная эффективность как-то выпадала из зоны моих интересов… Ну не то, чтобы прямо совсем, но надолго там не задерживалась, поэтому познания в данной области до сих пор у меня были весьма и весьма ограничены и отрывисты.
Минуя долгие пояснения, перейду сразу к… Кульминации моей истории, которая произошла этим летом. Так получилось, что сошлись абсолютно все звезды, которые только могли это сделать. Тут было все: мне активно не нравился мой проект, причем меня перевели еще и на новый, который мне нравился (на тот момент) еще меньше, “добавлял” счастья и близкий дедлайн, подливали масла в огонь регулярные происшествия с локальным окружением, довольно большие проблемы в личной жизни, отмена рейса, благодаря которой я застрял в другом городе, если добавить сюда эпидемию, то получится довольно полная и понятная картина. Все это привело к тому, что я начал гореть: мне было трудно работать, тяжело выполнять мало мальски сложные задачи, все время хотелось куда-то сбежать: чай, ютуб, книга и тд. В какой-то момент я понял, что работать больше не могу (ну вот прямо совсем). Оно и понятно, ведь вся моя работа последние месяцы строилась на самопринуждении: я заставлял себя работать. Довольно логичный результат.
Очевидные способы выйти из этой ситуации: попытаться изменить проект или уйти в отпуск. Но, во-первых, это не происходит моментально, а, во-вторых, я не знал, насколько меня хватит после отпуска или на новом проекте. Тогда сам себе задал вопрос: а чего я, собственно говоря, хочу? Оказалось, что чего угодно, но не программировать (удивительно). Например, пить чай (интересно, как отвечают на этот вопрос другие люди, оказавшись в схожей ситуации, но, возможно, мы этого никогда не узнаем). И я сказал себе, “окей пойду пить чай, но сначала сделаю хотя бы что-то”. И это очень важный момент, пытаясь понять, что же в таком состоянии могу сделать, начал делить задачу на микрозадачи и отсекать лишнее. Звучит просто и логично, более того — это азы проектирования. Однако, на самом деле, не все так радужно. В процессе выполнения задачи, мы все равно смотрим на задачу как на некий монолит, хотя, возможно, до этого она была разбита на составляющие. Более того, мы постоянно задаемся сотней разных вопросов, а что будет, если произойдет вот это (скажем, от сервера прилетит ответ с ошибкой).
До какой степени упрощать задачу
Задачу я дробил не на самостоятельные модули, а до тех пор, пока они не стали элементарными и не перестали вызывать у меня внутреннего сопротивления. В общем случае это может звучать следующим образом:
- Создать компоненту заглушку с базовым интерфейсом
- Подключить ее
- Добавить разметку
- Передать реальные данные
- Добавить стили
- Написать тесты
Если и это будет сложно, тогда эти шаги можно или уточнить, или разрабатывать компоненту по частям. (А как это делаете вы?)
Далее я хочу обратить внимание на три важных принципа:
Разделение задачи на элементарные
В моем случае, начальный этап выглядел примерно так:
- Создать заглушку компоненты с “рыбным” текстом
- Добавить для нее роут
- Проверить, что она подключилась
- Выяснить по каким адресам надо получать данные с сервера
Результат такого решения:
- Задачи элементарны, даже в таком состоянии я смотрю на них с некоторым облегчением, а не с отвращением
- На таких задачах легче концентрироваться
- Также снижен уровень стресса (я себя не принуждаю, а задачи не такие пугающе большие)
Фокусировка внимания на узком спектре подзадач
- Затрачивается меньше времени на выполнение подзадач
- Затрачивается меньше мозговых ресурсов
- Как следствие, сама задача выполняется быстрее
Ограниченность одной итерации по времени
- Я легко могу договориться с собой о том, что сейчас я минут 15 поработаю, а потом сделаю приятный перерыв на 5 минут. В то время как убедить себя (заставить) отработать целый день будет сложнее и неприятнее
Подведем итоги
Чтобы не тратить свое и чужое время постараюсь сделать это максимально коротко:
- Работа перестала быть для меня стрессом
- Я стал меньше уставать к концу дня
- Выросла производительность в сравнении с нестрессовым значением: раньше задача на 3 стори поинта + написание тестов занимала у меня 2 дня, теперь же получалось не больше полутора
- Более профессиональным подходом является использование таймера. О моих успехах (и неудачах, куда ж без них) внедрения техники помидора я бы хотел поговорить в другой раз.
