Перевод статей «Software engineer —Productivity: workflow» и «8 productivity coding tips for a Software Engineer».
«Советы по продуктивности» это серия статей общего назначения для программистов. Советы из этих постов могут применяться вне зависимости от того, в какой среде вы работаете, какой фреймворк используете и на каком языке пишете код.
Я ленив и очень ценю самую ценную нашу валюту: время. Экономить его очень помогает повышение эффективности труда.
За годы работы я сумел уменьшить время, которое ежедневно трачу на написание кода, с 8 до 5 часов. Мне удалось этого достичь благодаря применению техник, которые я изложу ниже.
Советы по организации рабочего процесса
Разработчик не может масштабироваться подобно серверам: если он больше работает, это не значит, что он поставляет более качественный код.
Перерывы каждый час
Если вы курильщик, то можете этот пункт пропустить: скорее всего вы и так делаете подобные паузы.
Перерывы на несколько минут каждый час полезны для моего здоровья (из-за ходьбы) и повышают мою продуктивность. Если у вас на работе есть зона отдыха с играми или другими интерактивностями, – посещайте ее. Или хотя бы ходите по офису. Я здесь плохой пример: я самый отъявленный пассивный курильщик в офисе, поскольку свои перерывы провожу в зоне для курения.
Если вы применяете в работе прием помидора, то у вас с перерывами все в порядке. Я делаю примерно то же самое, просто ставлю таймер на не 20 минут, а на 50 (это больше подходит для моего теперешнего рабочего процесса).
«Один из самых важных навыков программиста – знание, когда нужно ненадолго уйти», – Оскар Годсон.
Разработчики много печатают, но нам нужно больше думать и меньше писать код.
«Зона» это рискованная зависимость
Регулярные перерывы имеют дополнительное преимущество: они предотвращают чрезмерное пребывание «в зоне», которое с большой вероятностью может навредить коду. Когда вы углубляетесь в проблему, вам тяжело видеть ее края.
Я думаю, что «зона» это наша естественная среда, но только до определенного предела. Вы можете слишком сфокусироваться на проблеме/коде и в результате пишете код «в вакууме», «в пузыре». Выбравшись из этого пузыря, вы обнаруживаете, что забыли о чем-то, потому что ваше внимание было чересчур сфокусированным на маленькой зоне видимости.
- «Я забыл, что у нас есть этот функционал в модуле Х, поэтому просто написал новый».
- «Я забыл поговорить с Х по поводу этой задачи» (насчет крайних случаев или деталей реализации).
- «Я пропустил модульные тесты: сделаю их завтра, они бы замедлили мою работу».
- «Я использовал нечто, неподдерживаемое на платформе Х, я просто забыл».
В общем, вы можете допустить все те же ошибки, которые случаются, когда вы спешите, когда сроки поджимают или когда не уделяете работе достаточно внимания.
В большинстве случаев «зона» дает нам иллюзию продуктивности.
Я на 100% уверен, что вы напишете больше кода, но как насчет его качества? Чтобы оценить, является ли код, написанный «в зоне», более качественным, вам нужно измерить время, потраченное на его написание + время, потраченное на его исправление + время, потраченное на отладку + временные затраты, связанные с багами в этом коде за весь жизненный цикл кода. Долго работая «в зоне», вы имеете быструю первую итерацию, но длительность последующих стадий увеличивается.
Этот эффект также проявляется, когда разработчик использует свой мозг как «кучу» (Heap), пытаясь понять кусок кода (обычно гнилого – для воспроизведения бага). Справиться с этим можно несколькими способами, например, сразу сделать рефакторинг кода и использовать подходящий отладчик.
За годы своей работы я обнаружил небольшое количество сценариев, когда длительное пребывание «в зоне» хорошо для бизнеса. Например, когда весь проект целиком умещается в вашей голове, т. е., когда он достаточно маленький и работаете вы над ним в одиночку. Или когда вы делаете прототип или первую версию библиотеки. А также, когда работаете над единым, но сложным алгоритмом.
Кроме этих случаев я не нашел никаких положительных сценариев, когда разработчик пребывает «в зоне» дольше 40-70 минут и при этом не допускает как минимум 1 ошибки, портящей часть конечного кода.
PS: это, конечно, обобщение и я уверен, что бывают и исключения.
Отвлекающие факторы
Понаблюдайте за собой, припомните, что было наиболее частой причиной прерываний вашего рабочего процесса, поищите шаблоны. Постарайтесь исправить их самостоятельно или поговорите на эту тему с другими членами команды на ваших периодических ретроспективных собраниях.
Отвлекающие факторы могут принимать разнообразные формы. Это может быть падающий сервер стейджинга, постоянная проверка социальных сетей или шум от кофемашины.
Конечно, легче сказать, чем сделать, но тем не менее: не логиньтесь в социальных сетях.
Научитесь переключать «отладчик» – ваш мозг
Если вы застряли на одной проблеме дольше 5-15 минут, – отступайте. Вы попали в лабиринт и не осознаете этого. Пытаясь выбраться из него, вы вредите себе и, вероятно, своему коду. Продолжая тратить зря время, вы вредите также команде/продукту/работодателю.
Отступите, подумайте о чем-то другом, поговорите с коллегами, отключите «отладчик» и вернитесь к этой проблеме позже, подойдя к ней с другой стороны.
Используйте ваш мозг в режиме «очереди» (queue)
Как справляться с поступающими во время работы запросами:
- Если вы заняты – добавьте новую задачу в список TODO.
- Если к вам обратились лично – посоветуйте обратившимся в следующий раз использовать асинхронные системы коммуникации (чат, email).
- Пересматривайте приоритеты после выполнения текущей задачи.
Чтобы эта техника работала, вам нужно разбивать свои ежедневные задачи на маленькие кусочки и делать регулярные перерывы.
Уведомления
Хорошие уведомления: могут использоваться для устранения отвлекающих факторов. Например, вместо проверки командного чата каждые 10 секунд вы можете настроить уведомления.
Плохие уведомления: получение рассылок.
Отключите как можно больше уведомлений. Делайте все возможное для экономии своего времени.
Совет: в смартфонах есть режим DND (Do Not Disturb — «не беспокоить»), обеспечивающий режим тишины по ночам или в рабочее время.
Мобильность
Будьте мобильны – используйте ноутбук. Впрочем, вы наверняка и так это делаете.
Советы по написанию кода
Автоматизируйте команды
Понаблюдайте за собой, определите, какие команды вы вводите каждый день многократно и сократите их, если нужно – сгруппируйте. Если вы используйте только визуальный клиент git, вам стоит изучить команды, стоящие за ним.
Используя псевдонимы (aliases), вы будете делать меньше человеческих ошибок и сумеете доставлять больше. Убирайте скучные шаги из вашей ежедневной рутины.
Отрицательная сторона пользовательских псевдонимов состоит в негибкости и умственной нагрузке. Это означает, что псевдонимы работают только в определенной среде (например, на вашем ноутбуке) и вам нужно запоминать их.
Я также рекомендую git auto complete или фреймворки вроде bash-it. Они обычно разработаны с некоторой логикой (в названиях команд) и их легче запоминать. Поищите bash helpers, встроенные в ваш язык, фреймворк, платформу.
Отсутствие необходимости набирать текущее имя ветки git экономит мне больше 1M символов ввода, а благодаря псевдонимам я избегаю многих возможных ошибок.
Даже если вы не используете псевдонимы, такие практики как использование HEAD вместо master уменьшат вероятность человеческих ошибок. Например, научитесь вводить git pull origin HEAD вместо git pull origin master.
Также вы можете использовать Bash даже на Windows. Я пользуюсь Git bash из Git for Windows.
Совет по Bash: научитесь пользоваться историей, особенно CTRL+R.
Настройте свои инструменты
Вы проводите много времени, работая с IDE, bash и другими инструментами. Кастомизируйте их в соответствии с вашими нуждами и предпочтениями. Если вам что-то сильно не нравится в ваших инструментах (например, отсутствие сочетаний клавиш или цветовая схема), поменяйте это сразу, прямо сейчас.
Мне, например, нравится, когда мой bash цветной и жизнерадостный, а все мои редакторы имеют черные темы.
Настройте вашу среду разработки
Сделайте так, чтобы ваше рабочее окружение работало на вас, а не против вас. Самый простой пример – добавление ваших IDE-файлов в ваш глобальный git-файл .gitignore. Вы сохраните время, сделав это лишь один раз на каждой машине, вместо того чтобы делать это для каждого проекта.
[code]#~/.gitignore
.idea/
.vs/[/code]
Понаблюдайте за собой. С какими системными настройками у вас возникали проблемы в прошлом, с какими правилами файервола? С версиями Python? Локальным кэшем Unity3D? Решите эти проблемы сразу.
Изучите ваши инструменты
Вы должны изучать созданные для вас инструменты точно так же, как изучаете новые техники разработки, новые фреймворки, парадигмы и шаблоны проектирования.
Текстовые редакторы годятся для редактирования текста, а профессиональным разработчикам нужны IDE. Почему? Потому что для нас имеет значение время, мы хотим поставлять как можно больше кода за единицу этого времени. IDE «тяжелее» текстового редактора, поскольку имеет больше встроенного функционала, созданного специально для разработчиков.
PS: текстовый редактор с десятками плагинов вроде интеграции компилятора/git/linter это уже IDE.
Совершенствуйте свои навыки, выходя из зоны комфорта.
Обновляйте свою IDE и изучайте новый функционал: скорее всего он вам пригодится. Периодически ищите новые IDE: они могут вас удивить.
Вы можете сделать большой скачок в продуктивности, чаще используя сочетания клавиш. Например, «расширенный выбор» сэкономил мне много времени на протяжении многих лет использования. В качестве примеров также можно привести живые шаблоны и мультикурсоры.
Я часто использую такой живой шаблон как отладка сообщений: if IsDebugBuild {print(«msg», var)}. Или try/catch выражения.
Вы можете использовать замену с помощью регулярных выражений, но порой мультикурсоры проще и эффективнее.
Хорошие сценарии использования мультикурсоров это захардкоженные данные, перечисляемые типы, шаблоны и прочие вещи, зачастую скучные.
Автоматизируйте вашу среду разработки
Когда я последний раз менял работу, у меня ушло несколько полных рабочих дней на настройку всего необходимого для большого проекта. Но так быть не должно. Для автоматизации подобных вещей созданы специальные инструменты. Boxstarter (сам я еще не пробовал) может по отрывку кода за минуты построить вашу среду разработки в Windows.
Для подобных задач я начал пользоваться Docker. Используя простые CLI-инструкции, вы можете установить большую часть необходимых вам инструментов/сервисов/программ. Нет нужды в компиляции, поиске пакетов или бинарных исходников.
Не будьте «человеком с молотком»
«Для человека с молотком все выглядит, как гвоздь».
Если вам нужен системный скрипт, не используйте для этого JavaScript. Изучите немного bash, задайте вопрос коллеге или на stack overflow. Если вам нужна маленькая браузерная анимация, обратитесь к CSS3. Это займет у вас несколько лишних минут, но в будущем очень пригодится.
Подобная проблема есть у большинства инженеров. Раньше я все делал на PHP. Выпускники вузов могут застопориться на Java. Это человеческая натура. Дизайнеры делают то же самое с Photoshop, а QA – с программами для отслеживания багов вроде Jira. Идея в том чтобы расширить свой набор инструментов, понемножку, по одному маленькому скрипту за раз.
* при сохранении
Автоматизируйте все, что только возможно в действии «сохранить файл». При этом я чаще всего активирую «auto-format on save» (автоформат при сохранении).
Автоформат позволяет мне писать быстрый и грязный код, не тратя время на отступы, запятые, точки с запятой и прочие красивости – это работа IDE.
Также автоформат устраняет многие человеческие ошибки. Например, помогает в ситуациях, когда вы забываете отформатировать свой код и в результате генерируете git-конфликты и дурацкие коммиты. В целом это позволит вам и вашим коллегам стать более продуктивными.
Задача IDE – помогать вам, так что дайте ей выполнять свою работу.
Вы можете создать собственный конвейер того, что нужно сделать при сохранении, в зависимости от ваших нужд: компиляцию, проверку на ошибки, модульные тесты и т. д. Для более затратных по времени скриптов я использую запускаемые вручную задачи (Tasks).
Например, в Go я активирую «запустить тесты и покрытие при сохранении». Постоянно открытая консоль повышает мою эффективность. Я могу работать быстрее и не бояться рефакторинга, поскольку в каждую отдельную минуту знаю, в порядке мой код или нет.
TODO
Используйте в вашем коде побольше //TODO’s. Не нужно нарушать свой текущий рабочий процесс, не нужно выходить из «зоны» для решения смежных задач. Сделайте небольшую пометку и вернитесь к этому месту позже, имея лучшую, более широкую перспективу.
Отрывки кода (сниппеты)
Не храните сниппеты в чате, как делали некоторые из моих друзей. Вы можете использовать Gists или другие подобные сервисы. Например, ваш собственный репозиторий или документ в google drive. Идея в том чтобы сохранить отрывки кода, которые было трудно найти/создать, но при этом очень полезные. В будущем это сэкономит вам время.
Делитесь знаниями
Мы можем экстраполировать предыдущие решения на другие вещи. Если у вашего коллеги возникла проблема и вы собираетесь ему помочь, учтите, что с большой вероятностью в будущем найдутся и другие коллеги, которым пригодится ваш ответ. Используйте для публикации ответов каналы связи, которыми смогут воспользоваться другие люди.
Имейте минимальную документацию проекта, пишите статьи/истории, даже если они будут предназначены лишь для внутреннего использования. Ведите записи митапов. Идея в том чтобы выкладывать решение проблем не в электронной переписке и не в приватных чатах, а делиться знаниями с людьми так, чтобы они могли иметь к ним доступ.
Это сэкономит вам время, потому что вам не придется объяснять/решать проблему дважды.
Автоматизируйте ваши вызовы API
Если вы работаете с какими-либо API, я рекомендую пользоваться инструментом вроде Postman. Если вы храните ваши вызовы в одном месте, вы можете даже автоматизировать их (в конвейере непрерывной доставки) и делиться ими с коллегами (как конфигами). Я, например, хранил тесты в том же репозитории, что и исходный код API сервера.
Надеюсь, статья была вам полезна. Желаю приятной и продуктивной работы!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]