スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

開発の生産性とは

よくこの言語を使うと、あるいはこのフレームワークを使うと、従来よりも生産性が10倍上がるなどという。しかし、何を元にそう言っているのか。10倍というアバウトな数字は単なる宣伝文句に過ぎないとしても、そううたうからには実際に少なくとも数倍の速度で開発が進まないといけない。

RailsがJavaよりも速く作れるといったとき、細かく条件を見ていく必要があるだろう。JavaでもIDEを使う場合と使わない場合ではかなり違いがある。それから一体何を作るのかでも変わってくる。

第一に、開発対象・規模がどういうものか。業務系か制御系か、大規模か小規模か。そういった条件をつける必要があるだろう。

それから、開発のプロセスに入ったとき、かかる時間として考慮すべきものは以下のものがある。

・初期学習
 たいていの場合いきなり何も知らずに開発に入るのではなく、ある程度学んでから入る。ここでどれだけの時間がかかるか。簡単に習得できるかどうか。これは入門書やマニュアルがどれだけわかりやすく、適切かによっても違ってくる。

・調査
 先ほどのは最初の段階の学習。実際どんなに上級のプログラマでも何もかも知ってから開発に取り掛かるわけではない。基本をマスターしたら後は実践の中で深めていく。ある課題をどのように解決するか、エラーが発生したときにどう対処するか。このとき調査にどれだけ時間がかかるかである。これは、マニュアルがしっかりしているか、GoogleでのHit率がどのくらいか、トラブルシューティングの情報があるか、FAQや掲示板で調べられるかなどで違ってくる。

・環境構築
 一番最初に躓くのは環境構築だ。通常一人だと一回で済むからそれほど大きな要因ではないが、規模が大きい、あるいはTest環境構築など頻繁に行う場合、これが複雑だと生産性を下げる。

・開発環境
 IDE、Plugin、Toolがどれだけ充実しているかで生産性は変わってくる。

・記述
 1.短く記述できること
  それを実現するために必要な情報だけ記述すればよいこと。DRY(Dont Repeat Yourself)の原則が保たれていれば、より記述量は少なくなる。
  第一に、言語レベルで短く記述できるかどうか。Javaの1.4まではループの記述は面倒だった。それに比べてrubyだと簡潔に書ける。またメソッドの長さもrubyだとpとかto_sとかで済む。ただしこれはIDEを使っていたり、タイピングの問題なのでさほど大きな差が出るとは思えない。また言語に継承が使えれば記述を短くできる。
  またライブラリやフレームワークで予め機能が用意されているかどうか。予めその機能が使えるAPIがあれば自分で組む必要がないので記述は短く済む。少なくともありがちなもの、使いそうなものはすべて最初からあるのがよい。
 またそのライブラリやフレームワークを使うとき、記述の少なく、重複が少ないほどよい。これは例えばEJBなどを使った場合、そのまま教科書どおりにやると同じような記述を散々書かないといけない。XDocletを使うと便利だというが、もともと無駄で余計でロジックのかけらもない記述をさせて生産性を下げていたのを0に戻しただけで生産性がプラスになったわけではない。

 2.わかりやすい
  わかりやすいソースがかけるほど、デバッグ・メンテナンスは楽となり、これは生産性に直結する。これは属人的な要素となり、メンバーがわかりやすく書くようにすればいいことだが、JavaではCに比べて複雑な書き方ができないし、また一般的にオブジェクト指向言語の方がわかりやすく記述できる。またフレームワークで形の強制ができればソースはわかりやすくなる。

 3.応用度
  硬いフレームワークだと例外的な処理を書こうとするとかなり厄介で時間をとられる。そういったことがないように柔軟にかつ簡明に対応できるかどうかも生産性にかかわってくる。

少なくとも、こういう要素を考慮して、それぞれを一つ一つ比較・対照して、その結果このフレームワークの方がどれだけ生産性が高いなどと言うべきだ。
こういった要素の検討が生産性を測るメトリックスとなると思う。そういうふうにして各言語・フレームワークを比較できたら面白いと思う。

最も生産性というのに近いのは、記述の短さだと思う。
要求定義に記載する情報だけをソースに書けばよい、というのが最も短い記述になる(要求定義が整理されている場合)。それが究極のフレームワークが目指すところだろう。
DBの定義があれば、あとは勝手に一覧・登録・更新・削除画面が生成される。RoRではあと、Validationも自動化してくれればいいのだが。RoRのscaffoldは最初に習う分にはよいが、実際あのままでは使えないので、もっと細かくテンプレートが用意されているといいと思う。

そのためには、画面設計をパターン化する。これは画面のデザインパターンではなく、画面遷移のパターンだ。画面遷移では、一覧⇒変更⇒一覧となったり、一覧⇒変更⇒確認⇒完了⇒一覧となったり、いろいろパターンがある。こういったシーケンス等を研究する分野があってもいいと思う。

関連記事
スポンサーサイト

コメント

非公開コメント

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。