こういう共通ライブラリは要らない

  • 3
    いいね
  • 1
    コメント
この記事は最終更新日から1年以上が経過しています。

はじめに

プロジェクトでアプリを開発する場合、よほど小規模でない限り「共通ライブラリ」とか「フレームワーク」とか呼ばれるものを使います。ここで言うライブラリとは、汎用的なものをそのまま使うのではなく、そのアプリケーションに合わせて作られたものです。

例えば、.NET のプロジェクトで画面は Form クラスから派生させますが、とあるプロジェクトではカスタマイズされた 「CustForm から派生させて作りなさい」みたいな感じです。

問題になるケース

こういう共通ライブラリのできが悪いと、しばしば問題が大きくなります。例えば、

  • 共通ライブラリにバグが見つかり、デグレード確認のため再テストが必要になった。
  • まともなドキュメントがないため、アプリの開発に時間がかかり支障が出ている。
  • サンプルがない(少ない)ため、使い方がわからない。
  • 設計思想が統一されていないため、モジュールにより使い方が変わる。
  • 細々とした処理までアプリ側で書く必要がある。
  • 予定ではアプリ開発までに完成するはずであったが、まだデバッグをしている。
  • ライブラリとアプリの開発元が異なるため、得意先経由でしか問い合わせができない。
  • ライブラリ(フレームワーク)の動作要件が多すぎて、テスト環境が作れない(作りづらい)。
  • 起動に時間がかかりテストに支障が出ている。
  • 動作不良の原因がアプリ側なのか、フレームワーク側なのか判別が難しい。

結局・・・

上の例のような共通ライブラリやフレームワークによりプロジェクトの足が引っ張られることってよくあります。結局、どうすればいいかなんてここまでくればわかるでしょうが、あえて書くなら

  • リリースまでに十分なテストを行って、高い信頼性を確保する。
  • ドキュメントやサンプルはわかりやすく、しっかり作る。
  • シンプルでコンパクトであることに心がける。
  • アプリ側のテストがしやすいように。
  • 不具合が発生したときの切り分けをどうするのか考える。

原文 ..
たまに著作権を気にする人がいるのでひと言。「この投稿と著作者は同じです。」