既存のフレームワークを使用するよりも独自のフレームワークを構築する方が生産性が高いのはいつですか?[閉まっている]


22

会社で独自のフレームワークを構築することにした理由を知りたいと思います。

フレームワークとは、頻繁に使用するライブラリが少ないという意味ではありません。基本クラス、規約などを使用して、その上にアプリケーションを構築する特定の方法を意味します。

では、なぜ独自のフレームワークを構築したのですか?あなたを雇用している人にどうやってそれを正当化できますか。そのプラスとマイナスの影響を測定しましたか?

あなたの経験に関して、企業のフレームワークが本当のメリットを生み出したこと、あるいは開発コスト(学習曲線、デバッグ、メンテナンスなど)の増加に気づいたことはありますか?


6
決めなかった。それは一種のそれ自身を作成し​​ました...
Mchl

回答:


16

理由の答え:

  • ライセンスの問題
  • 現在のフレームワークには存在しなかった会社固有の要件
  • 会社は、フレームワークのサポートとメンテナンスを管理したいと考えています。
  • 建築家はよく知りませんでした!彼/彼女は特定のフレームワークが存在することを知らなかったので、彼らは車輪を再発明することを決めました。

更新:

企業は、「小さな」フレームワークを使用するよりも、車輪を再発明することを好みます。少々、私は不確実な未来を持っているかもしれないフレームワークに言及します。たとえば、小規模なコミュニティによって作成されたフレームワークよりも、企業にとっては.NETフレームワークの方が安全です。企業の多くのアプリケーションはビジネスに不可欠であり、長寿命であるため、セキュリティが必要です。車輪を再発明するコストは、短期的にはより多くなる可能性があります。ただし、企業のアプリケーションで使用されているフレームワークが廃止されてサポートされなくなった場合、またはライセンスが変更された場合は、コストが高くなる可能性があります。ここで、会社は現在のフレームワークを破棄し、別のフレームワークを配置する必要があります。Visual Basicは、Microsoftでサポートされなくなった言語の良い例です。そして、これは企業が新たな開発からやり直さなければならないため、数十億ドルの費用がかかります。


8

なぜ独自のものを構築するのですか?

  1. 以前にビルドされたことがないため(まれですが、それでも可能性があるため)
  2. 完全に制御したいからです。
  3. ほんの少しの機能が必要なだけなので、自分で作成する方が安くなります。

独自に構築してみませんか?

  1. あなたにはそうする時間がありません
  2. 既存のフレームワークを購入する場合、おそらくはるかに安くなります
  3. 時間を大幅に節約し、生産性を大幅に向上させることができます

7

、車輪の再発明をすることが適切であるときに私のポスト私は再実装の多くの利点をリストアップ。これらの利点は、特にフレームワークライブラリに適用されると思います。たとえば、アプリケーションのごく一部でフレームワークライブラリの使用を分離することは、多くの場合不可能です。代わりに、クライアントのソースコードの構造を決定する傾向があるため、ライブラリを完全に制御することが望ましいです。


3

車輪を再発明する唯一の本当の理由は、それがビジネスに不可欠なアプリケーションであるかどうかです。あなたの会社が来てしばらく使用する場合。このアプリケーション/フレームワーク/など。既存の商用フレームワークが提供しなければならないものを超えて進化する可能性が高いため、会社のコーダーに実装を行わせることは確かに受け入れられます。

これに対する唯一の本当の理由は次の場合です:

  1. 既存のフレームワークは適切に維持されており、タスクに完全に適合しており、将来にわたっても使用できます。

  2. これは「ここでは発明されていない」症候群の例です

  3. 現在のセットアップでは、このフレームワークを適切な時間内に適切なコストで正常に作成することはできません。

ジョエル・スポルスキーは、この件に関して非常に良い記事を書いています。「Invented Not-Invented-Here Syndrome」


2

基本的に、他の人の作品を使用する場合、それらを目に見えない雇用主または「余分な手」として追加します。

彼らが良ければ彼らはあなたを助けます。そうでない場合、あなたはあなた自身の仕事に加えて彼らの仕事をしなければなりません-言い換えれば彼らのコードを維持します。これは受け入れられないリスクかもしれませんが、私はそれを非常にまれだと考えています。

キーワードは、インターフェイスにコーディングすることにより、フレームワークをスワップ可能にすることです。Javaの世界で最も厳格なインターフェースはSun仕様であり、これはサーブレットAPIによって証明されています。

その場合、フレームワークを使用しない理由はないと考えます。


1
どのフレームワークを採用する場合でも、開発プロセスを見ると役立ちます。強力なコミュニティとオープンプロセスを備えたフレームワークは、特にソースコードが付属している場合、ユーザーが進行中のすべてを確認し、それに影響を与える票を投じることができるため、リスクは低くなります)。その場合、フレームワークの周りに追加のラッパーを開発する必要はありません。
ジョーリSebrechts

2

私が働いている場所には、かなり成熟したフレームワークがあります。Foundations Frameworkの概要は次のとおりです

それを使用する主な理由の1つは安定性です。マイクロソフトや、年々新しい機能や複雑さを追加するように駆り立てられている他のサプライヤを期待していません。

(雇用主などの見解ではなく、私自身の見解)


2

既存のフレームワークでカバーされていない要件を満たすために、それを数回行いました(当時)。

ほとんどの場合、これらの自作のフレームワークは、新しい完全に開発されたフレームワークによって後で削除されました。たとえば、2000年に、Railsに匹敵するJava Webフレームワークを作成しました。これを使用して、いくつかの整理されたフォームを持つ複雑な注文入力システムを作成しました。それはうまく機能しましたが、もちろん、数年後、StrutsやJSFなどのより成熟したフレームワークによって廃止されました。しかし、当時、それは正しいことであり、うまく機能し、開発速度は印象的でした。

私が開発した別のフレームワークはまだ使用中です(また、積極的に開発されています)。最初のバージョンは2004年に作成されました。これは主に物流内アプリケーションに使用されます。それを使用する会社はまだそれを際立った機能と見なしています。これを作成する主な理由は、モバイルバーコードスキャナー用のデータベース接続アプリケーションを簡単に作成できるようにすることです(Windows CEの一部を実行しています)。それは非常にうまく機能したため、上司はPCソフトウェアにも同じ概念を使用することにしましたが、それでも満足しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.