=================================================
98:フレームワークを使おう（巨人の肩の上に乗ろう）
=================================================

.. maigo:: この大量のオレオレフレームワークは何？

    * 後輩W：先輩、今やってるプロジェクトでXさんと一緒に開発してるんですけど、毎日レビューしきれないPRレビューが来てとてもやってられない感じなんです。どうしたらいいんでしょう……。
    * 先輩T：レビューしきれないPRって、どういう状況でそうなったの？
    * 後輩W：今回はWeb APIのみのサーバーを開発してるんですけど、SQLをたくさん実行する必要があるので、フレームワークを使わなかったんです。
    * 先輩T：うっ、なんだか嫌な予感がする話だね。
    * 後輩W：そしたら、Xさんが「必要だから」って新しい仕組みを次々実装しているんですけど、毎日20ファイル以上差分のあるPRレビュー依頼がバンバン来るんです。でもそれを見てもなんのためにどう動くのかわからないコードの山で、どこから手をつけて良いのかわからなくて。結局レビューが間に合っていなくて、Xさん以外はわからないから誰もそのコードに手を出せないんです。
    * 先輩T：それは **オレオレフレームワーク** っていうやつじゃないかな。使い方のドキュメントは……ないよね？
    * 後輩W：ないですね。「要件に合わせて変更が必要だから、今はドキュメントを書くときじゃない」って、楽しそうに言ってました。

.. index:: オレオレフレームワーク

プログラムを書いていると、同じルールを何度も実装することがあります。
このとき、たとえばアクセス権限の確認処理があちこちで実装されているとバグが入り込みやすくなります。
こういった問題を避けるには、必要な機能を切り出して実装を1箇所にまとめる必要があります。

こういった共通化をやり過ぎて「自動的に権限をチェックするBaseViewクラスを実装してすべてのビューがクラスを継承して実装する」といったルールが作られることがあります。
これが **オレオレフレームワーク** の始まりですが、それ自体は問題ではありません。
大なり小なりどのプロジェクトにもオレオレフレームワークはありますし、Djangoのようにごく一部で使われていたフレームワークをOSS化して公開した例はたくさんあります。
問題は、公開されていて既に多くのユーザーに使われている良いフレームワークを研究せず、その劣化版を作ってしまうことです。

問題を引き起こすオレオレフレームワークは、以下の特徴を持っています。

* 同等機能を持つライブラリを研究していない
* ドキュメントやテストコードがない
* レビューされていない
* 脆弱性があり修正されていない
* DBコネクションやカーソルの解放忘れなど、リソース管理が甘い
* 昨日までの知識で安定的に使えない
* 機能実装よりもフレームワーク修正に時間がかかる

レビューされていない、あるいはレビューが困難なコードが増えていくと、書いた本人以外はコード保守ができないうえに、大量に埋め込まれた潜在的なバグが近い将来顕在化してくることが想像できます。
保守が不要な使い捨てコードであればまだしも、通常はこのような **オレオレフレームワーク** は避けるべきです。

ベストプラクティス
======================

一般的に使われているフレームワークを使いましょう。
大きなフレームワークを乗りこなすには時間がかかるかもしれませんが、独自に実装するよりもはるかに少ないコストで課題を解決できます。

.. omission::

関連
========

* :doc:`99-フレームワークの機能を知ろう`