VimはIDEではありません

長い間、何か役に立つものを書きたかったのですが、何を共有できるのかわからず、推論についての別の記事に出くわしました。vim、emacs、またはIDEの方が良いでしょうか。 最初はIDEとvimの比較を書きたいと思っていましたが、IDEの使用が少なすぎて、偏りが怖いです。 したがって、vimを使用する理由を簡単に説明します。 編集者が自分のニッチを占めることを示すためだけに。 また、vimを使用して発生した問題と、それらをどのように解決したかについても説明します。



vimとの出会い



私は* nixのようなシステムのファンであり、そのようなシステムはすべてデフォルトで常にviを持っていると聞きました(ただし、常にそうであるとは限りません)。 そして、有名なLinuxディストリビューション用のCプログラムを作成する必要が生じた後、IDEの使用について疑問はありませんでした。viを開き、コードを書き始めたチートシートを開くことがよくありました。 私はすぐに、vimを通常のエディターとして使用し、コマンドモードのすべてのパワーを使用しなかったことに注意します。



小さなプログラムの時間が過ぎて、今はすべてが深刻です



学生としては素晴らしい時間でしたが、今はエンジニアです。 技術的なスタックを選択する必要がなかったので、phpで書き始めました。 PHPに最適なIDEの1つがPHPStormであることは誰もがよく知っていますが、無料のIDEを含む他の多くのIDEもあります。 しかし、同僚全員が私にPHPStormを勧めてくれたので、経験豊富な開発者のアドバイスを逃しませんでした。 このIDEは本当に優れており、Web開発者が必要とするものはすべて揃っていますが、問題がありました。IDEの動作は非常に遅いです。



仕事のスピードは良くありませんでした。 私が自由に使えるのは、Intel Core 2 Duo(正確に覚えていれば2.4 Ghzの2コア)3 GB RAMとHDDを搭載したラップトップでした。 新しいハードウェアにお金はなく、後輩の給料は高くなく、私は融資を受けたくありません。



このプロジェクトは、約1.5 GBのソースコード、Oracle上のデータベースで構成され、いくつかの特定のライブラリを使用していました。 また、非常に大きなリソースファイル(XML)があり、手動で編集する必要がありました。



PHPStormはひどく遅れ、長い間実行され、長い間検索され、テキストを編集したときにハングしました。XMLを開くことができませんでした。



そして再びヴィム



vimについて最初に言及する価値があるのは、設定と追加のプラグインを作成しないと、通常のプログラムでプログラムを作成できないことです。 しかし、すべてがセットアップされていれば、生きることができます。 次に、vimはIDEではないため、IDEを作成しないでください。 たとえ100個のプラグインをねじ込んだとしても、PHPStormや<IDEがここにある>とは異なります。



編集用のエディターですが、...


しかし、開発とはコードの編集だけでなく、分析、リファクタリング、デバッグ、ファイルの移動などです。



だから問題


プロジェクトファイルをツリー構造で見たい


プラグイン( NERDTree )でこの問題を解決しました。ファイルツリーの表示、操作などを行うことができますが、vimには組み込みのファイルマネージャーもあります。



編集中に構文エラーが発生したことを理解する


コードの静的分析とその結果のエディターへのマッピングは単純なタスクであることが判明しました。これはプラグインによって解決され、私が知っているPLについても同様です。



クイックファイル検索とクイックファイル検索があります


私はvimgrepまたはackを使用してファイルを検索します。これはIDEほど効果的ではないかもしれませんが、巨大なプロジェクトでも非常にスマートに動作します。 また、ファイル自体を検索し、 一連のfindまたはgrep + vimコマンドを使用して、またはプラグイン(たとえば、 ctrlp )を介して直接vimで編集用に開くこともできます。



エディターからデバッガーを実行する


デバッガーvimと友達になれませんでした。 むしろ、xdebugと通信するためのプラグインがありますが、それを使用することはあまり便利ではありませんが、このツールの価値は私にとって最小化され、コールスタックを見ることができ、残りはテクニックの問題です。 今はphpで記述せず、コンソールツール(gdbの類似物)をデバッガーとして使用していますが、十分な数があります。



コード検査ツールを持っている


コードの検査は見た目ほど必要ではなく、プラグイン( tagbar )を持っていますが、ほとんど使用しません。



メソッドまたはクラス定義に移動する


定義への通常の移動は、Cおよびその派生物(php、ruby、pythonなど)でのみ機能します。 設定できませんでしたが、すぐにackとvimgrepの使用に慣れました。



プロジェクトに関連付けられたオートコンプリートを持つ


オートコンプリートには非常に多くのプラグインがあるので、すべてを試すことはできませんが、時間が経つにつれて、これはそれほど便利なものではないと判断しました。 一部の人にとっては非常に重要であることに注意してください メソッドとクラスの非常に長い名前(hello、java)が使用されますが、必要に応じて、適切な自動コンパイルを構成できます。



多言語サポート


新しい言語のサポートを有効にするには、通常、適切なプラグインを接続して決定します。たとえば、golangの場合、すべてを実行できる1つのプラグインを接続するだけで十分です(強調表示から静的分析および自動フォーマットまで)。



非常に大きなファイルで作業する


Vimはそのままで大きなファイルを使用できますが、巨大なファイルにはプラグイン( LargeFile )もあります。これを使用すると、ギガバイトのファイルを開くこともできます。



コードの自動フォーマット


コードの自動フォーマットはすぐに使用でき、さまざまな言語のプラグインから設定を自動的に取得します。



バージョン管理の統合


私はgitを使用し、bashでそれを行いますが、一部の操作ではいくつかのプラグイン( vim-fugitivenerdtree-git-plugin )をインストールしました。



そのまま編集


vimの最も重要な機能はそのモードです。 それらの多くがありますが、最も重要なのは通常モードまたはコマンドモードです。 しばらくしてから(2〜3か月)、コマンドモードでコードをほぼ完全に編集しました。 もちろん、何かを書く必要があるときは挿入モードに切り替えますが、そうでない場合はコマンドを使用します。 これにより、キーボードから手を離さず、しばらくしてコードの編集方法について考えるのをやめることができ、必要な変更に完全に集中できます。 おそらく最も成功した例はピアノです。ピアノを弾くことを学ぶと、どのキーを押すかではなく、音楽だけを考えるようになります。 そして、ホットキーではそのような結果が得られないと断言できます(私は非常に長い間試しましたが、うまくいきませんでした)。



まとめると



弱いハードウェアと巨大なプロジェクトで働いていた状況では、IDEの使用は苦痛でしたが、標準* nix-toolsとvimの組み合わせにより、直面するすべての問題を解決することができました。 今はvimでも働いていますが、すでによく知られている環境を再学習して変更したくないので、すでにそれはうまくいきました。 時間が経つにつれて、私はますます効率的に働くようになりました。 vimおよび* nixシステムは、非常に長い間研究することができ、特定の問題を解決するための新しい方法を常に見つけられるものです。



IDEを使用したくない場合や、クールな有料版のお金がない場合は、vimやemacsなどのエディターで作業することをお勧めします。 彼らのイデオロギーを理解し、それが身近になれば、コードの作業に問題は生じません。



しかし、これはバックエンド開発者としての私にとってはすべて真実であり、おそらくGUIアプリケーションやフロントエンドを開発するために、エディタは制限されないと言う必要があります。



All Articles