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.