«Человек может стать человеком только путем воспитания. Он — то, что делает из него воспитание»
И. Кант

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

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

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

1. Не повторяйся (DRY – Don’t repeat yourself)

Вы наверняка сталкивались с тем, что, просматривая очередной участок кода, думаете: «Хм, вот тут я уже делал что-то подобное, но с другими аргументами, и вообще был другой массив данных».

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

Поэтому выработайте в себе хорошую привычку следовать принципу DRY («Не повторяйся»). Всегда, когда ловите себя на написании похожего алгоритма, потратьте время, продумайте несколько возможных вариантов с разными сущностями. Организуйте небольшую типовую функцию или даже класс, если алгоритм сложный. Это займет чуть больше времени, чем написание быстрого решения для конкретной задачи, но сэкономит в будущем невероятное количество часов на отладке и тестировании.

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

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

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

2. Как только решили, что все сделано, проведите рефакторинг

Большинство программистов, особенно новички, полагают, что их работа сделана, как только код начинает выполнять задачу так, как задумано. Только вот слово «сделана» включает в себя более обширное понятие, чем тривиальное написание кода.

Код работает правильно? Да! Так в чем же дело?

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

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

Очень рекомендую прочитать по этой теме «Чистый код» Роберта Мартина. Просветляющая книга, которая должна быть в библиотеке каждого программиста.

3. Сфокусируйтесь на бизнес-задачах

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

Если очень грубо представить программиста, который работает чисто по ТЗ без понимания сути, то можно привести пример. Водитель автобуса, рядом с которым сидят пассажиры и говорят ему: «Поверни налево, поверни направо, теперь прямо». И вот так пассажиры «ведут» автобус. Но если водитель проявит инициативу и спросит: «Куда нужно ехать?», тогда пассажир может просто сказать: «Едем в город N», и все становится намного проще. Водитель знает конечную точку назначения и может, используя свой опыт, самостоятельно строить маршрут и сам себе говорить, где и как нужно поворачивать.

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

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

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

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

Для лучшего понимания советую прочитать книгу «Начни с Почему» Саймона Синека.

4. Небольшие коммиты

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

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

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

В качестве литературы очень рекомендую прочитать хотя бы первую главу из книги «Git для профессионального программиста» Скотта Чакона и Штрауба Бена. Когда узнаешь, какие чудесные есть функции в Git и на что он способен, тогда остается только коммитить почаще, а остальное все можно уладить нужными инструментами.

5. Считайте время

Любая работа имеет начало и конец. Эффективность программиста измеряется в количестве часов, необходимых ему для решения определенных задач. Чем быстрее решаются задачи, тем лучше. Это вполне очевидно и не требует каких-то объяснений.

Но есть у этой очевидности другая сторона, которая часто ускользает от программистов, – нужно точно считать время, затраченное на решение. Не то, что вы ощущаете, когда сидите на работе с девяти до пяти вперемежку с котиками и совещаниями. А настоящее время вашей работы.
В самом начале я вырабатывал привычку считать время, просто записывая отчеты о том, что делал в течение дня, и прикидывая примерное время. Уже тогда я примерно вычислил, что эффективной работы у меня выходит только 4 часа из 8.

А затем установил специальные программы, которые считали время автоматически. Сначала я использовал www.rescuetime.com. Благодаря этой программе я увидел, что социальные сети хоть и казались мне незначительной тратой, на самом деле сильно портили мне картину производительности. В итоге я решил отключить доступ к некоторым сайта полностью в рабочее время. Для этого тоже есть специальные плагины в браузере.

Следующий шаг по учету времени потребовался, когда я решил фиксировать точное время работы именно с программным кодом. Для этого я сначала пробовал hubstaff.com. Как оказалось, довольно дорогое решение, если использовать его при работе в команде.

Затем испробовал wakatime.com. И это оказалась та самая серебряная пуля. У этого сервиса есть возможность внедрения во все популярные IDE, а также интеграция с github. В результате можно с точностью до минуты определить, сколько вы провели полезных минут, программируя. К тому же идет привязка к коммитам. Это просто замечательно, когда вы можете увидеть не только сами коммиты, но и узнать время, которое потратили на этот коммит.
Потрясающий сборник рецептов по правильной организации времени и работе над проектами есть в книге «Джедайские техники» Максима Дорофеева.

6. Стабильность – признак мастерства

Как вы уже наверняка поняли – можно бесконечно развивать свои навыки и способности. То, что вы делали год назад, вам может показаться смешным и неказистым с точки зрения вашего нового опыта. У вас, естественно, будут совершенствоваться способы написания сложных выражений.
Но среди всего этого вы должны выработать привычку придерживаться определенных правил. Даже если они вам кажутся не совсем отработанными, используйте эти способы работы повсеместно.

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

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

Так что же нужно делать, чтобы соблюдать принцип постоянства?

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

Также изучите литературу по способам наименования классов, методов и переменных. Рекомендую книгу «Совершенный код» Стива Макконелла.

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

7. Делай один раз

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

Хороший вариант понимания того, что вы действительно закончили этот участок кода, – это создание теста для проверки нескольких входящих условий.

8. Никогда не прекращать учиться

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

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

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

Только лишь когда поток клиентов уменьшился, я понял, что мой продукт нуждается в модернизации. И тут я столкнулся с огромным барьером. Раньше я использовать только PHP и очень редко AJAX-функции. А для понимания современных JS-фреймворков React, Angular, Vue мне потребовалось в срочном порядке потратить примерно год времени, чтобы по книгам изучить их. Самое интересное, что если бы я до этого уделял обучению достаточное времени, то мой продукт не терял бы конкурентоспособности. Просто вместо поддержки старых функций нужно было изучить новые и внедрять технологии постепенно, а не в таком авральном режиме.

Заключение

Даже если вы уверены на все сто в своих навыках, помните, что совершенству нет предела. Не переставайте задавать себе провокационные вопросы. Признавайтесь себе в том, что в некоторых областях у вас недостаточная подготовка или вы не знаете тонких моментов в знакомых вам фреймворках, но вам хотелось бы их узнать. Потратить пару часов и запустить на локальном сервере тестовый вариант прямо с github теперь очень легко.

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