書くか書かないか：フレームワーク[終了]

今日、何人かの友人と私はフレームワークについて話し始めました。

私たちの一部は、99.9％のケースで、新しいフレームワークを作成することは悪い考えであると強く信じています。おそらく、数百万のフレームワークのうちのいくつかは問題に適合するはずであり、そうでない場合は、ハック、API、または構成で十分なはずです。そうでない場合は、フレームワークへの貢献、機能の提案などが最善の解決策であると考えています。0.1％は、どのフレームワークも私たちのケースに適合しない場合です。

ただし、問題を修正するのがより速く、「学習」の要素（アプリを改善するとフレームワークを構築するあなたのスキル）など

明日がないようなコーディングフレームワークを外に出すのは正しい方法ではないと思います。「私たちは独自のフレームワークを構築し、私たちが支配し、仲間」という言葉を広めるためだけに、多くの小さなチームが独自のフレームワークを構築するのを見てきました。一般に、フレームワークはくだらないものであり、ドキュメントがなく、独自のアプリケーションでのみ機能します。

意見は意見であり、開発者は開発者であり、いかなる炎の戦争を開始する意図もありません、と私は尋ねます：

あれについてどう思う？フレームワークを構築するときに考慮するパラメーターは何ですか？このすべてについてどう思いますか？

私はGrandmasterBとは反対側にいます。私にとって、これは購入対構築の問題です。

私の観点からは、私の時間と労力はコストで表すことができます。では、フレームワークを構築するのに十分な投資収益率がある場合、問題はどうなるでしょうか。（私がクライアントのために働いているなら、クライアントの視点からこれらの質問について考えます。）

ここに私が自問する質問があります：

• フレームワークはすでに存在していますか？
• このフレームワークを構築した場合、これは知られていたいものですか？つまり、このフレームワークは私にとって差別化要因ですか？

多くの場合、私は2番目の質問に対する答えがノーだとわかります。私は今、ヘルスケア会社で働いています。彼らは最善のスケジューリングエンジンの開発者として知られることを望んでいません。私はそのフレームワークの開発と保守を外部委託すべきです。

ただし、価格設定エンジンについて話している場合、それは会社のパンとバターであ​​るため、私は間違いなく優れたエンジンの作成に私のエネルギーを集中する必要があります。

私の一般的なルールは、その製品または製品の重要な部分である場合は、可能な限り自分で作成することです。コア機能ではない場合、またはビジネス（社内でのみ使用されるもの）をサポートしている場合は、フレームワークを変更します。

私が行うアプリケーションの多くは、10年以上、おそらく-長期的な投資であり、それらは顧客に販売されている製品です（したがって、私の責任です）。したがって、サードパーティのフレームワークを使用して「すばやく」始めることができるのは、1年に数十のアプリを作っている人にとっては、私にとってそれほど重要ではありません。ですから、私は一般的に、骨の折れるものに飛び込んで自分で作ることに反対していません。製品の有効期間中、カスタムフレームワーク/コンポーネントを取得するための追加の数週間はそれほど重要ではありません。しかし、それはアプリケーション用に特別に設計されているため、頭痛とレンガの壁がはるかに少ないことを意味します。

フレームワークはライブラリのコレクションであるように私には思えます。それらがたくさんあり、それらが一貫したAPIを持っていることを確認し、うまく連携したら、それらをバンドルしてフレームワークと呼びます。ただし、Fワードを使用するかどうかに関係なく、会社のすべてのライブラリに一貫したAPIがあることを確認する必要があります。

フレームワークは、誰かが自分が持っているすべてのものを見て「うーん、この一連のものは他の人に役立つ可能性がある」と言うと「誤って」書かれる傾向があります。これは、ソースを出荷する会社である場合、またはフレームワークを作成するよう明示的に要求された場合を除きます。何かをするために何かをすることは、プログラミングでは常に悪い考えです。

何をする場合でも、特に四角形のように、ホイールを再発明していないことを確認してください。

私のような場合、あなたの仕事は、ペットプロジェクトのデバッグや調整ではなく、可能な限り効率的にビジネス価値を提供することです。広く使用されているフレームワークで必要なことを実行する場合は、時間を無駄にしないでください。広く受け入れられているフレームワークは、おそらくあなたができるよりも優れています。彼らには、それを開発するためのより多くの時間、経験、リソースがありました。

過去6か月間、私の会社では最近、多くの類似したことを行う2つの異なるアプリケーションを作成するよう求められました。最近、3つ目の類似のアプリケーションを作成するように依頼されましたが、将来、より類似したアプリケーションを作成する余地がたくさんあります。私が使用している独自技術のフレームワークを誰も開発していないので、私は自分のフレームワークを開発するしかありませんでした。私が自分のフレームワークを開発しないと、自分自身を繰り返すことに多くの時間を費やし、それは時間とお金の無駄になります。

これは、自分で構築する価値があるのか​​、他の誰かを使用する価値があるのか​​についての鍵だと思います。今後数年間で大量の現金を浪費するか、フレームワークを構築する必要がある場合は、フレームワークを構築します。

最初に何かを構築せずに理想的なフレームワークがどのように見えるかを正確に予測することは非常に困難です。収穫されたソリューションは、一般的に、より良いよりも基盤ソリューション（リンクの感謝caarlos0あなたのコードは、上に構築されていないため、）推測クライアントプログラマが望んでいるものについては、実際の経験。読む：創発デザイン。

とはいえ、自分のフレームワークを構築する理由は1つだけあります。同じ作業を2回実行し、おそらくさらに数回実行する予定で、だれもあなたのために作業を実行していない場合です。

新しいプロジェクトで利用可能なフレームワークとツールを最大限に活用するようにしています。プロジェクトが進化した後、おそらく1〜2年で焼き付き、次に最も痛みを引き起こすフレームワークの部分を置き換えることは合理的な選択です。あなたのビジネス計画が新しいフレームワークの作成を中心としない限り、私はあなた自身のものを書くつもりはありません。

ある技術が本当に失敗したとき、私は特定の苦情とそれをよりよく機能させるためにどのように再設計すべきかについてのアイデアのリストを保管しています。短期的には、この「マニフェスト」は、既存のフレームワークを使用しながら、私が欲求不満の出口を与えてくれます。中期的には、マイナーな問題を修正するエネルギーを無駄にしないように、最悪の問題点を特定するのに役立ちます。長期的には、マニフェストは部分的または完全な置き換えのデザイン、または新しいフレームワークを選択するための機能リストになる可能性があります。