補完駆動開発のすすめ
エディタを使って開発しているとき、自分が最も重要視するのが補完が出るかどうかである
エディタやプログラミング言語によって補完の質は異なるのだが、この補完があるかないかでプログラミングの速度というものが段違いになる
エディタに求められる機能はいくつもあるが、この補完にまさる重要性というのは他に比べられるものはないと思っている
なぜか?
プログラミングにおいて補完というものは本質的には必要ない。プログラミング言語の仕様に基づいて記述すればプログラムは動くので、その仕様を覚えていれば補助を得る必要はない
それはパソコンで文章を入力する際にもまったく同じことがいえるが、IMEの予測変換が文章作成においてどれほど重要かというのに異論は無いだろう
プログラミングにおける補完というのは文章作成の予測変換とは異なり、単なる入力の効率化以外にも重要な機能である
それは、補完を使いこなすということではなく、補完がきちんと効くかどうかという事自体がプログラミングの効率を左右するのである
これはどういうことかというと、通常補完は静的型付け言語である方がより機能する。これはその宣言的なプログラミングスタイルの性質が、エディタによって解釈しやすいからである
逆に動的型付け言語の場合、ランタイムの柔軟性を優先するためエディタが解釈しやすい宣言的なプログラミングモデルは省略されがちである
小規模なソフトウェアであればエディタの補完が効くかどうかはそこまで問題にならないが、大規模なソフトウェア開発においては補完が効くかどうかと言うのが非常に重要な要素になってくる
大規模なソフトウェア開発においては、通常関わるプログラマが一人ではなく多人数になるため、必然的にすべてのコードが一人によって書かれるということはありえない
どのような開発を進めたとしても、他人の書いたすべてのコードを書かれたときから把握しているということはない
誰かがそのコードを書いてからしばらくたってそこに手を入れる必要が出てくる際に、そのコードの意味や使い方を理解する必要が出てくる
そうなったときに補完が効くというのは、
コードが静的型言語で宣言的に記述されている
メソッドの呼び出し方などがすぐに分かる
IDEがサポートしているメジャーな言語である
IDEがサードパーティライブラリのリンクの仕方などを把握している
というプロジェクトがある程度の統制をもって作られているということそのものを意味する
開発者同士で常に密なコミュニケーションがとれるなら、このような特徴は無視できる
しかし実際の開発では、チームのメンバー以外が作ったコード(ライブラリ)を多用せざるを得ないし、同じチームの別の人が作ったコードですら実際はよくわからないことのほうが多い
そういうときに補完が効くだけで、パット見で何が行われているのか、どう使うのかということの手がかりを掴みやすくなる
補完の他にコードジャンプなどの機能もあるとなお便利である
こういう状態になっていないプロジェクトでは、何か分からないことがあったときひたすらコードの呼び出しを人力で辿ったり、作った人に根掘り葉掘り聞いて回る羽目になる
自分以外のいろいろなプロジェクトを眺めていても、とにかく補完が効かないプロジェクトが多すぎると思う
補完が効くだけで新規開発者も開発に乗りやすいし、プログラミングのルール的なものも自然に覚えていきやすい
プロジェクトの参加しやすさ、開発しやすさというのはコミュニティやドキュメントの充実さということが重視されがちだが、プログラミング言語そのものとIDEの支援が十全に受けられる状態を作っておく努力をしておくだけでかなり維持できると思っている
逆に新規開発者が入ってきたときに開発に四苦八苦していたら何かが健全でない状態になっているのではないかと考えるべきである
余談
個人的にRailsのCoC(Convention over Configuration)はその対極にある本当にひどい考え方で、Rubyが書けてもRailsが矯正する謎のルールを覚えないことには何も出来ないというプログラミングの本質から外れすぎた悪い設計である
プログラミングはプログラミング言語の仕様によってのみ制御されるべきで、プログラミング言語を使って別のプログラミング言語を作り出すDSLやマクロなどは、だったらそういうプログラミング言語を作れと思う