Development Guidelines

Entwicklungsrichtlinien zielen darauf ab in sinnvollem Maße eine Einschränkung der Kreativität und Freiheit der Entwickler und Programmierer zu definieren mit dem Ziel dadurch einen Geschäftsmehrwert zu erzielen oder zu erhalten. 

Bestandteil von Entwicklungsrichtlinien können auch die nicht-funktionalen Anforderungen an ein System sein.

Durchsetzung

Entwicklungsrichtlinien müssen für produktive Systeme eingehalten werden, sollen für Prototypen eingehalten werden und können für PoC berücksichtigt werden. Entwicklungsrichtlinien sind als Teil der Architekturvorgaben zu behandeln, da Architektur und Entwicklungsrichtlinien einander beeinflussen. 

Zum Beispiel können Einschränkungen der zu nutzenden Programmiersprachen Teil der Entwicklungsrichtlinie sein hinsichtlich Portabilität auf andere Zielsysteme oder auch weil es schwer ist entsprechende Entwickler zu finden - Delphi, COBOL, u.s.w. Diese sinnvolle Entwicklungsrichtlinie wird im Kontext einer gelebten Enterprise Microservice-Architektur jedoch irrelevant (vgl. Nicht-Pflege von Microservices).

Im Rahmen eines PoC sollten Entwicklungsrichtlinien vernachlässigt werden, da die notwendige Kreativität durch diese ebenso wie durch Architekturvorgaben hier eingeschränkt werden. Im Rahmen von Prototypen hingegen sind Entwicklungsrichtlinien ein Soll, da Prototypen zur späteren Überführung in ein Produktionssystem entwickelt werden.

KISS

„Keep it simple, stupid!“ ist eine Richtlinie nachdem eine Komponente (oder System) so einfach wie möglich aufgebaut werden soll. KISS fasst die Gedanken einer Microservice Architektur in einem Satz zusammen, Komponenten oder Programme klein zu halten und auf die Kernaufgabe zu beschränken.

KISS unterstützt dem Grundgedanken nach auch die Agile Entwicklung, da kleine Softwareartefakte eine logische Folge des Ansatzes ist.

Im Bereich der objektorientierten Entwicklung findet KISS zu Gunsten von Abstraktion weniger Einsatz.

MinD

„Minimize Dependency“ ist eine Richtlinie mit der neben Sicherheitsaspekten insb. beim Einsatz von Fremdprodukten auch KISS unterstützt wird. MinD grenzt sich hier deutlich von dem Prinzip ab Code nur einmal zu schreiben und dann wieder zu verwenden. MinD sollte daher nicht gegenüber eigenen Entwicklungen sondern primär gegenüber Fremdentwicklungen oder ungewünschten Lizenzen von Produkten Verwendung finden. MinD als Architekturprinzip beinhaltet eine klare Abgrenzung der Systemgrenzen. In der Objektorientierung können durch entsprechende Design Pattern wie Facade das MinD Prinzip auch intern umgesetzt werden.