Искусство упрощения для программистов.
Недавно я наткнулся на очень интересную книгу авторства Nagisa Tatsumi. Называется она “Искусство упрощения: как избавиться от беспорядка и найти радость” (“The Art of Discarding: How to Get Rid of Clutter and Find Joy”).
В этой книге рассказывается о способах отказа от ненужных вещей в вашей жизни, которые уже не приносят пользу, но вам от них сложно избавиться.
Чем больше я читал по этой теме, тем больше чувствовал, насколько она актуальна и для профессиональн?
Искусство упрощения для программистов...
Недавно я наткнулся на очень интересную книгу авторства Nagisa Tatsumi. Называется она “Искусство упрощения: как избавиться от беспорядка и найти радость” (“The Art of Discarding: How to Get Rid of Clutter and Find Joy”).
В этой книге рассказывается о способах отказа от ненужных вещей в вашей жизни, которые уже не приносят пользу, но вам от них сложно избавиться.
Чем больше я читал по этой теме, тем больше чувствовал, насколько она актуальна и для профессиональных разработчиков. Вот и решил написать об этом статью.
Книга состоит из трёх разделов:
- 10 полезных привычек, которые помогут избавиться от лишнего.
- 10 стратегий для упрощения жизни.
- Альтернативные способы “выбрасывания”.
Привожу выжимку из этих разделов с точки зрения ИТ-профессионала.
Не складируйте по принципу “пока что пусть будет”
Часто у нас бывает кусок “мёртвого” кода, который кто-то там написал для какой-то функции, чтобы когда-нибудь собраться и имплементировать её. Или же есть работающая задача/служба, которая не используется, но с тех пор, как вы получили ее от кого-то ещё, вы боитесь остановить ее работу. Во всех подобных случаях обычно говорят: “ну пусть побудет пока что”.
Автор книги предлагает следующее: если вы не пользовались кодом, задачей, службой некоторое время, лучше уберите их. Насовсем. Высока вероятность того, что они не понадобятся и в будущем.
Избегайте временных хранилищ — решайте сразу
Когда я создавал системы, то иногда попадал в ситуации, когда люди подытоживают что-то словами: “Давайте-ка оставим эти данные здесь на какое-то время, а потом внесём изменения”. Ещё они могут говорить так: “Давайте пока что будем использовать этот метод, а потом как-нибудь найдём другой”.
Есть ещё одна сторона: когда мы просим людей убрать что-то, они делают это не до конца — перемещают ненужные объекты во временное хранилище. Автор книги предлагает решать сразу же, если вы хотя бы уже задумались убрать что-то попозже. Не перемещайте во временное хранилище — удаляйте сразу и навсегда.
Когда-нибудь никогда не наступает
Когда людей просят убрать что-то, они часто возражают, что это может когда-нибудь да пригодиться…
Автор Nagisa Tatsumi говорит, что большинство людей не выбрасывает ничего, оправдывая себя тем, что эти вещи пригодятся в будущем. Ну хоть когда-то, неизвестно через сколько лет. Однако в большинстве случаев этот торжественный момент приходит… никогда. Так что, если найдёте что-то бесполезное, сразу же выбрасывайте.
Ну ничего святого у людей!
Если вам “по наследству” достался гигантский кусок кода, то там всегда найдутся классы, скрипты и целые блоки, к которым относятся, как к священным артефактам. Люди реально боятся изменять их и тем более удалять. Они думают, что всё сломается, если тронуть этот раритетный код.
Мы должны понять, что со временем определённые функции и свойства теряют свою актуальность, а сохранять код обновлённым, удаляя “мёртвые” части очень важно. Так в ваших программах будет всё чисто и понятно.
Сложно, но можно: не беспокойтесь потерять что-то полезное
Это самый большой страх при разборе вещей. Всегда важно определить, полезный предмет или нет. Бывает, решить это сложно.
Порой вы не уверены и не можете определиться: откладывать или выбрасывать. В таких случаях помогает действовать пошагово. Например, вы можете оставить службу/задачу в работе даже после исследования их полезности. Вы просто не знаете или не можете понять, полезные это штуки или нет. Тогда вместо полного удаления служб или задач начинайте с того, что уберёте их выполнение из графика.
Такой подход поможет определить реальную пользу. Так легче: если что-то сломается, то вы сможете быстренько вернуть прежние объекты на место.
Не гонитесь за совершенством
Чтобы наловчиться в этом искусстве упрощения, нужно время. Не пытайтесь стать гуру “уборки” за один день. Начните с малого. А потом продолжайте практиковаться в плюсах и минусах делания чего-то или, наоборот, бездействия.
Со временем вы станете мастером в этом.
Постоянное упрощение
Приучитесь разгребать свои завалы чаще, чем раз в год. Например, каждый сезон. Это поможет вам убрать ненужные загрузки из системы.
Сейчас мы привыкли к облачным технологиям во многих программных разработках, а их использование стоит денег. Можно немного сэкономить, если регулярно убирать ненужные моменты.
Установите критерий отказа
Принимать решение, от чего следует отказаться, должен не один человек. Лучше обозначить определенные критерии. Так принимать решения будет проще.
Например, критерии можно обозначить так:
- Пользуется ли кто-то активно этим свойством, функцией, службой?
- Что происходит после временного отключения свойства, функции, службы?
- Сэкономите ли вы деньги, если уберете это свойство, функцию, службу?
- Улучшается ли производительность, если убрать это свойство, функцию, службу?
- Снижается ли уровень стресса в рабочей команде, если отказаться от некоторых задач? Смогут ли они переключить своё внимание на более важные занятия с точки зрения бизнеса?
Сохраняйте баланс: не думайте, что всё вокруг — это мусор
Автор постоянно подчёркивает этот тезис. Некоторые вещи появляются у нас потому, что мы сами их захотели получить или приобрести какое-то время назад.
Со временем требования, пользователи и запросы изменяются, в результате чего определенные детали теряют пользу. Следовательно, от них нужно отказаться. Если будете держать это в уме, отказываться будет намного проще.
Заключение
Подводя итог, скажу, что будь то жизнь или ПО, вещи со временем стареют, и следовательно важно тренироваться в искусстве отсечения ненужного, чтобы сохранить свою жизнь и систему необременённой и чистой.
