Software-Framework

Die Designer von Software-Frameworks zielen darauf ab, Software-Entwicklungen zu erleichtern, indem sie es Designern und Programmierern ermöglichen, ihre Zeit der Erfüllung von Software-Anforderungen zu widmen, anstatt sich mit den standardmäßigen Low-Level-Details der Bereitstellung eines funktionierenden Systems zu beschäftigen, wodurch die Gesamtentwicklungszeit reduziert wird. Zum Beispiel kann sich ein Team, das ein Web-Framework für die Entwicklung einer Bank-Website verwendet, auf das Schreiben von Code konzentrieren, der speziell für das Bankwesen geeignet ist, anstatt sich mit der Mechanik der Anfragebearbeitung und der Zustandsverwaltung zu befassen.

Frameworks erhöhen oft die Größe von Programmen, ein Phänomen, das als „Code Bloat“ bezeichnet wird. Aufgrund der Anforderungen der Kunden landen manchmal sowohl konkurrierende als auch ergänzende Frameworks in einem Produkt. Darüber hinaus wird die beabsichtigte Reduzierung der Gesamtentwicklungszeit aufgrund der Komplexität ihrer APIs möglicherweise nicht erreicht, da zusätzliche Zeit für das Erlernen der Verwendung des Frameworks aufgewendet werden muss; diese Kritik gilt eindeutig, wenn ein spezielles oder neues Framework zum ersten Mal von Entwicklungsmitarbeitern verwendet wird. Wenn ein solches Framework bei nachfolgenden Aufgaben nicht verwendet wird, kann die Zeit, die in das Erlernen des Frameworks investiert wird, mehr kosten als zweckgebundener Code, der den Projektmitarbeitern vertraut ist; viele Programmierer bewahren Kopien nützlicher Boilerplates für häufige Bedürfnisse auf.

Wenn jedoch ein Framework einmal erlernt wurde, können zukünftige Projekte schneller und einfacher abgeschlossen werden; das Konzept eines Frameworks ist es, eine Einheitslösung zu erstellen, und mit der Vertrautheit sollte die Codeproduktion logischerweise steigen. Über die Größe des Codes, der schließlich mit dem Ausgangsprodukt gebündelt wird, sowie über seine relative Effizienz und Prägnanz werden keine derartigen Aussagen gemacht. Die Verwendung einer Bibliothekslösung zieht zwangsläufig Extras und ungenutzte Fremdressourcen mit sich, es sei denn, die Software ist ein Compiler-Objekt-Linker, der ein enges (kleines, vollständig kontrolliertes und spezifiziertes) ausführbares Modul erstellt.

Das Thema geht weiter, aber mehr als ein Jahrzehnt Erfahrung in der Industrie hat gezeigt, dass die effektivsten Frameworks diejenigen sind, die sich aus der Neuformatierung des allgemeinen Codes des Unternehmens entwickeln, anstatt ein generisches „One-size-fits-all“-Framework zu verwenden, das von Dritten für allgemeine Zwecke entwickelt wurde. Ein Beispiel dafür wäre, wie die Benutzeroberfläche in einem Anwendungspaket wie einer Office-Suite wächst, um ein gemeinsames Aussehen, ein gemeinsames Gefühl und gemeinsame Attribute und Methoden für die gemeinsame Nutzung von Daten zu haben, wenn die einst disparaten gebündelten Anwendungen zu einer Suite vereinheitlicht werden, die enger und kleiner ist; die neuere/entwickelte Suite kann ein Produkt sein, das integrale Dienstprogramm-Bibliotheken und Benutzeroberflächen gemeinsam nutzt.

Dieser Trend in der Kontroverse bringt ein wichtiges Thema über Frameworks auf. Ein Framework zu erstellen, das elegant ist, im Gegensatz zu einem, das lediglich ein Problem löst, ist immer noch eher ein Handwerk als eine Wissenschaft. „Software-Eleganz“ impliziert Klarheit, Prägnanz und wenig Verschwendung (zusätzliche oder überflüssige Funktionalität, von der ein Großteil benutzerdefiniert ist). Für Frameworks, die Code generieren, würde „Eleganz“ zum Beispiel bedeuten, Code zu erstellen, der sauber und für einen einigermaßen sachkundigen Programmierer verständlich ist (und der daher leicht modifizierbar ist), im Gegensatz zu einem, der lediglich korrekten Code generiert. Das Problem der Eleganz ist der Grund, warum relativ wenige Software-Frameworks den Test der Zeit überstanden haben: Die besten Frameworks waren in der Lage, sich anmutig weiterzuentwickeln, während die zugrundeliegende Technologie, auf der sie gebaut wurden, sich weiterentwickelte. Selbst dort, nachdem sie sich weiterentwickelt haben, behalten viele solcher Pakete Legacy-Fähigkeiten, die die endgültige Software aufblähen, da ansonsten ersetzte Methoden parallel zu den neueren Methoden beibehalten wurden.