Программировать быстро — это легко! Так считает инженер-программист компании Google, который все публикации в своем блоге подписывает лаконичным «Макс». Макс также работает главным архитектором, комьюнити-менеджером и релиз-менеджером в Bugzilla Project. Мы в Alconost впечатлились и перевели его советы о том, можно ли как научиться программировать с космической скоростью.
Если обсуждать с разработчиками сложность кода, они часто говорят, что хотят писать простой код, но из-за давления дедлайнов и более глубинных причин у них не хватает времени или знаний для того, чтобы выполнить задачу и оптимизировать решение до максимальной простоты.
Они, конечно, правы в том, что в условиях сжатых сроков разработчики, как правило, будут писать сложный код. Впрочем, дедлайны не должны приводить к сложности. Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто». То есть чем быстрее вы как программист — тем меньше влияния на качество вашего кода имеют дедлайны.
Теперь давайте разберемся, как, собственно, стать быстрее? Может, это врожденное магическое умение? Надо ли быть «умнее» других, чтобы быть быстрым?
Нет, это вообще не магия и не врожденный дар. На самом деле существует всего одно простое правило, считаясь с которым, со временем вы полностью решите проблему:
Всякий раз, когда замечаете, что топчетесь на месте в размышлениях, знайте: что-то пошло не так.
Это может звучать невероятно, но работает исключительно хорошо. Задумайтесь: когда вы сидите перед вашим редактором, но работа идет небыстро, потому ли это, что у вас низкая скорость набора? Я сомневаюсь: «слишком много набирать» — редкая проблема программистской производительности. Паузы, когда вы не набираете, — вот что все замедляет. А чем обычно заняты в таких паузах разработчики? Пытаются перестать думать — может быть, о проблеме, об инструментах, о сообщении в почте, да о чем угодно. Но всякий раз, когда такое случается, оно означает проблему. Размышления сами по себе — не проблема, но признак какой-то другой проблемы. Вероятно, вместо того, чтобы ходить по кругу в своих мыслях, вам стоит обратить внимание на что-то из этого:
Понимание
Самая распространенная причина непродуктивных размышлений разработчика — неполное понимание какого-то слова или символа.
Это произошло со мной буквально на днях. У меня ушли часы на написание того, что должно было стать действительно простым сервисом. Я очень старался прекратить думать об этом, пытаясь разобраться, как все должно работать. В итоге я осознал, что не понимал одну из входных переменных в основной функции. Я знал название ее типа, но так никогда и не поинтересовался его определением — то есть на самом деле не понимал, что эта переменная (слово или символ) означала. Как только просмотрел код и документацию по этому типу — пришло понимание, и я написал этот сервис как демон (каламбур отчасти неслучаен).
Таких вариантов — бесчисленное множество. Многие пользуются языком программирования, не разбираясь, что (, ), [, ], {, }, +, * и % означают в этом языке. Некоторые разработчики не понимают, как на самом деле работает компьютер. Помните мой «Единственный секрет программиста-рок-звезды»? Вот где суть! Ведь если ты по-настоящему понимаешь, тебе не надо прекращать ненужные размышления. Это также побудило меня написать книгу: понимание того, что есть незыблемые законы создания программного обеспечения, может избавить от многих эпизодов «борьбы с размышлениями».
Так что, если вы оказались в мыслительном тупике, не пытайтесь решить проблему в своей голове — ищите то, чего не понимаете, вне себя. После чего возьмите и посмотрите на что-то, что поможет вашему пониманию. Это применимо даже к вопросам вроде «Прочтет ли когда-нибудь пользователь этот текст?» У вас может не быть Департамента исследований пользовательского опыта для настоящего ответа на этот вопрос, но вы можете хотя бы нарисовать что-нибудь, показать другим, выслушать их мнение. Не пытайтесь просто сидеть и думать — сделайте что-то. Только действие ведет к пониманию.
Рисование
Бывает, мысль разработчика останавливается потому, что ему не удается одновременно удерживать в голове все находящиеся в работе идеи — множество связанных между собой сложным образом вещей, нуждающихся в осмыслении. В этом случае почти всегда эффективнее записать или зарисовать что-либо, чем думать об этом. Вам нужно каким угодно образом посмотреть на это со стороны, воспринять вне своей головы. Это один из вариантов понимания, но достаточно важный, чтобы вынести его отдельным пунктом.
Начинание
Иногда проблема в том, что «нет представления, какой код нужно начинать писать». Простейшее решение — начать писать любой известный вам код, который вы можете писать прямо сейчас. Выберите часть проблемы, которую вы полностью понимаете, и пишите для нее решение, даже если это всего одна функция или не самый важный класс.
Часто фрагмент кода, с которого проще всего начать, — это «ядро» приложения. Например, если бы я взялся писать приложение YouTube, я бы начал с видеоплеера. Воспринимайте это как упражнение по непрерывной поставке: пишите код, который действительно сначала создает продукт — неважно, каким дурацким или незначительным он может получаться. Видеоплеер без пользовательского интерфейса — уже продукт, выполняющий полезную задачу (воспроизведение видео), даже если еще не полноценен.
Если вы не уверены в том, как писать даже такой базовый код, просто начните с кода, в котором вы уверены. Обычно, как только решается часть проблемы, становится значительно легче решать проблему целиком. Иногда проблема раскрывается поэтапно: вы решаете одну часть, которая делает очевидным решение следующей части, и так далее. Начните с любой части, создание которой не требует длительного обдумывания, и просто напишите ее.
Пропуск шагов
Еще одна специфическая проблема понимания — пропуск какого-то шага в правильной последовательности разработки. Например, наш объект Велосипед зависит от объектов Колеса, Педали и Рама. Если вы попытаетесь написать весь объект Велосипед без написания объектов Колеса, Педали и Рама, вам придется много обдумывать эти несуществующие классы. С другой стороны, если вы напишете класс Колеса, пока вообще не существует класс Велосипед, вам предстоит много размышлений о том, как класс Колеса будет использоваться классом Велосипед.
Правильное решение тут — реализовать достаточную часть класса Велосипед, чтобы дойти до шага, где вам понадобятся Колеса. Потом написать достаточную часть класса Колеса, чтобы удовлетворить актуальную потребность в классе Велосипед. После чего вернуться к классу Велосипед и работать над ним до следующей нужды в каком-то из основных элементов. Так же, как и в пункте «Начинание»: найдите часть проблемы, которую можете решить без размышлений, и решите ее сразу.
Не перепрыгивайте шаги при разработке своей системы — и это позволит вам быть продуктивным.
Физические проблемы
Если я недостаточно ем, я начинаю отвлекаться и задумываться, потому что я голоден. Вовсе необязательно это будут мысли о моем желудке, но они бы вообще не возникли, если бы я был сыт, — я был бы сосредоточен. То же справедливо для сна, болезней и любых других телесных проблем. Они не настолько распространены, как перечисленные выше, так что первым делом всегда ищите, что вы недостаточно хорошо поняли. Но если вы уверены, что понимаете все, причиной остановки мысли могут быть проблемы на физическом уровне.
Отвлекающие факторы
Когда разработчик отвлекается на что-то внешнее, например, шум, ему может понадобиться некоторое время подумать, чтобы вспомнить, над чем он работал в своем решении. Ответ тут относительно прост: перед тем, как садитесь за разработку, убедитесь в том, что ваше окружение не побеспокоит вас или отвлекающие факторы не будут вас прерывать. Одним нужно закрыть дверь в свой офис, другим — надеть наушники, кому-то — поставить статус «Не беспокоить»: сделайте так, как вам нужно. Возможно, вам понадобится помощь вашего менеджера или сотрудников, чтобы создать действительно благоприятную для разработки среду.
Неуверенность в себе
Иногда разработчик сидит и размышляет потому, что ощущает неуверенность в себе и своих решениях. Выход тут аналогичен описанному в пункте «Понимание»: если вы не уверены в чем-то, узнавайте об этом больше до тех пор, пока не появится уверенность, достаточная, чтобы писать код. Если вы не уверены в себе как в программисте вообще, возможно, вам нужно изучить еще многое — вроде основ, изложенных в «Почему программисты отстой». Разбирайтесь с каждым вопросом, пока не добьетесь настоящего понимания, после чего переходите к следующему, и так далее. Программирование всегда подразумевает обучение в процессе, но по мере увеличения багажа знаний вы будете становиться все быстрее и быстрее, а задумываться придется все меньше и меньше.
Ложные представления
Многим говорили, что думать — удел умных людей, и они не задумываются, чтобы принимать разумные решения. Но это неправда. Если бы размышления сами по себе могли сделать вас гением, вокруг были бы одни Эйнштейны. По-настоящему умные люди учатся, наблюдают, принимают решения и действуют. Они приобретают знания и потом используют их для решения возникающих проблем. Если хотите быть действительно умным, используйте свой интеллект для деятельности в физическом мире — не замыкайтесь с ним для великих дум в своей голове.
Бездействие
Все перечисленное выше — ключ к тому, как быть быстрым программистом, когда вы сидите и пишете код. Если же вы весь день читаете почту и ходите по встречам, а программировать вам некогда — это другая проблема. Некоторые ее аспекты схожи (это как если бы организации пришлось «не задумываться»), но это не то же самое.
Впрочем, можно попробовать и несколько подходов по аналогии. Есть вероятность, что организация не вполне понимает вас или вашу роль и потому шлет вам столько писем и зовет на столько встреч. Возможно, вы чего-то не понимаете об организации, например, как посещать меньше собраний и получать меньше почты :) Может быть, вам удастся разрешить некоторые организационные сложности, адаптируя решения из этого поста к коллективам вместо отдельных людей.
Как вам такой подход?
О переводчике
Перевод статьи выполнен в Alconost. Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Подробнее: alconost.com
Автор: Alconost
