Hier sind zunächst meine 2 Regeln zur Vermeidung des Framework-Waste-Syndroms:

• Das Fehlen eines vorhandenen, das 80% von abdeckt meine Bedürfnisse und erweiterbar, um die letzten 20%
• The Near zu entsprechen Gewissheit, dass ich es in einer anderen Anwendung wieder verwenden werde.

Nachdem Sie diese bestanden haben, überprüfen Sie Folgendes:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

Kommentare

• Ich würde hinzufügen, dass Sie, wenn Sie ‚ kein Framework finden können, das Ihrer 80/20-Regel entspricht, entweder Sie arbeiten in einer extrem einzigartigen Domain ODER Sie verstehen ‚ Ihre Domain nicht gut genug.

1) Features sollten einem Framework nur hinzugefügt werden, wenn sie aus dem Arbeitscode extrahiert werden. Mit anderen Worten, bevor Sie Ihre coole neue Idee zu Ihrem coolen neuen Framework hinzufügen, stellen Sie sicher, dass sie tatsächlich einen Mehrwert für eine funktionierende, reale Anwendung bietet und diese reduziert.

2) Dokumentation, Dokumentation, Dokumentation.

3) Dokumentation, Dokumentation, Dokumentation.

Schmerzhafte Erfahrung und viel verschwendeter Aufwand Führen Sie zu diesem Rat: Extrahieren oder überarbeiten Sie ein Framework aus funktionierender Software. Erstellen Sie diese Software unter Berücksichtigung der Tatsache, dass Sie glauben, dass Sie in Zukunft ein Framework extrahieren möchten, aber erstellen Sie das Framework nicht zuerst.

1) Halten Sie sich von Anfang an an gute Konventionen. Stellen Sie sicher, dass Sie eine sehr spezifische Konvention dokumentiert haben. Die besten Frameworks sind diejenigen, die intern konsistent sind.

2) Stellen Sie sicher, dass alles gut dokumentiert ist, von gut Codekommentare bis hin zur Erklärung, was die wichtigsten Funktionen erfordern und produzieren, auch wenn es Ihnen sehr einfach erscheint, kann es sein, dass jemand sie in der 14. Stunde in Folge verwendet und sie nur diese eine Sache benötigen genau dann.

3) Stellen Sie sich eine Projektbeschreibung zusammen, mit dem, was der Rahmen erreichen soll, realistischen Zielen und allgemeinen Prioritäten.

4) Wenn es für Benutzer verfügbar sein wird, stellen Sie sicher, dass Sie über eine Form von Supportprozess / Fehlerverfolgung verfügen. Es wird Fehler geben, das passiert uns allen, aber wenn Sie sie von Anfang an verwalten können, wird dies Ihnen das Leben erleichtern.

Alles in allem ein ähnlicher Ansatz zum Erstellen einer Anwendung. Entwickler sind jedoch noch umständlicher als Benutzer, und die besten Frameworks sind diejenigen, die wir aufnehmen können, die wir verstehen und die wir nicht kämpfen müssen.

Ich bin mit vielen Aussagen nicht einverstanden und habe das Gefühl, dass mehr nicht erwähnt wurden, sodass ich bei Null anfangen werde.

Agile Methoden

Nehmen Sie während Ihrer Framework-Entwicklung agile Methoden an, damit Sie sich an Änderungen anpassen, schnell auf Hindernisse reagieren und ein funktionales, qualitativ hochwertiges Endprodukt sicherstellen können. Agile Methoden sind solche, die gemäß dem „Agilen Manifest“ folgende Prioritäten setzen:

Einzelpersonen und Interaktionen gegenüber Prozessen und Tools
Arbeitssoftware über umfassende Dokumentation
Kundenzusammenarbeit über Vertragsverhandlung
Reaktion auf Umstellung nach einem Plan

Das ist richtig. Ich sagte, Funktionalität ist wichtiger als Dokumentation. Beachten Sie, dass im „Agilen Manifest“ erwähnt wird, dass die Prioritäten für die rechte Hand immer noch wichtig sind, nur weniger als die auf der linken Seite.

Kommunikation

Wer das Framework erstellt, muss wissen:

1. Wie es verwendet wird: die Zielanwendung
2. Welches Problem soll gelöst werden: das Zielproblem
3. Wer wird es verwenden: die Zielgruppe

Wenn ein Unternehmen beispielsweise beabsichtigt, eine endgültige Anwendung mit ASP .NET zu entwickeln, wäre es dumm, seinen Programmierern mitzuteilen, dass sie dieses Framework erstellen, ohne ihnen das oben Gesagte mitzuteilen. Wenn die Programmierer die Zielanwendung nicht kannten, machten sie sie möglicherweise nicht weborientiert. Wenn sie das Problem nicht kannten, erstellten sie möglicherweise ein Framework für einen anderen Zweck. Wenn sie die Zielgruppe nicht kennen, können sie das Framework in C ++ programmieren. Unter diesen Umständen wird das resultierende Framework unbrauchbar.

Stil

Legen Sie natürlich einen Programmierstil fest / formatieren und dabei bleiben.

Die E „s

1. Modularität : Code programmgesteuert und nicht wörtlich wiederverwenden.
2. Effizienz : Ihr Code ist für die Wiederverwendung vorgesehen . Alle Nachteile für die Geschwindigkeit werden vervielfacht.
3. Wartbarkeit : Sie möchten das Framework bearbeiten können Aktualisieren Sie mehrere Programme, ohne diese Programme ändern zu müssen.
4. Benutzerfreundlichkeit : Können Anwendungen Ihr Framework tatsächlich verwenden? ohne durch Reifen zu springen?
5. Praktikabilität : Erfinden Sie das Rad nicht neu, wenn Sie es nicht haben um dies zu tun. Ihr Framework kann von anderen Frameworks abhängen.
6. Redundanz : Ausnahmen / Fehler abfangen. Überall. Mit ihnen umgehen. Überall. Vertrauen Sie niemals einem Code im lokalen Bereich, um Fehler zu behandeln, auch wenn Sie wissen, dass dies der Fall ist.

Kommentare

• Willkommen zu P.SE! Ich ‚ bin nicht einverstanden mit # 6, Ausnahmen in Ihrem Framework abzufangen. Ich ‚ bin der festen Überzeugung, dass das Framework ein absolutes Gör sein und Ausnahmen auslösen sollte, und überlasse es dem Programmierer, das Framework zu verwenden, um sie abzufangen oder (noch besser) ihren Code so neu auszurichten um die Ausnahme zu vermeiden – Konformität mit Konventionen zu fördern.

Ich bin sicher, dass es einen Unterschied zwischen der Entwicklung eines Frameworks oder einer Bibliothek und einer Anwendung gibt.

Die Entwicklungsprozesse sind im Wesentlichen gleich Unterschiede können auf Marketing- und Bereitstellungsprobleme zurückzuführen sein, obwohl ich feststelle, dass die größten Unterschiede normalerweise in Bezug auf Projektumfang und -definition bestehen. Denken Sie daran, dass eine Anwendung ein Framework oder eine Bibliothek enthalten oder verwenden kann. Ein Framework kann eine Sammlung von Bibliotheken sein.

Ich habe einige Zweifel, wie ich mit der Organisation und Verwaltung dieses Projekts umgehen soll: Gibt es einige allgemeine Regeln für fo Low, Tipps, Best Practices oder etwas, das Sie bei der Entwicklung dieser Art von Projekten beachten sollten?

Projektorganisation und -verwaltung sind für jedes Entwicklungsprojekt wieder gleich . Wieder kommt es auf den Umfang an. Wenn es jedoch darum geht, ein Framework zu schreiben, lohnt es sich, eine sehr klare Vorstellung davon zu haben, was Sie erreichen möchten, und strenge Entwurfsregeln für die öffentliche Schnittstelle zum Framework festzulegen, um die Konsistenz in Bezug auf die APIs sicherzustellen Präsentation. Wenn Sie jedem Entwickler erlauben, sein eigenes Ding zu machen, werden Sie ein kompliziertes Durcheinander und ein sehr unelegantes API-Design haben.

Ich werde Ryan Hayes „ empfehlen , Framework Design Guidelines obwohl das Buch selbst auf die Entwicklung von .NET-basierten Frameworks abzielt, da die allgemeinen Hinweise unabhängig von den spezifischen Implementierungstechnologien gelten, die Sie möglicherweise verwenden.

Aus Erfahrung würde ich empfehlen, sich daran zu halten das klassische YAGNI-Prinzip, indem zuerst die einfachsten öffentlichen Schnittstellen implementiert und dann erweitert werden, um später mehr Kontrolle und Tiefe zu bieten. Achten Sie jedoch darauf, nützliche Namen zu verwenden, um zu zeigen, warum Methoden oder Klassen erweitert werden. Ich war noch nie ein Fan davon, Methodennamen mit „Ex“ oder ähnlichen Suffixen zu versehen oder erweiterten Schnittstellendefinitionen Zahlen hinzuzufügen. Unterscheiden Sie sich nach Funktionalität, und Ihre Schnittstellen- / Methodennamen sollten klarer und hoffentlich weniger verschleiert und verwirrend werden.