僕がVSCodeVimで開発効率を向上させた方法
2021年の初め頃、Vim for VSCodeを使い始めた。
理由は単純で、HHKBキーボードに変えてから矢印キーがなくなったため(小指でfnキーを押す必要がある)、テキスト編集時に自然と矢印キーの使用頻度を減らしたいと思うようになったからだ。また、HHKBのキー配列ではControlキーがCaps Lockの位置にあるため、Controlキーを押しやすいという点もある。こうした外的要因の影響を受けて僕はVimを学び始め、VSCodeと組み合わせると本当に使いやすいことに気づいた。ここで、興味のある皆さんにいくつかの知見とテクニックを共有したいと思う。もしHHKBキーボードに興味があれば、以前僕が書いた記事も参考にしてみてほしい——無接點靜電容鍵盤 HHKB HYBIRD Type-S 使用心得
VSCodeVim
VSCodeVim はVSCodeの拡張機能で、VSCode内でVimのキーバインドや操作を利用できるようにするものだ。Vim単体を使う場合は設定の調整に多くの時間を費やす必要があり、僕自身もVSCodeのエコシステムから離れたくなかったため、VSCodeと直接組み合わせて使う方が手に馴染んだ。これが、僕が単体でのVimをおすすめしない理由でもある。ツールはあくまで補助に過ぎないとはいえ、VSCodeが提供するナビゲーションやターミナル統合、拡張機能、自動補完などは、開発効率を大いに高めてくれる。
この拡張機能はVSCodeとの親和性が非常に高く、VSCode内の機能に独自のショートカットキーを割り当てることができる。ここでは僕がよく使っている設定をいくつか紹介する。Vimのチュートリアルというよりは、この拡張機能を他の機能とどう統合して使っているかの共有に近い。
なお、この記事は単にVimとVSCodeVimの組み合わせをおすすめしているだけであり、Vimを押し売りするつもりもなければ、すべての開発者にVimでの開発を強要するつもりもない。
(この記事には大量のGIFファイルが含まれている。現在画像の拡大機能はないため、画像が小さすぎる場合は別タブで開いて閲覧してほしい)
定義へ移動(Go to definition)
ソースコードを追う際、関数と実装を行き来しながら見ることがよくある。gd と gf の2つのキーバインドによって、ノーマルモードのままマウスを動かすことなく実装を追ったり、プレビューで型を確認したりできるので非常に便利だ。

コンフリクトの解消(Merge Conflict)
Pull Requestをマージする際にコンフリクトが発生した場合、右上にコンフリクト解消を支援するいくつかの選択肢が表示され、incoming、current、またはbothを選択できる。これも同様に、操作をキーボードだけで完結させるために、ショートカットキーを割り当てて設定している。

GitHub上のファイルURLをコピーする
VSCode内で特定のファイルの実装を見つけ、それを他のメンバーに共有したいとする。その時にわざわざGitHubを開いて探すのは面倒だ。実はGitLens拡張機能には関連機能(gitlens.copyRemoteFileUrlFrom)がすでに統合されているため、ショートカットキーを割り当てることができる。また、直接ブラウザを開いてGitHubのタブにすぐ遷移することも可能だ。

コードを素早く整形(Prettify)する
僕はこのFormat Documentアクションをノーマルモードの ff に割り当てているため、f を2回押すだけでファイルを即座にフォーマットできてかなり便利だ。もちろん、素直にFormat on Saveを有効にしておくだけでもいい。
Git Blame
GitHub上にもBlame機能があって便利だが、VSCode内で完結できるならそれに越したことはない。この機能はGitLensにすでに備わっているため、ショートカットキーを割り当てるだけでいい。このように、キーボードだけで特定のコードを追い、原因を作った人を見つけるまでBlameを辿ることができる。(ここでは自分のプロジェクトを例にしているが、複数人での開発プロジェクトならさらに便利になるはずだ)

Finderでファイルを開く(revealFileInOS)
そのファイルが存在するパスに直接移動して作業したいときにかなり便利で、同様にVimのショートカットキーに割り当てている。

2つのタブを左右(または上下)に並べる
27インチの外部ディスプレイがある場合、HTMLとCSSを並行して書く際などにタブを左右に並べて配置すると見やすく、切り替えもスムーズになる。VSCodeVimでは :vs や :sp で分割できる。さらに、<C-w> + 矢印キー で左右のタブを切り替えることができる。

興味があれば以下のJSON設定を参考にしてほしい。人それぞれ好みのキーバインドがあるはずなので、自分のニーズに合わせて変更するといい。
"vim.normalModeKeyBindings": [
{
"before": [
"g", "l"
],
"commands": [
"cmake.build"
]
},
{
"before": [
"<leader>",
"q"
],
"commands": [
"workbench.action.openRecent"
]
},
{
"before": [
"g",
"f"
],
"commands": [
"editor.action.peekDefinition"
]
},
{
"before": [
"g",
"n"
],
"commands": [
"cmake.build"
]
},
{
"before": [
"<leader>",
"<leader>",
"c"
],
"commands": [
"merge-conflict.accept.current"
]
},
{
"before": [
"<leader>",
"o"
],
"commands": [
"gitlens.openFileOnRemoteFrom"
]
},
{
"before": [
"<leader>",
"<leader>",
"i"
],
"commands": [
"merge-conflict.accept.incoming"
]
},
{
"before": [
"<leader>",
"<leader>",
"b"
],
"commands": [
"merge-conflict.accept.both"
]
},
{
"before": [
"<leader>",
"s"
],
"commands": [
"workbench.action.quickOpenTerm"
]
},
{
"before": [
"<leader>",
"c"
],
"commands": [
"gitlens.copyRemoteFileUrlFrom"
]
},
{
"before": [
"<leader>",
"b"
],
"commands": [
"gitlens.toggleFileBlame"
]
},
{
"before": [
"<leader>",
"p"
],
"commands": [
"gitlens.openBlamePriorToChange"
]
},
{
"before": [
"<leader>",
"a"
],
"commands": [
"workbench.view.explorer"
]
},
{
"before": [
"<leader>",
"<leader>",
"r"
],
"commands": [
"revealFileInOS"
]
},
{
"before": [
"f",
"f"
],
"commands": [
"editor.action.formatDocument"
]
},
{
"before": [
"+",
"+"
],
"commands": [
"workbench.action.increaseViewSize"
]
},
{
"before": [
"-",
"-"
],
"commands": [
"workbench.action.decreaseViewSize"
]
}
]
その他のよく使うテクニック
vitvatタグブロック全体を選択:タグで囲まれたブロック(例えば<div>で囲まれた部分など)を直接選択できる。- 応用として
citやditなども利用でき、それぞれ内容の変更や削除に対応している。
- 応用として
dst外側のタグを削除:フロントエンド開発では、ラッパーとして囲んでいた外側のdivが不要になるケースがよくあるが、この操作で簡単に削除できる。csttタグを変更する(例:pからdivへ変更):これは僕が最も気に入っている操作で、非常に素早く変更できる。
.:直前の操作を繰り返すyssb:テキストブロックを()で囲むyiwciw:1つの単語をコピー/削除・変更するcs"':"を'に置換するdgn:検索した文字列を削除する
その他のVimテクニックについては割愛する。また、VSCodeVimはマクロ記録(recording)にも対応しているため、複雑な操作を行う際はあらかじめ記録してから実行することで、キーストロークを減らすことができる。
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。