​11 нестандартных советов для развития навыков программирования

Хотел бы поблагодарить EvilCat за перевод статьи.

Оригинал статьи.

Сама, собственно, статья.

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

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

1. Здоровая еда и сон

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

Любой, твёрдо решивший добиться успеха в разработке (да и в любой профессии), должен так же серьёзно отнестись к образу жизни. Как замечает сэр Кен Робинсон, люди часто "живут в своей голове" и склонны пренебрегать собственным телом. Программисты, в частности, обычно не понимают, насколько тонус влияет на их успехи на программном фронте. Программирование требует собранности и бодрости. Совершенно очевидно, что недосып и плохое питание подкашивают способность программировать.

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

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

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

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

2. Периодически отдыхайте, чтобы поддерживать продуктивность

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

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

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

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

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

3. Научитесь быстро возвращаться в рабочий настрой

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

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

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

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

4. Не работайте больше восьми часов в день

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

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

5. Обдумывайте проблемы

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

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

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

6. Пишите хорошую документацию

Да, да, все мы знаем, как важно документировать код. Однако обычно у программистов смешанные чувства о написании документации, поскольку мы не любим тратить время на лишние задачи. Это убеждение происходит от неверного понимания сути документации. Я считаю документацию прежде всего инструментом /взаимопонимания/ - то есть, когда я пишу комментарий, то ставлю своей целью сделать код понятным для читателя (будь то товарищ, будущий сотрудник или я сам). Когда люди не хотят писать документацию, они обычно либо считают код очевидным; либо думают, что коллектив и так понимает код; либо что никогда не забудут суть кода.

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

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

7. Выработайте привычку делать записки и фиксировать идеи

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

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

Хороший программист знает пределы собственной памяти, которые со временем только уменьшатся. Самое худшее, когда забываешь идею - в том, что это происходит незаметно, так что удержание идеи связано с определённым стрессом. Джесс Шелл так написал об этом в "Искусстве геймдизайна":

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

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

8. Знайте, когда срезать путь

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

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

9. Знайте, когда подчищать код

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

"Чистый" код - это совокупность нескольких качеств: хорошая документация, аккуратное форматирование, отсутствие закомментированных блоков (вы всё равно ими не воспользуетесь) и логичное расположение. В объектно-ориентированном программировании назначения классов часто размываются по мере добавления фишек, и может потребоваться некоторая неорганизация, чтобы распределить назначение по нескольким соответствующим классам. Комментарии тоже имеют склонность устаревать, и периодически их следует обновлять.

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

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

10. Отточите до блеска искусство отладки

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

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

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

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

11. Научитесь предсказывать дефекты до их проявления

Когда я разрабатываю что-либо, я стараюсь мысленно составить список возможных неполадок и как каждый предполагаемый дефект /выглядел бы/. Например, когда мне не хочется проверять действительность входных значений функции, то я хотя бы пытаюсь представить, что произойдёт в случае недействительных параметров (например, если я программирую платформер, то, может, персонаж начнёт бежать задом?). Если однажды появляется дефект, соответствующий моему предположению, то я ещё до разбора кода знаю, где искать причину.

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

___________________________________

На этом все.

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

Не забываем заглядывать и подписываться на наш паблик в ВК и ФБ. Во ВКонтакте у нас появился чат сообщества.

На этом все. Делитесь, комментируйте, сохраняйте в закладках.

Всем добра и успешных стартов.