skillup

技術ブログ

Java プログラミング全般

便利すぎる道具の弊害

投稿日:

現在、Javaのプロジェクトでは会社でNetbeansを使っていますが、IDEを使っているばっかりに理解できていないところがありました。便利すぎる道具の弊害ですね・・・

IDEについて一応説明をしておきますと、IDE(統合開発環境)とは本来ばらばらであった

  • コーディングにおけるさまざまな補助機能
  • コンパイル
  • デバッグ
  • ビルド
  • デプロイ
  • バージョン管理

などのさまざまな処理がワンセットになっているソフトでそのほとんどがGUIから操作できるようになっています。

JavaのIDEというとEclipseやNetbeansなどのIDEが有名ですね。おそらくJavaで仕事をしている人の95%以上がこのどちらかのIDEをつかっているのではないでしょうか。

PHPなどのスクリプト言語ならともかく、Javaで大規模な開発を行う場合にはIDEはほぼ必須といってもいいと思います。非常に極端なことを言えば、Javaの開発をエディタで行おうとするのはコンビニやスーパーを使わずに自給自足の生活をするようなものだと思います。

便利すぎる道具は技術力の衰退につながる

とはいえ、IDEもいいことづくめではありません。上記のような一連の作業が全て自動化できてしまうために、技術者自身が前述した作業(コンパイル~デプロイ)について考えなくなる、というデメリットがあるからです。

私はいつもはWindowsのローカルマシンでNetbeansで開発をしています。Javaの開発でのキャリアがそれほどあるわけではないのですが、コーディング自体はなんとかなるため、ローカルのマシンで動かすには特には問題ありませんでした。IDEを使っているとよくわからなくてもボタンを押せば動きますし、文法エラーなどはIDEが教えてくれます。

ただ今回、Javaで作ったソースをサーバー(CentOS)にあげて、ビルドをしようとしたのですが、当然Netbeansがないためにすぐには実行できません。結局あれこれ調べて手作業でのビルド処理を調べることになりました。

これをもともとエディタで書いて、コンパイルし、実行していたら処理を全て自分で記述しなくてはならない反面、windowsでもLinuxでもやることは一緒だったため、かえって移行はスムーズだったと思います。

フレームワークの弊害

このことはIDEだけに限りません。便利すぎるがために技術者の思考力が落ちる点としてはフレームワークの使用などが上げられます。フレームワークはよく使う汎用的な技術などをまとめたソフトウェアです。

同じアプリケーションを作成する場合でもフレームワークを使用するのとしないのではかかる時間を半分かそれ以下にすることができます。ただし、フレームワークでもIDEのときと似たような現象が起こります。

便利すぎるゆえに、最初からフレームワークを使ってしまうと内部の構造やロジックについても理解が不完全なままなのです。また込み入ったカスタマイズをしようとするとどうしてもフレームワークのルールから外れる書き方をする必要がでてきます。

そのため「フレームワークしか使えない」場合にはかえって生産性を落としてしまうのです。私の先輩エンジニアが言っていましたが、最初からフレームワークをやるのは四則演算が自分でできないのに計算機を使うようなものだといっていました。まさにその通りだと思います。

道具が価値を発揮するのは・・

このように便利な開発環境やソフトウェアが価値を発揮するのは今までやっていた操作をしっかり理解していたかいなかによるかと思います。

最初からIDEを使ってしまうとその内部の処理を理解すること無しに開発できてしまうため、それを理解する能力がどうしても落ちます。前述したとおり、大規模な開発をIDEなしで行うのはばかげていますが、内部の動きを理解するのにたまにはテキストエディタで開発してみるのもいいのかもしれません。

 

-Java, プログラミング全般

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

URLパターンマッピング

JavaEEではURLのマッピングについて結構悩んだんですが、サーブレットは案外簡単ですね。 web.xmlで設定することもできるようですが、アノテーションで設定することもできるようです。 例えば s …

no image

リファクタリング

業務で大幅なリファクタリングをする機会があり、その際の注意だったり、気をつけるべきことなどをまとめておきます。 自分用なので自分にしかわからない言葉で書いてある可能性が大きいです。 気になる方は問い合 …

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …

no image

Optionalについて その2

JavaEEブログなはずなのに11月はcakeのことばかり書いていて、Javaのことすら書いていないですね(汗) 今日はOptionalについて書きます。 いまいち使い方がわからなかったんですが、自分 …

no image

リーダブルコードまとめ

リーダブルコードほぼ読み切ったのでまとめを。チェックリスト化して、常にこれを見ながらコードは書いたほうがよさげ 前半のまとめや参考リンクでみたものとマージします。 Contents1 変数の名称2 コ …