小僧の神様

とは巧い言い回しだなぁ。

教訓：小僧にEclipseを与えてはならない（実にたくさんメソッドが入っていたわけで、だめなコードの生産性を高めては本末転倒であろう。より生産性が低いツールを与えた方がプロジェクト全体としては効率が向上する可能性がある）。または重箱の隅をつつくようなコーディング規約の厳密なチェックは、より質の低下を招く。

小僧にいきなり"いたれりつくせり"な統合開発環境(IDE)を与えるとろくな事にならないってのはある程度ベテランの開発者でも解っていないかもしれません。誰もが解っているのであれば最初はシンプルなエディタとコンパイラのみの環境からの学習を薦めるわけですがどうもそうではない訳で。トップダウン的には「IDEは生産性を上げてくれる神様」なのであり特にEclipseのようなオープンソースのIDEは見かけ上のライセンスフィーが掛からない上に巷に溢れる情報や書籍により教育費用を省けるし万々歳と思って要る節があります。んで結局作られて出てくるコードはぼろっかすなものばかりと嘆くのですがそれは当たり前ですよね。高性能な道具は見合った人じゃないと使いこなせい、という理です。


同じことがここ最近すっかり主流に躍り出たフレームワークを用いた開発にも言えると思います。例えばDI(Dependecy Injection)コンテナと呼ばれる依存性の注入を用いたフレームワークは少なくとも

オブジェクト指向の基本と限界
インタフェース(Interface)の意味と意義

これらを少しも理解していない開発者に与えた場合はやはりぼんくらなコードがわんさか生まれてくるでしょう。特にDIを使用した場合はインタフェースの設計がキモであるため使うだけならまだしも起こしたインタフェースがぼんくらだと目も当てられません。また、フレームワークもIDE同様に見る必要(見せる必要)の無い部分は見えないようにできているので育つ(小僧では無い)技術者は見えない物を見ようとする一部の熱心な人だけになる事が多いです。

コーディング規約に関しても全く同意します。規約を守ること自体が目的になった時点で規約はIDEが発する意味の無いwarningと同じ効果しか持ちません。規約を決める側は少なくとも何故そのような規約を遵守する必要があるのかをきちんと説明できるようでなくてはならないと思います。あと、規約で開発言語の限界を補うような使い方は規約の範囲を越えているためやはりうまくいきません。

L'eclat des jours(2005-07-01)"良い工夫と悪い工夫"より

#追記 '2005/07/02

Eclipse等のIDEを使うと初学者がとっつき易い、興味を持ち易い、という点は否定しませんし認める所ではあります。そこから開発言語やプラットホームの深い部分に興味が移っていく熱心な開発者ばかりであれば最初から使うのは悪いことではないです。でもそのような開発者って10人に1人、多くても2人位ということが経験で判っているので敢えて便利な道具をいきなり使うことに敢えて苦言を呈している訳です。別にEclipseが嫌いな訳ではありませんし、実際にはいきなりPCにEclipseインストールするプロジェクトが大半でしょう。