Как научиться писать код быстро — отвечают эксперты

Существуют ли какие-то техники, чтобы научиться быстро писать код? Спросим у наших экспертов.

Кирилл Хлопцев

начальник отдела разработки Центра программных решений «Инфосистемы Джет»

Любой разработчик под фразой «написать код быстро» в первую очередь поймёт «написать плохой код, похожий на работающий». Потому что что в перспективе проекта или продукта в целом единственный способ двигаться быстро — делать качественно. Trade-off качества на скорость возможен только в вещах, которые обречены не попасть в продакшн — прототипы и эксперименты. Чтобы делать качественно — нужно думать: «А как научиться думать быстро?» Только приобретая собственный опыт и изучая чужой.

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

Из ошибок, которые сказываются в первую очередь на скорости кодинга, я бы выделил две. Первая заключается в преждевременной оптимизации, когда для решения задач специалист начинает придумывать сложные способы реализации, уповая на то, что в дальнейшем это решение будет использовано в других задачах либо в намного более жестких условиях, чем задумывалось. Приведу случай из практики: стоит задача проконтролировать входящий документ по базовому набору правил. Разработчик, не получив достаточно вводной информации, решает, что таких правил и форматов текста будет не 5, а 150. А документов не 5 в секунду, а 500. Поэтому он решает сделать отдельный масштабируемый сервис с библиотекой подключаемых правил, что занимает существенное время (хотя в будущем, может, и не будет использоваться вовсе). Да, во многих случаях такие решения оказывается верными, но всё равно потребуют переработки. Конечно, это не означает, что нужно стремиться к предельному упрощению, но в отсутствие полноты понимания задачи нужно делать простые и понятные решения, готовые к рефакторингу.

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

Общему ускорению способствуют различные agile-методики, тот же Scrum, например, помогает убрать «белые пятна» в понимании задачи и продукта, получить поддержку команды и, что самое главное, самому чётко определить для себя план действий. Конечно, немаловажно тут и наличие хороших инструментов вроде современного компьютера и удобного рабочего места, актуальных средств разработки, выстроенных процессов CI/CD — той среды которая минимально отвлекает от решения основной задачи.

Семен Тараканов

разработчик Galileosky

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

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

Среди системных подходов решения задач очень популярен agile-подход, когда ты итеративно разрабатываешь проект. Это позволяет работать эффективнее, а значит быстрее решать задачу.

Михаил Андрейков

Senior .NET Developer в «Циан»

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

Изучите «горячие клавиши» вашей ОС и IDE

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

• Ctrl+Shift+стрелки влево и вправо позволяют выделять несколько слов целиком;
• Ctrl+Shift+B — собрать проект.

У продуктов JetBrains есть даже такое окно «Search Everywhere», в котором можно написать название команды и найти «горячую клавишу» для этого действия.

Шаблоны

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

Библиотеки

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

Автоматизируйте ваш процесс

Старайтесь автоматизировать процесс разработки как можно больше. Простые вещи, которые можно автоматизировать уже сейчас:

• создание ветки от мастера в один клик;
• развёртывание проекта локально или в контейнере одной командой.

Слепая печать

Пожалуй, самый популярный ответ на то, как печать код быстрее. Тут всё просто — это надо уметь. Можно овладеть этим навыком не в полной мере, но всё-таки это необходимо.

Виталий Филиппов

разработчик-эксперт, компания CUSTIS

Мне кажется, важно много знать и помнить. Чем больше влезает в твою голову, в самом широком понимании этого выражения, тем проще писать код. А чем проще его писать, тем выше скорость.

Вопросы на собеседованиях типа «что делает вот эта функция» хоть и выглядят глупо, но проверяют именно то, что вы, имея опыт работы с каким-то языком, должны обязательно помнить. Ясно, что всё в конечном счете можно загуглить, но вот этот гуглеж и тормозит процесс.

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

Ещё я верю: чтобы писать код быстро, желательно использовать инструменты, которые позволяют писать его меньше, а тестировать быстрее. Это в целом очень полезно, так как меньший объём кода снизит его сложность для того, кто будет с ним разбираться в следующий раз. Если кто не понял, это камень в огород любителей большого числа слоёв и объектной ориентированности ? Ну и в адрес авторов Bitrix-like простыней на 3000 строк кода без единой функции, конечно, тоже. Самое приятное занятие — это не написать кусок кода, а удалить кусок кода, сохранив функциональность.

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

А еще ваша IDE, которая пытается услужливо додумывать за вас, скрывать типы, по одному нажатию клавиши генерировать простыни кода — не помощник, а враг. Простыни никуда не денутся, хоть вы их и не будете писать руками. А вы в итоге станете зависимыми от IDE и перестанете помнить, где что лежит. В конце концов, самые хардкорные парни, например разработчики ядра Linux и системного софта типа Ceph, пишут код в Vim. При этом в коде ядра даже практически нет документации. Почему этим парням не нужна IDE? Да просто потому, что они и так помнят всё, что им нужно. Поэтому они и круты.

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

Дмитрий Сергеев

тим-лид, ведущий разработчик, REG.RU

Написание кода — не то же самое, что набор текста. Как правило за написанием самого кода идёт стадия тестирования и приёмки заказчиком. Бывает, что эти стадии по времени оказываются более продолжительными, чем время, затраченное на основной код. Но как же всё-таки сделать всё это быстрее? Не делайте ничего лишнего. Следуйте принципу YAGNI («You aren’t gonna need it»): он подразумевает отказ от добавления функциональности, в которой нет потребности. Делайте сначала самое важное. Используйте итеративный подход к разработке. В большом проекте не пренебрегайте юнит-тестами. Это поможет сэкономить массу времени на отладке.

Игорь Камышев

ведущий разработчик в Breadhead

Чтобы быстро писать код, не нужно быстро набирать текст, это популярное заблуждение. На самом деле, 90 % времени программист думает и ничего не пишет. Потому важнее научиться быстро думать. Есть несколько вариантов как это сделать:

• набраться опыта — чем больше решённых задач есть в багаже разработчика, тем быстрее он решает новую задачу;
• расширять кругозор — большая часть задержек происходит из-за неизвестности, поэтому нужно постоянно изучать новое и смотреть на индустрию вокруг;
• брать сложные задачи — если вы решите сложную задачу, то быстро вырастете и будете решать более простые задачи быстро.

Данил Юсупов

инженер-программист 3 категории в компании ICL Services

Полагаю, что вопрос не в скорости долбления по клавишам на клавиатуре, а в стремлении написать хороший код. ?

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

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

Хорошим «бустом» в данном направлении также станет практика парного программирования, если, конечно же, работа позволяет и твой коллега не против.

Дмитрий Рогов

директор по технологическому развитию ИТ-компании «АйДи – Технологии управления»

В целом, скорость написание кода и его объём давно не являются общепринятой характеристикой эффективности работы программиста.

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

• 35 % времени уходит на продумывание работы;
• 15 % времени уходит на настройку окружения;
• 35 % времени уходит на проверку и исправление кода;
• 15 % занимает собственно написание кода.

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

Скорость самого процесса набора кода в среде разработки не сильно различается у опытного программиста и начинающего.

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

Олег Шиков

декан факультета веб-разработки в GeekUniversity

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

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

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

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

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

Ну и конечно практика, очень много практики — её вам не заменит никто.

Роман Спиридонов

СТО в The JstUP Team

Есть несколько механик, позволяющих ускорить скорость набора кода.

1. Слепая печать. Причем не просто слепая печать для набора на русском языке, а слепая печать для английской раскладки с обязательной проработкой спецсимволов, которые приходится набирать в большом количестве. Важно при этом также стараться не опечатываться и сразу писать правильные конструкции из языка.
2. Настройка среды разработки. Необходимо правильно настраивать среду разработки, которую используешь в процессе написания кода. Ведь установленные плагины для генерации кода из сниппетов позволяют серьёзно ускориться. И вместо написания margin-right: 10px, можно набирать mr10px и жать Tab.
3. Использование быстрых клавиш в IDE или текстовом редакторе. Важно знать возможности используемого инструмента и применять их. Переключение с клавиатуры на мышку — долгий процесс, от которого желательно избавиться. Для навигации по файлам, например, в Sublime Text 3 можно нажать Ctrl+P. Чтобы перейти к конкретной функции в файле — Ctrl+R, а для перехода к конкретной строке — Ctrl+G. Подобные сокращения клавиш есть во многих IDE, и их стоит себе записать и выучить.
4. Практика, практика и ещё раз практика. В быстрой работе вообще и в написании кода в частности важен технический навык. Вы можете выдавать отличный результат в клавиатурном тренажёре, но при постоянной работе печатать медленно. Или же использовать быстрые клавиши, только когда смотрите в шпаргалку с ними. Все эти пункты необходимо тренировать и отрабатывать до полного автоматизма, чтобы при следующей необходимости переключиться к другому файлу и добавить что-то в метод вы не думали, что нужно нажать, и уж тем более не тянулись к мышке, а сразу действовали и получали нужный результат.

Евгений Ким

руководитель отдела разработки платформы RU-CENTER

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

Во-первых, уменьшите время на рутинные работы.

Потратьте время на изучение IDE, которой вы пользуетесь. Выучите основные комбинации клавиш, чтобы работать без использования мыши или тачпада.

Используйте шаблоны для часто повторяющихся конструкций (большинство IDE позволяет это сделать), настройте автозавершение кода и т. д.

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

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

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

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

Мария Горькова

эксперт в области IT-разработок

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

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

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

• на этапе анализа требований уметь задать существенные вопросы и пользоваться документацией;
• на этапе раздумий уметь воспользоваться опытом коллег и не изобретать велосипед там, где это не нужно;
• при тестировании и отладке владеть инструментами и методиками тестирования.

Теме правильной и эффективной разработки посвящено много литературы, например «Идеальный программист» и «Чистый код» Роберта Мартина. В целом же, чтобы «быстро» писать код, нужен системный подход и практика, которые рано или поздно дадут свои плоды.

Михаил Адигеев

руководитель отдела программных разработок и поддержки компании «ГЭНДАЛЬФ»

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

Вторая по очерёдности цель — «как научиться писать код правильно», т. е. в соответствии со стандартами и рекомендациями. Это позволит сэкономить время (ваше или ваших коллег) в будущем.

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

Рустам Салимзибаров

руководитель отдела разработки «Сателлит Инновация»

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

Чтобы получалось подхватывать мысль и превращать её в код, нужна практика. Нужно много практики! Чем больше тренируешься — тем больше скорость. Здесь, кстати, поможет и общая тренировка в скорописании на клавиатуре. Помогут любые практики и приёмы. Сначала фразы вроде «правый безымянный — на 0, O, L, >» будут казаться бессмысленными, а затем пальцы начнут догонять мысли.

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

А вообще, надо писать не быстро, а правильно. Много кода — это хорошо только у индусов.

Виталий Чижков

руководитель группы разработки проектов Тверского технологического центра Accenture

Когда стоит задача написать код быстро, мы обращаемся к трюкам, которые лежат на поверхности, таким как: GTD, DDD, TDD, Agile. Шорткаты IDE, DevOps, кодогенераторы, WYSIWYG. Это клёвые штуки, и они правда работают. Но существенное ускорение дают менее очевидные вещи.

Жизненный цикл разработки программного продукта с планированием, тестированием и сопровождением — это марафон, а не спринт. И скорость в моменте не так важна, как скорость в перспективе.

Самыми главными пожирателями времени являются отладка, правка багов и незапланированный рефакторинг.

Стоит ли ускоряться ради того, чтобы накидать тысячи строк кода, если две из них будут стоить нескольких дней отладки? Или если проект придётся существенно переделывать из-за того, что он не оптимизирован под планируемую нагрузку?

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

Писать код быстро — означает писать качественно.

Наибольший прирост скорости дают тщательное планирование, покрытие тестами и хороший стиль программирования с правильной архитектурой. Последнее приходит с опытом; но познакомиться с good practice, изучить релевантные open-source-проекты, почитать Макконнелла и «банду четырёх» никогда не будет лишним. Изучайте новые стеки и инструменты — технологическая эрудиция позволит выбрать готовое решение, сэкономив время на реализацию.

Александр Сибречный

ведущий frontend-разработчик TalentTech

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

• декомпозировать;
• структурировать;
• организовать.

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

Этап структуризации предполагает создание плана работы — какие задачи и в какой последовательности выполнять. Совсем не обязательно, что задачи будут идти строго одна за другой: какие-то можно выполнять параллельно, какие-то задачи взаимозависимы и так далее. Иногда эффективнее вообще начинать с конца и чётко понимать, к какому результату мы должны прийти.

Под организацией я подразумеваю использование инструментов, позволяющих регулировать рабочее время. Мы используем совместные календари для встреч, JIRA для ведения статуса задач и индивидуальные способы фокусировки. В команде популярна техника помидора (25 минут напряжённой работы и 5 минут отдыха) и метод лягушки (самое сложное сделать с утра и тогда остальные задачи кажутся намного проще).

Алексей Ладейщиков

CTO в aim digital agency

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

1. получение знаний;
2. формирование умений;
3. формирование навыков.

Знание — это чистая теория.

Умение — это возможность применять знания на практике. При этом умение предполагает постоянный контроль собственной деятельности. Требует неспешности и постоянного внимания.

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

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

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

Вывод: когда учитесь — не спешите.

Анатолий Пешков

технический директор компании Mad Brains

Дедлайн — главный мотиватор писать код быстро. А если серьёзно, главное, что тормозит программиста в написании кода в турбо режиме, — это неопределённость. Чем больше специалист знает подходов и вариантов решения задачи, чем лучше он работает с инструментами, чем увереннее и осознаннее он работает с используемыми библиотеками и фреймворками — тем меньше неопределённость, а значит, тем меньше времени он будет останавливаться, чтобы почесать репу и поковырять в носу, размышляя, куда положить очередной класс и как назвать следующий метод. Читаем книги, учим паттерны, практикуем горячие клавиши, внимательно изучаем документацию → profit!

Александр Грисенко

руководитель проектов цифровизации и разработки информационных систем

Если речь о скорости печати — то тренажер слепого метода.

Если речь о скорости решения задачи — то ставить задачи, которые нужны самому себе, например написать свой учёт своих финансов. То есть решить практическую собственную задачу собственными силами. Чем чаще решение будет помогать, тем более эффективно будет обучение. Выбирайте простую задачу, которую делаете ежедневно, и попробуйте это автоматизировать при помощи кода. Например 3 раза в день присылать в Telegram количество неотвеченных писем в почте. Дальше добавлять фичи, например ссылку на почтовый ящик, список заголовков писем, чтоб оценить важность и срочность ответа. Решайте повседневные задачи и придёт понимание прикладного применения написанного кода.

Итак, как быстро писать код?

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

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

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

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