#はじめに
プロジェクトでアプリを開発する場合、よほど小規模でない限り「共通ライブラリ」とか「フレームワーク」とか呼ばれるものを使います。ここで言うライブラリとは、汎用的なものをそのまま使うのではなく、そのアプリケーションに合わせて作られたものです。
例えば、.NET のプロジェクトで画面は Form クラスから派生させますが、とあるプロジェクトではカスタマイズされた 「CustForm から派生させて作りなさい」みたいな感じです。
#問題になるケース
こういう共通ライブラリのできが悪いと、しばしば問題が大きくなります。例えば、
- 共通ライブラリにバグが見つかり、デグレード確認のため再テストが必要になった。
- まともなドキュメントがないため、アプリの開発に時間がかかり支障が出ている。
- サンプルがない(少ない)ため、使い方がわからない。
- 設計思想が統一されていないため、モジュールにより使い方が変わる。
- 細々とした処理までアプリ側で書く必要がある。
- 予定ではアプリ開発までに完成するはずであったが、まだデバッグをしている。
- ライブラリとアプリの開発元が異なるため、得意先経由でしか問い合わせができない。
- ライブラリ(フレームワーク)の動作要件が多すぎて、テスト環境が作れない(作りづらい)。
- 起動に時間がかかりテストに支障が出ている。
- 動作不良の原因がアプリ側なのか、フレームワーク側なのか判別が難しい。
#結局・・・
上の例のような共通ライブラリやフレームワークによりプロジェクトの足が引っ張られることってよくあります。結局、どうすればいいかなんてここまでくればわかるでしょうが、あえて書くなら
- リリースまでに十分なテストを行って、高い信頼性を確保する。
- ドキュメントやサンプルはわかりやすく、しっかり作る。
- シンプルでコンパクトであることに心がける。
- アプリ側のテストがしやすいように。
- 不具合が発生したときの切り分けをどうするのか考える。
原文 ..
たまに著作権を気にする人がいるのでひと言。「この投稿と著作者は同じです。」