Wann ist es produktiver, ein eigenes Framework zu erstellen, als ein vorhandenes zu verwenden? [geschlossen]

Ich würde gerne wissen, warum Sie sich dazu entschlossen haben, in Ihrem Unternehmen ein eigenes Framework aufzubauen.

Mit Framework meine ich nicht wenige Bibliotheken, die Sie häufig verwenden. Ich meine eine bestimmte Art, Anwendungen darüber zu erstellen, mit Basisklassen, Konventionen usw.

Also , warum haben Sie Ihren eigenen Rahmen gebaut? Wie könnten Sie das der Person rechtfertigen, die Sie anstellt? Haben Sie die positiven und negativen Auswirkungen davon gemessen?

Haben Sie in Bezug auf Ihre Erfahrungen bemerkt, dass ein Unternehmens-Framework in einigen Fällen echte Vorteile erbrachte oder andererseits die Entwicklungskosten erhöhte (Lernkurve, Debugging, Wartung, ...)?

Antwort auf den Grund:

• Lizenzprobleme
• Unternehmensspezifische Anforderungen, die in aktuellen Frameworks nicht vorhanden waren
• Das Unternehmen möchte die Kontrolle über die Unterstützung und Wartung des Frameworks haben
• Der Architekt wusste es nicht besser! Er / sie wusste nicht, dass es einen spezifischen Rahmen gibt, und beschloss, das Rad neu zu erfinden.

Aktualisieren:

Unternehmen ziehen es vor, das Rad neu zu erfinden, anstatt "kleine" Frameworks zu verwenden. Im Kleinen beziehe ich mich auf einen Rahmen, der eine ungewisse Zukunft haben könnte. Zum Beispiel ist .NET Framework sicherer für Unternehmen als ein Framework, das von einer kleinen Community erstellt wurde. Unternehmen benötigen Sicherheit, da viele ihrer Anwendungen geschäftskritisch sind und eine lange Lebensdauer haben. Die Kosten für die Neuerfindung des Rades können kurzfristiger sein. Die Kosten können jedoch höher sein, wenn das in der Unternehmensanwendung verwendete Framework veraltet ist und nicht mehr unterstützt wird oder Lizenzen geändert werden. Hier muss das Unternehmen möglicherweise das derzeitige Framework verwerfen und ein anderes einfügen. Visual Basic ist ein gutes Beispiel für eine Sprache, die von Microsoft nicht mehr unterstützt wird. Und das kostet Unternehmen Milliarden, da sie mit der Neuentwicklung neu anfangen müssen.

Warum bauen Sie Ihre eigenen?

1. weil es noch nie gebaut wurde (selten, aber eine Möglichkeit)
2. weil du die volle Kontrolle haben willst.
3. weil Sie nur ein bisschen Funktionalität brauchen, damit es billiger ist, es selbst zu bauen

Warum nicht selbst bauen?

1. Sie haben nicht die Zeit dazu
2. Es ist wahrscheinlich viel billiger, wenn Sie ein vorhandenes Framework kaufen
3. Sie sparen viel Zeit und können viel schneller produktiv werden

In meinem Beitrag über die Frage, wann es angebracht ist, das Rad neu zu erfinden, führe ich eine Reihe von Vorteilen einer Neuimplementierung auf. Ich denke, diese Vorteile gelten insbesondere für Framework-Bibliotheken. Beispielsweise ist es häufig unmöglich, die Verwendung einer Framework-Bibliothek in einem kleinen Teil Ihrer Anwendung zu isolieren. Stattdessen bestimmen sie in der Regel die Struktur des Client-Quellcodes. Daher ist es wünschenswert, die vollständige Kontrolle über die Bibliothek zu haben.

Der einzige wirkliche Grund, das Rad neu zu erfinden, ist, wenn es sich um eine geschäftskritische Anwendung handelt. Wenn Ihr Unternehmen noch einige Zeit in Anspruch nehmen wird. Wenn diese Anwendungen / Framework / etc. wird sich wahrscheinlich weiterentwickeln, als es die bestehenden kommerziellen Rahmenbedingungen bieten, dann ist es mit Sicherheit akzeptabel, dass die Codierer der Unternehmen ihre Implementierung vornehmen.

Die einzigen wirklichen Gründe dafür sind, wenn:

1. Das vorhandene Framework ist gut gepflegt, passt perfekt zu Ihrer Aufgabe und wird es auch in Zukunft tun.

2. Dies ist nur ein Fall von " Not Invented Here " -Syndrom

3. Ihr aktuelles Setup ist nicht in der Lage, dieses Framework in angemessener Zeit und zu angemessenen Kosten erfolgreich zu erstellen.

Joel Spolsky hat einen sehr guten Artikel zu diesem Thema geschrieben: In Defense of Not-Invented-Here Syndrome

Wenn Sie die Arbeit anderer verwenden, fügen Sie sie im Allgemeinen als unsichtbare Arbeitgeber oder "zusätzliche Hände" hinzu.

Wenn sie gut sind, werden sie dir helfen. Wenn nicht, müssen Sie ihre Arbeit zusätzlich zu Ihrer eigenen erledigen - mit anderen Worten, Sie müssen ihren Code beibehalten. Dies mag ein inakzeptables Risiko sein, aber ich würde es als sehr selten betrachten.

Das Schlüsselwort besteht darin, das Framework austauschbar zu machen, indem es in eine Schnittstelle codiert wird. Die starrsten Schnittstellen in der Java-Welt sind die Sun-Spezifikationen, die von der Servlet-API bewiesen werden.

Dann würde ich keinen Grund dafür sehen, kein Framework zu verwenden.

Wir haben ein ziemlich ausgereiftes Framework, in dem ich arbeite. Hier ist eine Zusammenfassung des Foundations Frameworks

Einer der Hauptgründe für die Verwendung ist die Stabilität. Wir sind weder Microsoft noch anderen Anbietern verpflichtet, Jahr für Jahr neue Funktionen und Komplexität hinzuzufügen.

(Meine eigenen Ansichten, nicht die meines Arbeitgebers usw. usw.)

Ich habe das mehrmals gemacht, um Anforderungen zu erfüllen, die (damals) noch nicht durch bestehende Frameworks abgedeckt waren.

In den meisten Fällen wurden diese einheimischen Frameworks später durch neuere, ausgewachsene Frameworks entfernt. Zum Beispiel habe ich im Jahr 2000 ein Java-Webframework erstellt, das in einigen Aspekten mit Rails vergleichbar ist und dazu dient, ein komplexes Auftragserfassungssystem mit mehreren hundert Formularen zu erstellen. Es hat gut funktioniert, aber natürlich haben einige Jahre später ausgereiftere Frameworks wie Struts und JSF es obsolet gemacht. Aber damals war es das Richtige, es hat gut funktioniert und die Entwicklungsgeschwindigkeit war beeindruckend.

Ein anderes Framework, das ich entwickelt habe, wird noch verwendet (und auch in der aktiven Entwicklung). Die erste Version wurde im Jahr 2004 geschrieben. Diese wird hauptsächlich für Intralogistik-Anwendungen verwendet. das Unternehmen, das es verwendet, sieht es immer noch als Unterscheidungsmerkmal. Der Hauptgrund für die Erstellung war, die Erstellung datenbankgebundener Anwendungen für mobile Barcodescanner zu vereinfachen (mit einer gewissen Windows CE-Version). es hat so gut geklappt, dass die Chefs beschlossen, dasselbe Konzept auch für die PC-Software zu verwenden, und nun, sie sind immer noch damit zufrieden.