Наведите порядок в кодировке

Представьте, что вы заходите в комнату барахольщика. Она полна множества вещей: повсюду чашки, коробки, дохлая мышь, пыль и всевозможные другие вещи. Скорее всего, вы не сможете долго находиться в этом беспорядке: внешний хаос просочится в ваш разум.

И все же, именно это ощущение хаоса может быть тем, что человек несет в себе во время работы.

Беспорядок в работе приводит к хаосу в рабочем процессе.

Каковы отрицательные стороны беспорядка?

Беспорядок:

• заполняет доступную рабочую память данными, не имеющими отношения к решаемой проблеме
• распыляет внимание на несколько мысленных точек
• вызывает переключение между задачами
• что, в свою очередь, может снизить производительность труда и вызвать стресс.

Минимализм как противоядие от хаоса

В контексте работы минимализм можно определить следующим образом:

минимально возможный объем соответствующей работы

Как бы выглядела загроможденная разработка программного обеспечения?

Все, что нарушает приведенное выше определение, может быть определено как беспорядок:

• добавление, но не удаление точек останова во время отладки
• редактирование кода, не имеющего отношения к решаемой проблеме
• попытка реализовать несколько функциональных элементов одновременно
• наличие в поле вашего зрения (например, в вашей IDE) большего, чем необходимо для того, что вы пытаетесь сделать.

Будьте минималистичны…

…следуя TDD

Если задуматься, то TDD (в BDD-формате) совершенно минималистичен. Он заставляет разработчика думать о фактическом поведении, которое ожидает реализации, что затем требует минимального количества кода для того, чтобы это поведение действительно существовало, за чем следует целенаправленное действие по очистке этого кода.

…записав желаемое поведение как ожидающее реализации

context 'when the password is valid' do
  it('creates a session') { pending }
  it('responds with 201 Created') { pending }
end

context 'when the password is invalid' do
  it('does not create a session') { pending }
  it('responds with 422 Unprocessable Entity') { pending }
end

Именно так мне нравится писать свои спецификации в RSpec (Ruby): начиная с определения желаемого поведения моей задачи. Это освобождает меня от необходимости постоянно возвращаться к размышлениям о том, какое еще поведение должно быть у моего решения. Вы записываете свой список дел в виде ожидающих тестов, а затем переходите к их реализации один за другим. В RSpec я предпочитаю использовать опцию focus: true, чтобы убедиться, что тестируется только то, что важно для меня.

…делая коммит после каждого пройденного теста.

Коммиты контроля исходного кода могут затем сделать снимок этого поведения: коммит будет инкапсулировать эту единственную точку добавленной ценности. Каждый снимок будет постепенно создавать окончательную картину, и если в какой-то момент нам понадобится вернуться в прошлое, мы можем быть уверены, что каждый коммит будет содержать рабочую версию приложения с минимальным количеством чистого кода, необходимого для реализации поведения до этого момента.

…закрывая ненужные представления & уплотняя ненужный код.

it 'does this' do ... end

it 'does that' do ... end

it 'does not do Y' do
  # why see more than you care about?
end

context 'when X is true' do ... end

Закройте все вкладки файлов, которые не имеют отношения к текущей задаче. Отладка может заставить вас просмотреть дюжину файлов, но в итоге только два из них станут актуальными. Закройте неактуальные, чтобы сосредоточиться только на том, что вас волнует.

Это относится к любому другому фрагменту кода: классам, функциям, тестам и так далее. Если сейчас вы хотите выяснить, почему пользователь не может отменить подписку, зачем вам смотреть, как будет получена информация о его счетах?

…имея за один раз только столько точек останова, сколько вам нужно.

Иногда мы хотим углубиться в код, чтобы понять, что происходит с данными. Это может привести к добавлению ненужного количества точек останова, которые могут заставить нас ненужно пропускать, пока мы не достигнем нужного места. Удалите то, что вам не нужно, чтобы вы могли сосредоточиться на том, что вас волнует.

…удаляя электронные письма, которые вы не хотите оставлять без внимания.

Помимо разработки, большую часть современного мира составляют электронные письма — и их, конечно, очень много. За день легко набрать тысячу писем, но сколько из них мы хотим просмотреть?

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

Удаляя письма, которые вас больше не интересуют, вы сделаете дополнительный шаг к тому, чтобы видеть только то, что вас интересует, и убережете себя от бомбардировки неактуальными данными. Это мелочи, но их становится все больше.

…концентрируясь на одной задаче за раз.

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

Делайте одно дело и заканчивайте его, прежде чем переходить к следующей задаче.

Заключение

Помимо разработки программного обеспечения, принцип минимализма можно экстраполировать и на жизнь. Применение этих принципов заметно повысило мою продуктивность и одновременно снизило уровень стресса, и я призываю вас попробовать их и посмотреть, поможет ли это и вам.

Счастливого заказа!

Иллюстрация на обложке: Samsul Undangan @ Vecteezy

P.S. Это моя первая статья. Если вам понравилось или вы нашли ее полезной, пожалуйста, подумайте о том, чтобы стать моим подписчиком, так как я планирую писать регулярно.