Veltioblog

2025 年の開発環境

2025 年の自分の開発環境についての備忘録


前提:

https://gist.github.com/sile/ff7080fd41d3f74100f80c963bcbb429 に触発されて書いたため、まとめ方は同じ...

ハイライト

2025/12/26 時点での開発環境

ハードウェア:

ワークスペース構成:

ツール:

ハードウェア

Magic Trackpad

Magic Trackpad は結構気に入って使っていたのだが、自分が手汗を書きやすく指先まで湿ってしまうタイプであるため、 トラックパッド上を指が滑らないという残念な状況が度々あった。無理に動かすと指先がだんだん痛くなってしまうという経緯があって移行を検討し始めた。

移行用に Bluetooth マウスの購入を検討したが、 自分は普段 Windows と Linux では 2025年版使ってるマウス で紹介したマウスを使ってるいるため、どうせなら同じものを使うかということで有線でこのマウスを使うことに決めた。

ゲーミング向けマウスは余分な機能を削ってあって軽いのが良い（トラックパッドは三本指でシュッシュしてただけなので別に移行も困らない想定...）。

ワークスペース構成

以下のスクショのように仮想デスクトップ上に、ブラウザとターミナルを並べている。

ブラウザとターミナルの画面比率は 1:2 くらいにしてあって、これはディスプレイサイズが WQHD 3440 x 1440 で画面を三分割して使うのに十分だからこうしてる（ターミナルは tmux で二分割してる）。

Image from Gyazo

ターミナル

ターミナルは Ghossty を利用してるが、複数端末の管理は tmux で行っているため、Ghossty の機能の殆どは利用していないのが現状で設定もほぼデフォルト。 ただし、Ghossty 開発者の Mitchell Hashimoto 氏が tmux の代替機能をGhossty で開発することを目標にしているらしいツイートをしていたので、将来的には移行しているかもしれない。

tmux + ghq + fzf

ワークフローは 思考を減らしコードに集中するための tmux, Neovim 設定 という記事に書いてあったワークフローを真似した。

元々自分は ghq + peco でリポジトリ間を簡単に移動できるようにしていたが、tmux のセッションと ghq でのリポジトリを 1:1 に紐付けることでリポジトリの移動と端末管理を一手で行うことができるのはとても良いなと思ったので、記事と同様のワークフローにするようにした。

このワークフローの詳細は記事内で記載されている内容と同じになるのでここでは割愛する。

移行するにあたって peco から fzf に移行した理由は特にないが、強いて言えば neovim でも fzf を利用していたためこちらも fzf を使うかーというくらいの理由。

プログラミング

基本的には neovim でプログラムを書いている。

よく使う plugin は fzf.vim。このプラグインによって neovim 上で fzf を呼ぶことができて大変気に入ってる。

LSP は nvim-lspconfig と mason.nvim と mason-lspconfig.nvim を設定している。キーバインドとかは特にいじってない。

vim キーバインドが好きかつ neovim という名前がかっこいいというだけで使い始めたままここまできたし、カスタマイズもそこまでしていないため、来年はがんばって自作エディタを Rust で書いてみるというチャレンジをしても良いかもしれない。

iOS / Android のプログラミングもするため、IDE を使わないのか？という話もあるが、LLM のおかげで IDE が必要だった場面はだいぶ減ってきてるように思う（UI を触る場合は IDE を使うが）。

LLM で設計 -> ざっくりの骨組み生成まで行って、あとは neovim でちょこまか実装を繰り返すという感じでやっているため、IDE の必要性が減ってきてるのかもしれない。コンパイルのチェックも xcodebuild や gradle などでできるし大抵の場合は今のスタイルで困ってないという状況。

LLM 関連

LLM のツールは CLI ツールとブラウザで ChatGPT / Gemini を利用している。

開発時には主に CLI ツールで LLM を利用していて、tmux でペイン分割して使ってる。ブラウザとターミナルを 1:2 で使ってると言っていたが「ブラウザ | neovim | LLM 」という並びにしている。

LLM は Vibe Coding によるコード生成というよりは以下に書くような使い方が多い。これによって知識が増えていってることを実感はしてる。

コードの設計

最初に API をざっくり決めて、この API を追加するとしてユーザーはどのようにこれを利用するかのシナリオを考えるなどをやってる。 これによりユーザー目線でどういう API だと使いやすいかを考えやすい。その結果、どういう使い方をしてほしいか、何をやってほしくないかが型に現れたり、どういうデータ構造にすべきかが決まってくる。

コーディング中のアドバイス

LLM 登場以前は何パターンか実装パターンがあるうち、どういう実装がここでは良いかというのを実際にコードを自分で書いて繰り返すのは面倒だったけど、今はそれを LLM でやってしまえるのが良い。

このフィードバックループを高速化できたことが LLM の恩恵だと感じている。

レビュー

↑のアドバイスとほぼ同じなんだけど、LLM を使うことでセルフレビューの質が上がってきたように思う。特に今のワークフローを構築してからはターミナルにこもってセルフレビューを繰り返すようになった。できるだけレビュアーに負担をかけないように、かつ自分の学びになるように LLM をうまく使ってセルフレビューを続けていきたい（正直まだまだなので訓練中）。