Жизнь программиста трудна — особенно на начальных этапах. И я до сих пор на нем… Работать продуктивно? Еще сложнее.

Программистам приходится мириться с долгими встречами, пожирающими ваше время. А ведь в это время можно было писать код! Не стоит забывать и о медлительных менеджерах, расплывчатых критериях... Бесспорно, это отнимает время, но есть вещи гораздо хуже — наши вредные привычки.

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

Определите конкретную и четкую цель

В середине рабочего дня я привык отдыхать. Я бы предпочел упорно работать и писать код, чтобы позже иметь возможность почитать обзоры на мотоциклы. Однажды мне пришлось фиксить серьезный баг, а дедлайном был конец рабочего дня. Баг затрагивал множество пользователей. В тот день я работал сосредоточенно, быстро. Причина проста — у меня была конкретная и четкая цель.

Теперь я знаю, что решение найти сложнее, если я не понимаю своей цели. Моя эффективность возрастает, когда я составляю план на день.

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

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

  • Обновить persistence-код для использования библиотеки AndroidX Room.
  • Провести рефакторинг функции Х, чтобы она подчинялась шаблону MVVM.
  • Создать первых два окна пользовательского интерфейса.

Определите минимальные критерии жизнеспособности продукта и приступайте к работе

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

Позже я понял, что главное — создать рабочий минимально жизнеспособный продукт (MVP). Звучит, конечно, очевидно — естественно я должен создать что-то рабочее! Но кое-что я, конечно, постоянно упускал из виду: необходимость есть только в этом минимуме. Ни больше и ни меньше.

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

Итак, как же узнать, когда стоит закончить работу? Когда все просто… работает.

Очевидно, что есть критерии, которым необходимо соответствовать. Но самое важное — во время работы нужно отвечать себе на эти вопросы:

  • Соответствует ли код нужной архитектуре?
  • Сведены ли баги к минимуму?
  • Может ли кто-то помимо вас понять происходящее в коде?
  • Покрыты ли все сценарии использования?

Работайте с разными ветками проекта как можно больше

Чем сложнее задания вы выполняете, тем выше вероятность появления критических ошибок. Что самое страшное — появиться они могут тогда, когда вы закоммитите ее в мастер-ветку.

Когда я впервые получил серьезное задание, я был очень взволнован. Мне нужно было провести рефакторинг функции, чтобы она была написана на Kotlin и подчинялась шаблону MVVM. К сожалению, у меня не было необходимого опыта — я не смог грамотно протестировать код. После этого я закоммитил его в мастер-ветку, когда git сильно лагал. Через несколько дней тестировщики столкнулись с моим кодом и были в ужасе. Я две недели подряд исправлял кучу ошибок. Я задержал всю команду, а причиной была моя лень — я не протестировал свой код тщательным образом. И раз я закоммитил все правки, то существовала вероятность, что релиз мог быть отложен.

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

Не беритесь за нечетко сформулированные задания

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

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

Не знаю, как вы, но я хочу только писать код. Я не хочу общаться с заказчиками, проверять элементы пользовательского интерфейса, составлять критерии приема, постоянно спрашивать бэкенд-команду об API…

Я просто хочу писать код!

Именно поэтому я беру лишь те задания, которые соответствуют следующим критериям:

  • Все ли зависимости составлены и работают?
  • Доработан и утвержден ли пользовательский интерфейс?
  • Могу ли я легко связаться с людьми, которые отвечают за эту работу?
  • Понятны ли критерии приемлемости? Смогу ли я их понять, если прочту их в нетрезвом виде?
  • Готовы ли инструменты и SDK? Есть ли необходимые лицензии для них.

Перевод статьи: Practices That Doubled My Productivity as a Developer