[Высокая производительность, Программирование] Как не сгореть на проекте
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет всем! Сначала я хотел отразить в заголовке что-то про личную эффективность, но потом решительно отверг эту идею. Заранее хочу отметить, что речь здесь пойдет не столько о достигаторстве и правильной постановке цели (хотя это немаловажно), а скорее о личном опыте и о событиях, которые привели меня прямиком в объятия этого вопроса (причем случилось это довольно спонтанно). Также я отмечу базовые способы упрощения работы, они настолько просты, насколько и эффективны.
Предыстория
Большую часть своей девелоперской карьеры (как фронтенд, так и фулстэк), я задумывался о немаловажной задаче: о производительности кода. Однако личная эффективность как-то выпадала из зоны моих интересов… Ну не то, чтобы прямо совсем, но надолго там не задерживалась, поэтому познания в данной области до сих пор у меня были весьма и весьма ограничены и отрывисты.
Минуя долгие пояснения, перейду сразу к… Кульминации моей истории, которая произошла этим летом. Так получилось, что сошлись абсолютно все звезды, которые только могли это сделать. Тут было все: мне активно не нравился мой проект, причем меня перевели еще и на новый, который мне нравился (на тот момент) еще меньше, “добавлял” счастья и близкий дедлайн, подливали масла в огонь регулярные происшествия с локальным окружением, довольно большие проблемы в личной жизни, отмена рейса, благодаря которой я застрял в другом городе, если добавить сюда эпидемию, то получится довольно полная и понятная картина. Все это привело к тому, что я начал гореть: мне было трудно работать, тяжело выполнять мало мальски сложные задачи, все время хотелось куда-то сбежать: чай, ютуб, книга и тд. В какой-то момент я понял, что работать больше не могу (ну вот прямо совсем). Оно и понятно, ведь вся моя работа последние месяцы строилась на самопринуждении: я заставлял себя работать. Довольно логичный результат.
Очевидные способы выйти из этой ситуации: попытаться изменить проект или уйти в отпуск. Но, во-первых, это не происходит моментально, а, во-вторых, я не знал, насколько меня хватит после отпуска или на новом проекте. Тогда сам себе задал вопрос: а чего я, собственно говоря, хочу? Оказалось, что чего угодно, но не программировать (удивительно). Например, пить чай (интересно, как отвечают на этот вопрос другие люди, оказавшись в схожей ситуации, но, возможно, мы этого никогда не узнаем). И я сказал себе, “окей пойду пить чай, но сначала сделаю хотя бы что-то”. И это очень важный момент, пытаясь понять, что же в таком состоянии могу сделать, начал делить задачу на микрозадачи и отсекать лишнее. Звучит просто и логично, более того — это азы проектирования. Однако, на самом деле, не все так радужно. В процессе выполнения задачи, мы все равно смотрим на задачу как на некий монолит, хотя, возможно, до этого она была разбита на составляющие. Более того, мы постоянно задаемся сотней разных вопросов, а что будет, если произойдет вот это (скажем, от сервера прилетит ответ с ошибкой).
До какой степени упрощать задачу
Задачу я дробил не на самостоятельные модули, а до тех пор, пока они не стали элементарными и не перестали вызывать у меня внутреннего сопротивления. В общем случае это может звучать следующим образом:
- Создать компоненту заглушку с базовым интерфейсом
- Подключить ее
- Добавить разметку
- Передать реальные данные
- Добавить стили
- Написать тесты
Если и это будет сложно, тогда эти шаги можно или уточнить, или разрабатывать компоненту по частям. (А как это делаете вы?)
Далее я хочу обратить внимание на три важных принципа:
Разделение задачи на элементарные
В моем случае, начальный этап выглядел примерно так:
- Создать заглушку компоненты с “рыбным” текстом
- Добавить для нее роут
- Проверить, что она подключилась
- Выяснить по каким адресам надо получать данные с сервера
Результат такого решения:
- Задачи элементарны, даже в таком состоянии я смотрю на них с некоторым облегчением, а не с отвращением
- На таких задачах легче концентрироваться
- Также снижен уровень стресса (я себя не принуждаю, а задачи не такие пугающе большие)
Фокусировка внимания на узком спектре подзадач
- Затрачивается меньше времени на выполнение подзадач
- Затрачивается меньше мозговых ресурсов
- Как следствие, сама задача выполняется быстрее
Ограниченность одной итерации по времени
- Я легко могу договориться с собой о том, что сейчас я минут 15 поработаю, а потом сделаю приятный перерыв на 5 минут. В то время как убедить себя (заставить) отработать целый день будет сложнее и неприятнее
Подведем итоги
Чтобы не тратить свое и чужое время постараюсь сделать это максимально коротко:
- Работа перестала быть для меня стрессом
- Я стал меньше уставать к концу дня
- Выросла производительность в сравнении с нестрессовым значением: раньше задача на 3 стори поинта + написание тестов занимала у меня 2 дня, теперь же получалось не больше полутора
- Более профессиональным подходом является использование таймера. О моих успехах (и неудачах, куда ж без них) внедрения техники помидора я бы хотел поговорить в другой раз.
===========
Источник:
habr.com
===========
Похожие новости:
- [JavaScript, Программирование, Разработка веб-сайтов] Server-Sent Events: пример использования
- [Программирование, Изучение языков] Hi Programming Language
- [Высокая производительность, Компьютерное железо, Презентации, Видеокарты, Настольные компьютеры] RTX 3080 – Мечта, которой нет в наличии
- [Python, Высокая производительность, Распределённые системы, Финансы в IT] Собираем данные AlphaVantage с Faust. Часть 1. Подготовка и введение
- [JavaScript, PostgreSQL, Программирование, Алгоритмы] Immutable Trie: найди то, не знаю что, но быстро, и не мусори
- [Python, Программирование, Визуальное программирование] Опыт проведения городской школьной олимпиады по программированию
- [Беспроводные технологии, Программирование микроконтроллеров, Разработка для интернета вещей, Производство и разработка электроники, Интернет вещей] ИК датчик движения на STM32
- [Информационная безопасность, Программирование, CTF] Мамкины хацкеры или мой путь в CTF
- [Функциональное программирование, Lisp, Работа с векторной графикой, Программирование] Опубликован Scheme Request For Implementation — 203: A Simple Drawing Language in the Style of SICP
- [Ноутбуки, Программирование, Процессоры, Смартфоны] ARM против x86: В чем разница между двумя архитектурами процессоров?
Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_programmirovanie (Программирование), #_vygoranie (выгорание), #_povyshenie_produktivnosti (повышение продуктивности), #_emotsionalnoe_vygoranie (эмоциональное выгорание), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_programmirovanie (
Программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Привет всем! Сначала я хотел отразить в заголовке что-то про личную эффективность, но потом решительно отверг эту идею. Заранее хочу отметить, что речь здесь пойдет не столько о достигаторстве и правильной постановке цели (хотя это немаловажно), а скорее о личном опыте и о событиях, которые привели меня прямиком в объятия этого вопроса (причем случилось это довольно спонтанно). Также я отмечу базовые способы упрощения работы, они настолько просты, насколько и эффективны. Предыстория Большую часть своей девелоперской карьеры (как фронтенд, так и фулстэк), я задумывался о немаловажной задаче: о производительности кода. Однако личная эффективность как-то выпадала из зоны моих интересов… Ну не то, чтобы прямо совсем, но надолго там не задерживалась, поэтому познания в данной области до сих пор у меня были весьма и весьма ограничены и отрывисты. Минуя долгие пояснения, перейду сразу к… Кульминации моей истории, которая произошла этим летом. Так получилось, что сошлись абсолютно все звезды, которые только могли это сделать. Тут было все: мне активно не нравился мой проект, причем меня перевели еще и на новый, который мне нравился (на тот момент) еще меньше, “добавлял” счастья и близкий дедлайн, подливали масла в огонь регулярные происшествия с локальным окружением, довольно большие проблемы в личной жизни, отмена рейса, благодаря которой я застрял в другом городе, если добавить сюда эпидемию, то получится довольно полная и понятная картина. Все это привело к тому, что я начал гореть: мне было трудно работать, тяжело выполнять мало мальски сложные задачи, все время хотелось куда-то сбежать: чай, ютуб, книга и тд. В какой-то момент я понял, что работать больше не могу (ну вот прямо совсем). Оно и понятно, ведь вся моя работа последние месяцы строилась на самопринуждении: я заставлял себя работать. Довольно логичный результат. Очевидные способы выйти из этой ситуации: попытаться изменить проект или уйти в отпуск. Но, во-первых, это не происходит моментально, а, во-вторых, я не знал, насколько меня хватит после отпуска или на новом проекте. Тогда сам себе задал вопрос: а чего я, собственно говоря, хочу? Оказалось, что чего угодно, но не программировать (удивительно). Например, пить чай (интересно, как отвечают на этот вопрос другие люди, оказавшись в схожей ситуации, но, возможно, мы этого никогда не узнаем). И я сказал себе, “окей пойду пить чай, но сначала сделаю хотя бы что-то”. И это очень важный момент, пытаясь понять, что же в таком состоянии могу сделать, начал делить задачу на микрозадачи и отсекать лишнее. Звучит просто и логично, более того — это азы проектирования. Однако, на самом деле, не все так радужно. В процессе выполнения задачи, мы все равно смотрим на задачу как на некий монолит, хотя, возможно, до этого она была разбита на составляющие. Более того, мы постоянно задаемся сотней разных вопросов, а что будет, если произойдет вот это (скажем, от сервера прилетит ответ с ошибкой). До какой степени упрощать задачу Задачу я дробил не на самостоятельные модули, а до тех пор, пока они не стали элементарными и не перестали вызывать у меня внутреннего сопротивления. В общем случае это может звучать следующим образом:
Если и это будет сложно, тогда эти шаги можно или уточнить, или разрабатывать компоненту по частям. (А как это делаете вы?) Далее я хочу обратить внимание на три важных принципа: Разделение задачи на элементарные В моем случае, начальный этап выглядел примерно так:
Результат такого решения:
Фокусировка внимания на узком спектре подзадач
Ограниченность одной итерации по времени
Подведем итоги Чтобы не тратить свое и чужое время постараюсь сделать это максимально коротко:
=========== Источник: habr.com =========== Похожие новости:
Высокая производительность ), #_programmirovanie ( Программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 16:20
Часовой пояс: UTC + 5