 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| フレームワークの設計思想を理解する | ||||||||||
|
Javaでアプリケーション開発を経験したエンジニアであれば、何かしらのフレームワークを使った経験があるだろう。現在、Javaのフレームワーク製品は、ベンダが販売しているものもあわせると相当な数になる。どの製品も、用途をあらかじめ想定して設計されている。つまり製品を理解することは、その製品の仕様を把握することと同義だといえるだろう。それは実装する時のルールであったり、拡張する時のルールであったりする。 |
||||||||||
| 導入実績、稼働実績をチェックし、評価版があれば試用して適材適所を判断する | ||||||||||
|
フレームワークには、得意分野と不得意分野がある。適用領域をあらかじめ想定して設計されているので、適材適所を考えることも大切だ。こうしたポイントは、導入実績や稼働実績から、ある程度判断できるが、評価版が提供されている場合は試用して判断すべきだろう。また製品紹介のセミナーに参加したり、個別に製品紹介の場を設けてもらうことも望ましい。 |
||||||||||
| 必要な機能の有無、カスタマイズの可否、他のフレームワークとの連携の可否を把握する | ||||||||||
|
フレームワークを選定する際は、そのフレームワークでは提供されていない機能を追加（カスタマイズ）できるか、またどのように追加作業するのかを確認する必要がある。 そして、フレームワークをカスタマイズする場合に、完璧を求めてはいけない。70点〜80点くらいでよしとするくらいの気持ちが大事だ。 フレームワークに多くの機能を持たせ過ぎると、柔軟性がなくなるばかりでなく、煩雑になり理解できなくなる恐れがある。フレームワークを利用する目的は、システム開発の生産性の向上であり、完璧なフレームワークを開発することではない。 |
||||||||||
| 「属人性のジレンマ」を考える | ||||||||||
|
読者の皆さんは、「属人性」という言葉を聞いたことがあるだろうか。 これは、ソフト開発の世界では「その開発者に依存した能力」と解釈できる。その開発者でなければ書けなかったり、メンテできないプログラムコードは「属人性が高い」となるわけだ。 属人性が高いということは、ソフト開発ではあまり歓迎されない。 そのため、属人性を低くしたり、排除するために標準化という動きがとられる。 これにより、プログラムコードの品質を一定以上に保ち、可読性を高め、メンテナンス性を向上し、結果的にシステム開発の生産性を上げることにつながる。 フレームワークの導入目的の1つにも、属人性の低減があげられる。それは言い換えると、「誰にでもできるようにすること」だ。誰にでもできるようになると、人月単価は下落する。 また、優秀な技術者にとっては、退屈な仕事になるかも知れない。すると、より高収入や能力を活かせる仕事を求めて、優秀な開発者の流出がはじまる恐れもでてくる。 だが、属人性が高いとシステム開発の生産性は向上しない。このジレンマを感じるのは私だけだろうか？ |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
-
-
連載
