Программировать быстро — это легко! Так считает инженер-программист компании Google, который все публикации в своем блоге подписывает лаконичным «Макс». Макс также работает главным архитектором, комьюнити-менеджером и релиз-менеджером в Bugzilla Project. Мы в Alconost впечатлились и перевели его советы о том,
Если обсуждать с разработчиками сложность кода, они часто говорят, что хотят писать простой код, но из-за давления дедлайнов и более глубинных причин у них не хватает времени или знаний для того, чтобы выполнить задачу и оптимизировать решение до максимальной простоты.
Они, конечно, правы в том, что в условиях сжатых сроков разработчики, как правило, будут писать сложный код. Впрочем, дедлайны не должны приводить к сложности. Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто». То есть чем быстрее вы как программист — тем меньше влияния на качество вашего кода имеют дедлайны.
Теперь давайте разберемся, как, собственно, стать быстрее? Может, это врожденное магическое умение? Надо ли быть «умнее» других, чтобы быть быстрым?
Нет, это вообще не магия и не врожденный дар. На самом деле существует всего одно простое правило, считаясь с которым, со временем вы полностью решите проблему:
Всякий раз, когда замечаете, что топчетесь на месте в размышлениях, знайте: что-то пошло не так.
Это может звучать невероятно, но работает исключительно хорошо. Задумайтесь: когда вы сидите перед вашим редактором, но работа идет небыстро, потому ли это, что у вас низкая скорость набора? Я сомневаюсь: «слишком много набирать» — редкая проблема программистской производительности. Паузы, когда вы не набираете, — вот что все замедляет. А чем обычно заняты в таких паузах разработчики? Пытаются перестать думать — может быть, о проблеме, об инструментах, о сообщении в почте, да о чем угодно. Но всякий раз, когда такое случается, оно означает проблему. Размышления сами по себе — не проблема, но признак какой-то другой проблемы. Вероятно, вместо того, чтобы ходить по кругу в своих мыслях, вам стоит обратить внимание на что-то из этого:
Понимание
Самая распространенная причина непродуктивных размышлений разработчика — неполное понимание какого-то слова или символа.
Это произошло со мной буквально на днях. У меня ушли часы на написание того, что должно было стать действительно простым сервисом. Я очень старался прекратить думать об этом, пытаясь разобраться, как все должно работать. В итоге я осознал, что не понимал одну из входных переменных в основной функции. Я знал название ее типа, но так никогда и не поинтересовался его определением — то есть на самом деле не понимал, что эта переменная (слово или символ) означала. Как только просмотрел код и документацию по этому типу — пришло понимание, и я написал этот сервис как демон (каламбур отчасти неслучаен).
Таких вариантов — бесчисленное множество. Многие пользуются языком программирования, не разбираясь, что (, ), [, ], {, }, +, * и % означают в этом языке. Некоторые разработчики не понимают, как на самом деле работает компьютер. Помните мой «Единственный секрет программиста-рок-звезды»? Вот где суть! Ведь если ты по-настоящему понимаешь, тебе не надо прекращать ненужные размышления. Это также побудило меня написать книгу: понимание того, что есть незыблемые законы создания программного обеспечения, может избавить от многих эпизодов «борьбы с размышлениями».
Так что, если вы оказались в мыслительном тупике, не пытайтесь решить проблему в своей голове — ищите то, чего не понимаете, вне себя. После чего возьмите и посмотрите на что-то, что поможет вашему пониманию. Это применимо даже к вопросам вроде «Прочтет ли когда-нибудь пользователь этот текст?» У вас может не быть Департамента исследований пользовательского опыта для настоящего ответа на этот вопрос, но вы можете хотя бы нарисовать что-нибудь, показать другим, выслушать их мнение. Не пытайтесь просто сидеть и думать — сделайте что-то. Только действие ведет к пониманию.
Рисование
Бывает, мысль разработчика останавливается потому, что ему не удается одновременно удерживать в голове все находящиеся в работе идеи — множество связанных между собой сложным образом вещей, нуждающихся в осмыслении. В этом случае почти всегда эффективнее записать или зарисовать что-либо, чем думать об этом. Вам нужно каким угодно образом посмотреть на это со стороны, воспринять вне своей головы. Это один из вариантов понимания, но достаточно важный, чтобы вынести его отдельным пунктом.
Начинание
Иногда проблема в том, что «нет представления, какой код нужно начинать писать». Простейшее решение — начать писать любой известный вам код, который вы можете писать прямо сейчас. Выберите часть проблемы, которую вы полностью понимаете, и пишите для нее решение, даже если это всего одна функция или не самый важный класс.
Часто фрагмент кода, с которого проще всего начать, — это «ядро» приложения. Например, если бы я взялся писать приложение YouTube, я бы начал с видеоплеера. Воспринимайте это как упражнение по непрерывной поставке: пишите код, который действительно сначала создает продукт — неважно, каким дурацким или незначительным он может получаться. Видеоплеер без пользовательского интерфейса — уже продукт, выполняющий полезную задачу (воспроизведение видео), даже если еще не полноценен.
Если вы не уверены в том, как писать даже такой базовый код, просто начните с кода, в котором вы уверены. Обычно, как только решается часть проблемы, становится значительно легче решать проблему целиком. Иногда проблема раскрывается поэтапно: вы решаете одну часть, которая делает очевидным решение следующей части, и так далее. Начните с любой части, создание которой не требует длительного обдумывания, и просто напишите ее.
Пропуск шагов
Еще одна специфическая проблема понимания — пропуск какого-то шага в правильной последовательности разработки. Например, наш объект Велосипед зависит от объектов Колеса, Педали и Рама. Если вы попытаетесь написать весь объект Велосипед без написания объектов Колеса, Педали и Рама, вам придется много обдумывать эти несуществующие классы. С другой стороны, если вы напишете класс Колеса, пока вообще не существует класс Велосипед, вам предстоит много размышлений о том, как класс Колеса будет использоваться классом Велосипед.
Правильное решение тут — реализовать достаточную часть класса Велосипед, чтобы дойти до шага, где вам понадобятся Колеса. Потом написать достаточную часть класса Колеса, чтобы удовлетворить актуальную потребность в классе Велосипед. После чего вернуться к классу Велосипед и работать над ним до следующей нужды в каком-то из основных элементов. Так же, как и в пункте «Начинание»: найдите часть проблемы, которую можете решить без размышлений, и решите ее сразу.
Не перепрыгивайте шаги при разработке своей системы — и это позволит вам быть продуктивным.
Физические проблемы
Если я недостаточно ем, я начинаю отвлекаться и задумываться, потому что я голоден. Вовсе необязательно это будут мысли о моем желудке, но они бы вообще не возникли, если бы я был сыт, — я был бы сосредоточен. То же справедливо для сна, болезней и любых других телесных проблем. Они не настолько распространены, как перечисленные выше, так что первым делом всегда ищите, что вы недостаточно хорошо поняли. Но если вы уверены, что понимаете все, причиной остановки мысли могут быть проблемы на физическом уровне.
Отвлекающие факторы
Когда разработчик отвлекается на что-то внешнее, например, шум, ему может понадобиться некоторое время подумать, чтобы вспомнить, над чем он работал в своем решении. Ответ тут относительно прост: перед тем, как садитесь за разработку, убедитесь в том, что ваше окружение не побеспокоит вас или отвлекающие факторы не будут вас прерывать. Одним нужно закрыть дверь в свой офис, другим — надеть наушники, кому-то — поставить статус «Не беспокоить»: сделайте так, как вам нужно. Возможно, вам понадобится помощь вашего менеджера или сотрудников, чтобы создать действительно благоприятную для разработки среду.
Неуверенность в себе
Иногда разработчик сидит и размышляет потому, что ощущает неуверенность в себе и своих решениях. Выход тут аналогичен описанному в пункте «Понимание»: если вы не уверены в чем-то, узнавайте об этом больше до тех пор, пока не появится уверенность, достаточная, чтобы писать код. Если вы не уверены в себе как в программисте вообще, возможно, вам нужно изучить еще многое — вроде основ, изложенных в «Почему программисты отстой». Разбирайтесь с каждым вопросом, пока не добьетесь настоящего понимания, после чего переходите к следующему, и так далее. Программирование всегда подразумевает обучение в процессе, но по мере увеличения багажа знаний вы будете становиться все быстрее и быстрее, а задумываться придется все меньше и меньше.
Ложные представления
Многим говорили, что думать — удел умных людей, и они не задумываются, чтобы принимать разумные решения. Но это неправда. Если бы размышления сами по себе могли сделать вас гением, вокруг были бы одни Эйнштейны. По-настоящему умные люди учатся, наблюдают, принимают решения и действуют. Они приобретают знания и потом используют их для решения возникающих проблем. Если хотите быть действительно умным, используйте свой интеллект для деятельности в физическом мире — не замыкайтесь с ним для великих дум в своей голове.
Бездействие
Все перечисленное выше — ключ к тому, как быть быстрым программистом, когда вы сидите и пишете код. Если же вы весь день читаете почту и ходите по встречам, а программировать вам некогда — это другая проблема. Некоторые ее аспекты схожи (это как если бы организации пришлось «не задумываться»), но это не то же самое.
Впрочем, можно попробовать и несколько подходов по аналогии. Есть вероятность, что организация не вполне понимает вас или вашу роль и потому шлет вам столько писем и зовет на столько встреч. Возможно, вы чего-то не понимаете об организации, например, как посещать меньше собраний и получать меньше почты :) Может быть, вам удастся разрешить некоторые организационные сложности, адаптируя решения из этого поста к коллективам вместо отдельных людей.
Как вам такой подход?
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Подробнее: alconost.com
Комментарии (47)
beavis88
16.02.2017 12:27+2Точно, я если хочу есть, то кодить вообще не могу.
MaximChistov
16.02.2017 12:39потому что кровь от мозга уходит к желудку)
Free_ze
16.02.2017 17:05+3Это было бы не особо логично, ей там быть незачем. А вот у сытого человека как раз…
nckma
16.02.2017 12:37+5Как насчет писать код в программе, которую вообще мало понимаешь?
Если смотришь на программу и она кажется абсурдом, нагромождением хаоса, спагетти?
А нужно развить или дополнить ее функционал.
fogone
16.02.2017 12:48+4вставьте в любое место `println` или брекпоинт и посмотрите в какой момент туда попадет код. Посмотрите, что происходит в этом месте. Делайте так до тех пока не станет понятно хоть что-то.
nckma
16.02.2017 13:04+3Так и делаю. Но есть большая разница между понятно «хоть что-то» и «все понятно».
Когда понятно все, то можно сделать красивое решение. Когда понятно что-то, то можно сделать решение, но скорее всего будет костыль.fogone
16.02.2017 13:07+27если для проекта в котором ничего не понятно вы делаете костыль, то вероятно вы используете бестпрактис этого проекта, а как результат не будете выделяться на общем фоне и нарушать хрупкий баланс и эстетику остального кода
un1t
16.02.2017 17:01+3к сожалению бывает, когда разработчики меняются, то в хорошо написанном проекте с тестами и прочим, новые люди даже не пытаются разобраться и сразу начинают пихать костыли везде.
poxvuibr
16.02.2017 13:08+1Я как-то допиливал pandoc, чтобы он генерировал хабра-разметку. Это при том, что Haskell я как не знал, так и не знаю. Тут главное научиться собирать и запускать код. Если это умеешь, то дальше проще.
Ищешь по ключевым словам, если код более менее, то дальше будет понятно, как сделать какое-то мелкое изменение. Дальше делаешь его, запускаешь код и смотришь — оправдывает он твои ожидания, или нет. И так повторять до полной победы.
KvanTTT
17.02.2017 19:42Не удалось найти в репе ничего по слову habr :) Можете кинуть PR или issue — тоже надо бы допилить pandoc для лучшей поддержки codeproject разметки.
poxvuibr
19.02.2017 23:11Это было достаточно давно, с тех пор в pandoc накомитили более 1000 коммитов. Под хабра разметкой имеется в виду хабровский html — он немного особенный. pr я не делал и issue не создавал. Просто поправил и использовал для своих нужд. Код можно найти в в моём маленькм форке. Там взят стандартный html, в который внесены модификации. Они там в четырёх коммитах. Название нового формата — habr. Если это вам чем-то поможет — буду рад.
Durimar123
16.02.2017 13:39+3Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто».
Диалектичненько.
То есть чем быстрее вы как программист — тем меньше влияния на качество вашего кода имеют дедлайны.
Или можно произнести равноценную: «Чемтупеешустрее меджеры, тем меньше влияют на качество кода программисты.»
sbnur
16.02.2017 13:59+5Короче, как в известном анекдоте: Что тут думать — трясти надо
TimsTims
16.02.2017 19:53Полную версию бы того самого анекдота, который все знают
sbnur
16.02.2017 20:31+4Привожу.
Идет физик-теоретик по пустыне. Жарко. Пить хочется. Видит кокосовая пальма. Подбежал, стал трясти. Не стрясается. Так, надо подумать. Огляделся, увидел палку. Кинул, сбил орех. Напился и пошел дальше.
Идет физик-экспериментатор по пустыне. Жарко. Пить хочется. Видит кокосовая пальма. Подбежал, стал трясти. Не стрясается. Так, надо подумать. А что тут думать — трясти надо.
zuborg
16.02.2017 14:26+8Программировать — это не всегда кодить, на самом деле.
Мне иногда приходится неделями обдумывать, как подступиться к какой-то проблеме, но этим я уберегаю себя от зря потраченного времени на написание кода, который тупо пойдет в топку.
Danov
17.02.2017 09:09+2С другой стороны, за эти недели можно было написать несколько прототипов и посмотреть на проблему с разных сторон. Попутно, прокачивается куча разных навыков, начиная со скорости набора кода до более высокоуровневых.
max3_05
20.02.2017 22:36Для того, чтобы написать несколько эффективных прототипов, надо определить, как эти протитипы оценивать. А то знаю я таких горе-разработчиков, которые напишут что-нибудь на коленках, а потом туча времени уходит на поддержку этого «прототипа».
Danov
21.02.2017 11:21Прежде всего, нужно осознавать соблазн признать прототип итоговым продуктом. Причем соблазн и со стороны разработчика и со стороны заказчика. Первому хочется быстрее получить деньги, второму готовый продукт. Заказчик может убедить разработчика, что и так всё уже хорошо работает. При этом разработчик может смириться с набором костылей в реализации с сдать продукту в продакшен. Ведь можно перейти к разработке другого продукта и получить дополнительный доход.
А вопрос соотношения доли костылей в архитектуре приложения остается открытым. Это вопрос финансовой оптимизации. Если работает, и не требуется сопровождение, и проще его переписать чем вносить правки, так зачем вкладываться в правильную архитектуру? А если есть потребность сопровождать и получать за это доход, тогда нужно оптимизировать архитектуру для снижения себестоимости сопровождения.
Прототип всегда пишут «на коленке». Он для того и нужен, чтобы понять, что еще за функционал потребуется прикрутить. После осмысления ТЗ (внешнего описания по Жоголеву), можно полностью с нуля спроектировать правильное приложение. А можно и докрутить прототип за несколько циклов спирали.
K-o-D-e-N
16.02.2017 15:58Они, конечно, правы в том, что в условиях сжатых сроков разработчики, как правило, будут писать сложный код
Причем сложный код, не значит сложная архитектура, а код без какой либо структурированности, накиданный наспех.
Вообще, как говорил один из моих наставников, когда видишь код и не понимаешь что тут происходит, начни с рефакторинга. Особенно когда код в этом очень нуждается.
OpieOP
16.02.2017 16:56В любой неопнятной ситуации гугли или читай доки. Вроде очевидная вещь, но часто сидишь и тупишь от недопонимания.
speller
16.02.2017 16:56+7Если тебе спускают подробное ТЗ на каждую задачу, где всё описано от и до — то да, ты кодер, и можешь строчить абы что и абы как, лишь бы побыстрее и в спецификацию уложиться. А если тебе нужно сначала принять решение «как это сделать», чтобы вписать в архитектуру и не нагородить костылей, и лишь потом фигачить код, то тут уже спешка и попытки «не думать» могут привести к плачевным результатам в виде будущих факапов и необходимости рефакторинга.
Поэтому, было бы интересно сначала узнать о типе решаемых автором статьи задач и об организации рабочего процесса и постановки этих задач. От этого очень много зависит в режиме работы программиста. Я бы даже сказал — всё.
powerman
21.02.2017 18:55На самом деле в процессе разработки архитектуры похожие техники тоже применимы — просто либо ты пытаешься всю архитектуру (или требуемое её изменение) удержать в голове и продумать целиком, либо начинаешь выносить отдельные части наружу (что-то нарисовать, для какого-го мелкого и понятного элемента написать спеку, изменить схему БД в более-менее нужном направлении, провести мелкие нагрузочные тесты каких-то подсистем, почитать более детально доку по малоизвестным фичам ЯП или БД, etc.) и в процессе много проясняется быстрее, чем если делать всё это в голове.
alexeiz
16.02.2017 19:39+4Не совсем понятно, на какой вывод наталкивает автор. "Меньше думай — пиши больше (говно) кода и делай это быстрее?"
Nordicx86
17.02.2017 09:39Скорее так — «не думай Лети» — в контексте — «пиши Не думая СЛИШКОМ много, позволяя коду появлятся без затруднений» — сложная на самом деле методика когда что то пишешь или кодишь, но когда умеешь «ловить» такие трансовые состояния процесс идет очень быстро — правда иногда проблема с последующим пониманием принципов работы…
PavelGatilov
16.02.2017 20:30+2Вместо фразы «Этот дедлайн помешал мне написать простой код» можно произнести равноценную: «Я недостаточно быстро программирую, чтобы писать просто».
Проблема в данном подходе — это то, что на следующий task/story/feature/project ты получишь еще меньший дэдлайн и это станет нормальной практикой. Проблема в том, что поставить дедлайн меньше и научиться быстрее кодить, вещи по сложности не сопоставимые.
pupizoid
16.02.2017 20:30В целом согласен с утверждениями автора, но он не уточняет один вопрос очень важный для программиста — качество сформулированной задачи. Если взять за аксиому что задача описана детально то да, статья описывает, на мой взгляд, все важные аспекты быстрого написания программ и соблюдения дедлайнов в конечном итоге.
Я очень много раз был свидетелем того что программисту давали задачу которая формулировалась двумя-тремя предложениями и подразумевала создание достаточно сложного продукта, без конкретных требований к составляющим. Ну и разумеется дедлайн из разряда: «Да че там писать, за неделю управишься!».
Поэтому я бы добавил еще один пункт к статье — Требуйте детального технического задания, и расписал бы соответственно плюсы и минусы наличия такового, а то начинающие программисты могут подумать что только на них лежит отвественность за срыв сроков выполнения проекта из-за того что они пишут код медленнее по причинам зависящим только от них.
AIxray
17.02.2017 02:24-1Всё сказанное в посте верно в большинстве случаях, Но не каждому человеку подойдёт, у некоторых всё же другой подход(я замечал).
Toshiro
17.02.2017 03:50+5Название статьи вводит в заблуждение. Она должна называться «10 очевидных вещей, ни одна из которых не является особенно важной». Я заходя думал, что тут будет какая-то методика — как любую сложную задачу превратить в мгновенный код. А тут банальная и очевидная бытовая туфта. Похоже даже мои джуниоры больше знают о том как кодить быстро, чем это ваш Макс из Гугла.
Zoolander
17.02.2017 06:01+1Этот совет годится для программистов, у которых уже есть какой-то бессознательный набор знаний, которые они могут применять. Для тех, кто программирует регулярно меньше года (или нерегулярно всю жизнь) — большая часть знаний находится пока в сознательной области, и «не думать» не получится
vadimr
17.02.2017 09:01+3Думаю, что, имея представление о функционировании велосипеда в реальном мире, полученное из анализа предметной области, написать класс Колесо можно без всякого представления о классе Велосипед. Это называется программированием снизу-вверх и ещё принципом инкапсуляции. А умельцы в цирке могут даже ездить на колесе без велосипеда (это низкоуровневый внешний интерфейс).
Anessence
17.02.2017 17:43Мне кажется, что не был упомянут достаточно значительный факт, как производительность инструментов разработки: программные и аппаратные. Недостаточная производительность которых может привести к значительным паузам. И чем больше эти паузы, тем опаснее, так как могут вывести разработчика из состояния потока.
Color
20.02.2017 00:35+4Не хочу никого обидеть, но выглядит как пособие для
индусовcode monkey. Все сводится к тезисам вида «быстро писать код = быстро разрабатывать продукт».
Для сайта-визитки это, может и актуально, но разве этот подход будет работать для более серьезного функционала?
На протяжении всей статьи автор постулирует, что работа программиста = написание кода. Ни больше ни меньше. И когда ты не стучишь по клаве, значит случилось что-то плохое и мешает тебе «работать».
Да, такое мнение было (и есть?) распространено среди руководителей, не знакомых со спецификой работы программиста (и R&D в целом), умеющих оценивать только количество. Также это актуально и для задач, не требующих высокой квалификации, например, когда вся архитектура уже написана (или ее нет, как таковой), и нужно только перенести эту идею в код, не добавляя ничего от себя. Ну к фрилансерам с почасовой оплатой тоже можно притянуть, хотя я сомневаюсь, что люди уровня выше code monkey на фрилансе большинство времени тратят на набор текста. Это только в фильмах про хакеров так. В остальных же случаях процесс написания кода — это лишь следствие процесса работы программиста, без которого не обойтись, но который не является сутью работы сам по себе. Этакий boilerplate-процесс, если можно так выразиться.
Нет, я очень хорошо понимаю посыл автора. Иногда действительно застрянешь в какой-то умозрительной проблеме, когда можно было бы написать проще ии так сгодитсяни к чему усложнять на ровном месте. Да и с отдельными пунктами я согласен. Но с общей идеей — абсолютно нет. И странно слышать от разработчика такие вещи
vasiliysenin
20.02.2017 22:37Есть ещё один способ быстрого программирования — это использование готового кода (повторное использование). Можно использовать как программные библиотеки так и шаблоны алгоритмов, изменяя их или комбинируя.
А иногда всё-таки можно задуматься и часть кода вообще не писать, за не надобностью. Например иногда можно решить проблему другим способом (не программным) или окажется что надо решать совсем другую проблему (и соответственно писать другую программу).
VMichael
Замечал за собой, что есть периоды, когда «прет мысль» и когда «не прет мысль».
Вот в период, когда «не прет» хоть убейся, получается медленно и мучительно.
За годы уже сложилась организация работы, когда интуитивно ловишь моменты, когда «прет».
Получается эффективнее, чем выдавливать из себя по капле разработку.
***
P\S: Про еду. Для себя заметил обратное. Когда я сыт, меня это отвлекает гораздо сильнее, чем когда я голоден.
Когда сыт, еще и спать хочется.
feudorsam
Согласен. Когда поем, то в сон сразу клонит. Поэтому обхожусь промежуточными перекуса.
BulatSa
Ем 4-5 раз в день, на работе —
И 2-2,5 л воды в день. Удобно вести отчет времени по Помидорро — большой перерыв — обед. Всегда легко сыт и голова не забита перевариванием большого кол-ва еды