С 200 до 500 знаков в минуту — 4 года учусь писать код быстрее. Рассказываю о самых эффективных методах в статье
Опытные разработчики каждый день пишут тонны кода (а еще более опытные не пишут его совсем), и если ты хочешь быть продуктивным — нужно учиться писать быстрее. Сегодня на связи — Даниил Лихачев, python-разработчик в ДАЛЕЕ. Делюсь известными и не очень способами по ускорению написания кода.
Способ 1: печатать быстрее
Это самый очевидный и простой способ. Как минимум, нужно уметь печатать вслепую, почти не подглядывая на клавиатуру, но, как мне кажется, это любой уважающий себя программист и так может. После этого нужно развивать скорость печати, будь это ускорение текущего метода набора или переход на десятипальцевую печать.
Я считаю, что обучение должно быть веселым, тогда и прогресс будет виден намного раньше, поэтому я бы посоветовал использовать онлайн-тренажеры: например, «Клавогонки» и TypeRacer. Необязательно пользоваться зарубежным ресурсом для набора английского текста — все есть на «Клавогонках»: и уже собранные пользователями наборы текста, и полноценные уроки по ускорению печати за короткий промежуток времени, например, Упражнения Хруста. Лично я смог поднять скорость печати с ~200 до 450–500 символов/мин, что очень ускорило мою работу.
Также есть мнение, что на скорость печати влияет клавиатура. По своему опыту могу сказать, что я работал на разных клавиатурах, и ни одна меня не тормозила. Любая механическая, ножничная и мембранная клавиатура хорошо справляется с быстрым набором текста, если вы им владеете. Да, расположение клавиш на разных моделях несколько отличается — если ты привык к одной клавиатуре, то будет немного некомфортно пересаживаться на другую, но это дело привычки.
Способ 2: использовать средства IDE
Сейчас на рынке лидируют два решения: IDE от JetBrains и Visual Studio Code от Microsoft. Те, кому не хочется париться, просто ставят себе IDE под нужный язык от JetBrains и получают хотя и громоздкую, но полнофункциональную IDE со всеми возможностями, какие только можно придумать. Visual Studio Code более легкий, но его нужно кастомизировать самостоятельно через плагины.
Я сделал свой выбор в пользу VSCode, так как решение от JetBrains довольно неповоротливо и за него нужно платить. Как мне кажется, основная вкладка для любого, кто только поставил VSCode — вкладка плагинов. Если вам нужна поддержка Python, надо ввести в окне плагинов «Python», и можно выбирать из множества доступных плагинов. Среди них есть, в том числе, и разработанные самой Microsoft. Нужна поддержка SCSS? Проделываем те же действия, заменив Python на SCSS, и получаем полную поддержку в один клик. Иногда, конечно, приходится конфижить плагины, но не могу сказать, что это очень тяжело.
Однако, вне зависимости от того, где вы пишете, нужно знать про LSP (Language Server Protocol) и обязательно использовать языковые сервера для любого языка, потому что так вы сможете отлавливать синтаксические ошибки в коде, прыгать на definition функций, классов, методов или их references. Без этих трех функций, мне кажется, невозможно быть полноценным программистом. Потому что, как мы помним, правда всегда в исходниках.
Например, когда я сидел на VSCode, я использовал плагин Python — он разработан той же Microsoft. Плагин дал мне массу полезных возможностей:
полноценную поддержку языка через Pylance — проприетарный языковой сервер от Microsoft;
дебаг-мод для приложений на Python;
линтинг;
форматтинг;
рефакторинг;
юнит-тестирование;
и многое другое.
Способ 3: использование редактора Vim (или хотя бы vim motions)
Vim — это текстовый редактор, который работает в терминале на UNIX-системах. В отличие от других редакторов, у него собственная логика ввода текста, и его можно удобно кастомизировать под себя, поэтому Vim используют многие разработчики для ускорения написания кода.
Работа с Vim требует привыкания — это не обычный текстовый редактор, где мы используем клавиатуру вместе с мышью, чтобы управлять курсором и набирать текст. В нем есть три режима: режим ввода, командный и визуальный режим. То есть, все команды выполняются при помощи клавиатуры — и ввод текста, и перемещение по нему (в Vim это называется моушнами или движениями). Это здорово экономит время: например, вам не нужно брать мышку и искать начало строки, чтобы поставить туда курсор, а переместиться в начало или конец файла можно парой клавиш.
Но с другой стороны, это и вызывает сложности у новичков, потому что логика работы с текстом абсолютно меняется. При запуске Vim вы сразу попадаете в командный режим, а чтобы выйти из редактора, нужно написать определенную команду во внутренней консоли — привычно свернуть окно или кликнуть куда-то мышкой не получится.
Например, курсор управляется через клавиши H, J, K и L вместо стрелочек. Можно перепрыгивать через полные слова, нажимая E и B. Нажатие на % (Shift+5) открывает и закрывает парные знаки (например, фигурные скобки), чтобы прыгать сразу в конец метода или функции. В Vim огромное количество возможностей для быстрого движения по коду, которые не только позволяют писать быстрее, но и, как мне кажется, помогают сохранять концентрацию при написании кода. Это абсолютно меняет то, как вы работаете с кодом.
Чтобы освоить Vim, в редактор встроен справочник vimtutor, также существует игра Vim Adventures, которая помогает в формате квестов и головоломок выучить базовые движения. Но в целом очень много информации есть просто в Google или на Хабре. Чтобы работать с Vim, я советую отбросить страх, пересилить себя и начать. Например, если у вас два монитора, можно открыть шпаргалки по Vim на одном и работать на другом, поглядывая на подсказки. В конце концов эти движения отложатся в вашей мышечной памяти и будут совершаться на автомате.
Что касается меня — в VS Code и других IDE есть плагины, которые позволяют «включить» движения, как в Vim. То есть, вы находитесь в привычном интерфейсе VS Code, но при этом можете использовать моушны Vim, чтобы постепенно к нему привыкнуть. По моему опыту, достаточно 2–3 месяцев для того, чтобы выучить основные моушны. По личным ощущениям, многие остаются на этом этапе и это тоже хорошо! Даже если вы будете просто использовать плагин для движений, как в Vim, это уже сильно ускорит вас. Но я уверен, что могут найтись «отчаянные», готовые пойти дальше.
Если привыкнуть к Vim, он в разы ускорит работу. Для него разработано множество плагинов и готовых сборок, которые позволяют превратить его в аналог любой IDE —, но только она будет удобно кастомизирована именно под вас, если есть желание в этом копаться.
Важно отметить, что на самом Vim«е, как он есть, мало кто пишет. Чаще всего разработчики используют кастомные сборки — NeoVim или другие open source сборки, в которых умельцы уже поставили все нужные плагины. Это позволяет меньше заморачиваться с поиском нужных фич и сразу начать работать. Например, я для себя открыл LunarVim — это сборка, которая автоматически подтягивает LSP-сервера. То есть, когда я открываю файл на Python, у меня автоматически в фоне скачивается самый популярный опенсорсный языковой сервер Pyright. Это очень удобно: я могу нажать определенное сочетание клавиш и увидеть, какие параметры мне нужно передать, какая еще есть информация по функции, методу, классу, можно быстро прыгнуть к definition или референсам и т.д. Также, чуть-чуть посидев, можно настроить линтер и форматтер, чтобы парой сочетаний клавиш отформатировать текст и сразу видеть, где можно нарушать кодстайл. Для Python я использую flake8 для линтинга и black + isort для форматирования.
Пример моего config.lua под Python для Lunarvim:
```
vim.opt.guicursor = "i:block"
vim.opt.relativenumber = true
local formatters = require "lvim.lsp.null-ls.formatters"
formatters.setup {
{ name = "black" },
{ name = "isort" },
}
local linters = require "lvim.lsp.null-ls.linters"
linters.setup { { command = "flake8", args = { "--ignore=E203,E133", "--max-line-length=120" }, filetypes = { "python" } }}
```У LunarVim хорошая документация и активное коммьюнити, так что найти, как что настроить и куда класть, не составит труда. Главное — запастись свободным временем и терпением.
Способ 4: искусственный интеллект
Принцип работы любого инструмента на основе ИИ-модели таков — у владельцев модели есть облако, куда вы отправляете свою кодовую базу или кусок кода, и на основе этого натренированная модель решает, как дополнить текущую строчку, и возвращает ответ. Все это происходит очень быстро, в течение буквально нескольких секунд. Вроде бы рабочая схема, но есть нюансы.
Разберем один из самых популярных ИИ-инструментов для разработки — Copilot. У него есть несколько тарифных планов — персональный и бизнес. В персональном плане вы не можете запретить языковой модели обучаться на базе ваших проектов. То есть, если вы отправляете в облако рабочий проект, легко может произойти утечка данных. Чтобы такого не случилось, можно взять бизнес-подписку, которая стоит дороже, и закрыть доступ на обучение. Но с другой стороны, все равно вы отправляете свой код большим дядям из Microsoft, и никто не может гарантировать, что он не будет использован на стороне.
Также есть российский аналог Copilot, который называется GigaCode. Он создан на основе Сберовского GigaChat. И на ресурсах, где размещен этот инструмент, вообще не прописано, как они собирают и обрабатывают данные. Я не так долго пользовался этим продуктом, но опять же, не на рабочих проектах, потому что неизвестно, где потом будет использоваться мой код.
В целом, ИИ-инструменты можно использовать, но очень аккуратно. Если есть возможность, то оформлять бизнес-подписку, которая защитит код от копирования. Я воспринимаю такие инструменты как ассистента — он не должен писать код за тебя. Потому что код нейросети обязательно нужно проверять два, а то и три раза. И если условный Copilot напишет код, в котором вы особо не разбираетесь, то это может вылиться в большую головную боль.
Лучше всего ИИ-инструменты подойдут для маленьких кусочков, в которых вы точно уверены, но не хочется тратить на них время — например, описать JSON-объект. Или если вы знаете принцип, но немного забыли, какие конструкции нужно конкретно прописать — можно спросить это у Google или отправить в Copilot. Опять-таки, главный совет в работе с ИИ-инструментами — обязательно проверять, что они вам предлагают.
Немного про абстракции
Разговоры про абстракции в IT-коммьюнити, наверное, происходят уже на протяжении десятилетий. Тот уровень, до которого нужно абстрагировать свой код, каждый определяет сам, но в некоторых командах это доведено до крайней точки, и слоев абстракции становится больше, чем зубов у среднестатистического человека.
Понятно, что все мы читали о паттернах проектирования от «Банды четырех», знаем принципы SOLID, DRY, KISS и все остальное. Но не всегда уместно натягивать общее на частное. Умные дяди, которые придумывали эти принципы, писали общие (и правильные) вещи, но они не знают, какой конкретно кейс у вас в проекте. И, по моему мнению, руководствоваться только этими принципами при разработке — не самая лучшая идея. Всегда нужно подключать здравый смысл — читать авторитетные мнения и брать из них то, что подходит конкретному проекту.
С одной стороны, абстракции дают гибкость — у тебя все разбито на модули, все атомарно. Но с другой стороны, ты тратишь массу времени, чтобы это описать. И это очень редко приносит реальную пользу. По идее, абстракция нужна, чтобы можно было быстро что-то подправить, но в реальности огромное количество слоев выливается в часы работы. Все то же самое можно написать умеренно в одном месте, что-то выделить, разграничить зоны ответственности слоев у себя в приложении и работать в соответствии с этим.
Я не против абстракций, но считаю, что нужно для себя найти ту грань, при которой код будет достаточно абстрактным, чтобы можно было его править и поддерживать. Но при этом не уходить в абстракции на миллион ненужных слоев, с мыслями: «А ВДРУГ!». А когда происходит этот самый «А ВДРУГ», разработчик понимает, что выделил сущности неправильно, да и вообще все не так, как задумано. В итоге он начинает переписывать миллион слоев абстракции, чтобы все хотя бы заработало.
И в заключение: мой опыт
Для меня лучший рецепт для ускорения написания кода — это быстрая скорость печати + подходящая сборка Vim (будь то сборки по типу LunarVim или же VSCode с Vim плагином). Использование моушнов — это как небо и земля, по сравнению с обычным текстовым редактором. Однако предупреждаю: если получится пересесть на Vim, работать или даже просто писать что-то относительно длинное вне Vim будет больновато. Иногда можно подключать сюда Copilot по бизнес-подписке для написания каких-то рутинных вещей.
Лично я пользуюсь всеми способами где-то с 2019 года. Первое время привыкать к Vim было очень тяжело, но где-то через 3–4 месяца я натренировал мышечную память, и дело пошло быстрее.
Могу сказать, что скорость работы увеличилась где-то на 20–30% — одни только моушны значительно ускоряют написание кода. Потому что тратится гораздо меньше времени на то, чтобы найти нужную строчку, ткнуть в нее курсором и т.д. Так что всем, кто обеспокоен своей скоростью в написании кода, я советую попробовать все эти способы и вывести для себя наилучшее решение.
Habrahabr.ru прочитано 3436 раз
