In der Entwicklung ist es ja oft Gang und gebe, es zu machen, wie man es vorher auch schon gemacht hat. Typisches Beispiel für jede Anwendung wird der SQL Server genutzt, weil man ihn ja immer nutzt. Eben so passiert dies auch gerne mal bei Architekturen. Aber das ist eindeutig nicht der richtige Weg. Daher heute drei Punkte, welche man bei neuen Projekten mal bedenken sollte. Den eines für alles ist nicht immer eine gute Lösung.
Nummer 1 – Immer dieselbe Technologie
Bei den Technologien wird all zu oft auf altbewährtem gesetzt. In vielen Fällen ist dies eindeutig keine schlechte Wahl, wenn es dabei z.B. um Programmiersprachen geht oder ein Framework, welches man wirklich gut kennt. Aber auch dort sollte man nicht blind. Für manche Lösungen kann auch mal ein Blick um die Ecke gewagt werden, weil diese sich für ein bestimmtes Problem viel besser eignet. So ist es auch bei Datenbanken im .NET Bereich wird typischerweise sehr oft der SQL Server genutzt. Nur ist auch der SQL Server leider nicht für alle Lösungen perfekt. Für viele zwar, aber halt nicht für alle.
Daher bei einem neuen Projekt immer mal sehen, welche Technologien vielleicht auch in Frage kommen können und dann abwägen.
Nummer 2 – Architekturen immer wiederholen
Eine typische Architektur, welche wirklich immer gerne genutzt wird ist wohl die N-Tier Architektur. In vielen Fällen auch eine gute Wahl, aber auch hier keine Lösung für alle Fälle. Nur weil die Architektur für eine Lösung gut funktionierte, muss sie dies für ein komplett anders Problem nicht. Daher sollte man auch in der Welt der Architekturen sich mal Gedanken machen, welche den am besten zu meinem Problem passt. Gute Architekturen stellen meist viel mehr einen bestimmten Ablauf bzw. Prozess da, wo man sich dann denken das N-Tier nicht das Allheilmittel sein kann.
Daher auch hier mal ein Blick um die Ecke wagen.
<
h2>Nummer 3 – Das ganze Programm muss auf den selben basieren
<
h2>
Der dritte Punkt ist für mich so ein Thema, welches ich ein wenig aus den DDD habe. Dort wird oft der Begriff Bounded Context erwähnt. Daher Bereiche, welche unabhängig sind und auch so behandelt werden sollten. Den all zu oft werden die Nummer 1 und 2 gerne für ein ganzes Projekt genutzt. Obwohl bestimmte Teile eines Projektes durch andere Technologien oder Architekturen viel besser wären. Man verkompliziert meist so unnötig eine Menge Dinge, weil man sie dann versucht in das Muster zu bekommen. Teilweise endet es dann, wie bei den Kinderspielzeugen und das Runde würde durchs Eckige gequetscht. Keine wirklich schöne Lösung. Verschiedene Architekturen in einem Projekt sind dabei auch keine schlimme Sache bei der Kommunikation, wenn man die Schnittstellen zwischen einander stabil hat.
Daher immer gucken in welche logischen Einheiten man ein Projekt zerlegen kann. Und sich dann für jede einzelne Gedanken machen.
Fazit
In der Entwicklung wird viel zu oft wiederholt, was gut geklappt hat. Aber oft scheitert dieser Punkt, wenn die Anforderungen ganz andere sind. Daher sollte man mittlerweile auch mal ein wenig mehr aus der Reihe tanzen. Den mittlerweile gibt es so viele Möglichkeiten, welche für ein Problem viel besser sein können.
The post Nicht eines für alles bei der Entwicklung appeared first on CODE IS COOL.