IT Notes

Пять способов повышения продуктивности для программиста

Введение

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

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

Итак, приступим.

Способ 1. Освоение среды разработки в совершенстве

Вы ведете разработку в мощной IDE, типа Visual Studio или Eclipse? - Прекрасно, но может быть что-то получается не так, как вам хотелось бы? Или вам для работы хватает простого блокнота? - Если так, то советую вам задуматься о переходе на что-то посерьезнее.

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

  1. Подсветка синтаксиса. Ее использование поможет многократно сократить количество опечаток и незакрытых скобок;
  2. Автозавершение. Чем меньше нужно печатать - тем лучше. Еще лучше, если эта функция будет работать с учетом синтаксиса языка, например, выдавая варианты методов класса с предложением подстановки аргументов;
  3. Макросы (см. Принцип DRY в действии). Макросы позволяют сохранить некую последовательность действий в редакторе и повторять их многократно по необходимости;
  4. Быстрые клавиши. В идеале для любого действия должна быть предусмотрена комбинация клавиш. Старайтесь не использовать мышь вообще. Конечно, ожидается, что вы уже уверенно владеете методом слепой печати. Если это не так, то срочно скачивайте тренажер и учитесь. Для программиста это просто жизненно необходимый навык. Причем, речь в этой ситуации идет не просто о разнице между печатью быстрее и медленнее. Это различие в правильном и неправильном использовании одного из самых главных ваших инструментов - клавиатуры. Вы же не забиваете гвозди отверткой? Вот и клавиатурой нужно пользоваться правильно;
  5. Поиск и замена по регулярному выражению. Думаю, что этот пункт не требует комментариев;
  6. Функции рефакторинга. Как минимум должна быть возможность быстро переименовать переменную, метод или класс. Но и другие возможности никогда не будут лишними. Главное - пользоваться ими, если они есть.

Конечно, это не полный список, но даже выполнение лишь этих условий существенно увеличит вашу продуктивность. Обычно в этом случае в качестве редактора предлагают использовать либо Emacs, либо Vim. Сейчас мы не будем говорить об особенностях этих редакторов, но когда-нибудь мы еще к этому вернемся. Лично я частично остановился на последнем варианте, то есть на Vim. Но что значит частично? Следует учитывать, что Vim - это не полноценная IDE. В этом есть свои плюсы и минусы. И хоть существует огромное количество расширений для него, которые могут решить большинство сложностей, мне все же приятнее работать с полноценной IDE. Поэтому я нашел для себя простой выход. Практически в любой более или менее серьезной интегрированной среде разработки есть возможность использовать режим редактирования в стиле Vim. Где-то она уже встроена, например FakeVim в Qt Creator, а где-то может быть установлена в виде плагина, например vrapper в Eclipse и VsVim в Visual Studio. Однако по опыту работы скажу, что лучше, когда поддержка режима Vim встроена в IDE, поскольку установка плагинов может принести множество побочных проблем: возможные пересечения комбинаций клавиш, нестабильная работа с другими плагинами и т.д.

Способ 2. Эффективное управление файлами

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

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

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

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

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

Способ 3. Больше мониторов

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

О моем опыте работы с несколькими мониторами и о том, почему я к этому пришел, вы можете прочитать в заметке Почему я пользуюсь Openbox?. Лично для себя я решил остановиться на двух мониторах. Все же это самый простой с аппаратной точки зрения вариант. Кроме того, если бы их было больше, то ими было бы труднее управлять, да и у меня на столе уже попросту не хватит места на еще один монитор. Но тут еще зависит от размера мониторов. Есть системы с 4 или 6 относительно небольшими экранами, которые крепятся на кронштейне. Только я предпочитаю не мельчить, поэтому и выбрал два 27-дюймовых монитора, на которых все хорошо видно, а работать приходится в основном с текстом.

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

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

И в качестве бонуса фотография моего основного рабочего места:

my_desktop

Способ 4. Автоматизация

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

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

Конечно же, не забывайте про возможность генерации кода с помощью утилит. Например, во многих случаях формы UI-интерфейсов удобнее компоновать с помощью специальных инструментов в стиле WYSIWYG. Они позволяют создавать весьма сложные интерфейсы без единой строки кода за считанные минуты. Однако есть мнение, что такие генераторы нужно использовать лишь для создания прототипов или в работе дизайнеров. А окончательную версию уже реализовывать вручную. Нельзя сказать, что какой-то из методов намного лучше другого. Всегда найдутся преимущества и недостатки, ведь все зависит от ситуации, поэтому окончательный выбор остается за вами.

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

Способ 5. Не изобретайте велосипед

Как и обещал, мы возвращаемся к вопросу использования чужих наработок при решении собственных задач. Идея и выгоды достаточно прозрачны, но у многих стоит настоящий психологический барьер по этому поводу. У меня у самого такое было, да и сейчас не на 100% прошло. Ведь всегда хочется сделать свой независимый проект, который будет лучше других.

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

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

Если же речь идет о сторонней утилите, то все еще проще. Вы же работает в операционной системе, пользуетесь браузером и средой разработки. Так что мешает воспользоваться чужим скриптом или простенькой утилитой?

Однако помехи и правда вполне возможны. А связаны они могут быть с тем, что чужая библиотека или утилита делает ПОЧТИ то, что нужно, но не совсем то.

Если вы имеете доступ к исходным кодам, то все несколько проще. Вы всегда можете подправить реализацию так, как нужно. Но лично я считаю это крайней мерой. Сначала внимательно прочитайте доступную документацию. Вполне возможно, что то, что вы ищите, уже предусмотрено. Однако вынужден признать, что часто для Opensource-проектов документации не так много или вовсе практически нет. Но здесь уже все зависит от удачи и вашей настойчивости. Если же вам не повезло, то попробуйте поискать другое решение. Обычно всегда есть хотя бы несколько альтернатив, если ваша задача не сверх-специфичная.

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

Заключение

Вот мы и рассмотрели пять способов, которые позволят повысить вашу продуктивность. Старайтесь их соблюдать:

  1. Освойте среду разработки в совершенстве;
  2. Эффективно управляйте файлами;
  3. Используйте больше мониторов;
  4. Автоматизируйте все, что можете;
  5. Не изобретайте велосипед.

В идеале вам следует использовать все 5 из этих способов, но даже если вы воспользуетесь лишь несколькими из них, то уже заметите, что стали работать продуктивнее.

Похожие публикации

Комментарии

спасибо

Anonymous:

спасибо

Пожалуйста. Рад, что этот материал оказался для Вас полезен.