VSCode Vim を使って開発効率を爆上げする
大体的には2021年初頭頃に、Vim for VSCodeを使い始めました。
理由はシンプルです。HHKBキーボードに変えた後、方向キーがなくなったため(小指でfnキーを押さえる必要があります)、テキストを編集する際に自然に方向キーの使用回数を減らしたいと思ったからです。また、HHKBのcontrolキーはCapsLockの上にあるため、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ファイルが含まれています。現時点では画像の拡大機能がありませんので、画像が小さい場合は読者自身で新しいタブを開いてご覧ください。)
定義に移動
ソースコードを追いかける際、関数を見ながら実装を確認することがよくあります。gdとgfという2つのバインディングを使用すると、ノーマルモードの状態でマウスを動かさずに実装を追うことができ、型をプレビューすることも非常に便利です。

マージコンフリクト
Pull Requestをマージする際に衝突が発生すると、右上にいくつかのオプションが表示され、conflictを解決するのに役立ちます。incoming、current、またはbothを選択することができます。同様に、操作をすべてキーボード上で完結させるために、ショートカットキーを設定しています。

GitHub上のファイルのURLをコピー
VSCodeで特定のファイルの実装を見つけて、他のメンバーと共有したい場合、GitHubでゆっくり探すのは面倒です。実はgitlens拡張機能には関連機能(gitlens.copyRemoteFileUrlFrom)が統合されているため、ショートカットキーでバインドできます。また、ブラウザを開いてGitHubのページに直接飛ぶことも可能です。

コードを素早くprettify
私は、format documentアクションをノーマルモードのffにバインドしていますので、fを2回押すだけでファイルをすぐにprettifyできます。もちろん、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で全てのtag blockを選択:例えば、<div>に包まれた部分を直接選択できます。- これを拡張して
citditなども使え、内容の変更や削除に対応しています。
- これを拡張して
dstで外側のtagを取り除く:フロントエンドでは、外側にdivが包まれているが、急に不要になった場合にこの操作で取り除けます。csttでタグを変更、例えばpからdivに変更:これは私のお気に入りの操作で、非常に素早く変更できます。
.:前の動作を繰り返します。yssb:テキストブロックを()で包みます。yiwciw:単語を削除します。cs"':"を'に置き換えます。dgn:検索した文字まで削除します。
他のVimのテクニックについては省略しますが、VSCodeVimはrecordingもサポートしており、複雑な操作に出くわした際には、あらかじめrecordingで記録してから実行することで、キーストロークを減らすことができます。
関連記事
- 測定が目標になったとき:窓税から Pull Request 数まで 僕はかつて、小さなツールを書いて自分が四半期にどれだけ PR を出し、どれだけ review を残し、どれだけ ticket を解決したかを集計し、数字で上司に成果を示そうとした。上司はただ、評価は成果だけで決まるわけではないと言った。数年後になって僕はようやく理解した——測定が目標になった瞬間、それはもはや良い測定ではなくなるのだと。イギリスの窓税からハノイのネズミ懸賞金、そして今日の PR 数による開発者評価まで、仕組みはまったく同じである。
- 画像のストレージと変換を Cloudflare Images に任せる Web ページに画像を一枚置くのはフロントエンドで一番簡単なことだ。でもそれをちゃんとやる——リサイズし、各フォーマットを生成し、トラフィックにも耐える——となると、実はひとつの解決策まるごとになる。だから僕は結局、原画一枚だけ渡して全部 Cloudflare Images に任せた。
- Access Keyはもう使うな Access KeyはAWSで見落とされがちなセキュリティリスクだ。OIDCとIAM Roleを組み合わせれば、GitHub Actionsはsecretなしで安全にAWSリソースを操作できる
- データベースの主キー: AUTO_INCREMENT、UUID、UUIDv7 バックエンド開発では主キーをどうするかをよく決める必要がある。auto increment か UUID か、衝突はどうするか、UUIDv7 と created_at + index の性能差はどれくらいか。実際に 2000 万件のデータで検証し、設計判断までまとめる。