Softwarearchitektur: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Roth (Diskussion | Beiträge) |
Thomas (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
Den Softwareaspekt mal außen vorgelassen, so weckt der Begriff „Architektur“ doch gewisse Vorstellungen in uns. Der Architekt – hochgebildet und erfahren – plant und entwirft Bauwerke nach praktischen und ästhetischen Gesichtspunkten und überwacht die korrekte Ausführung. Doch so sehr sich die Konstruktion von Bauwerken und die von Software auf den ersten Blick ähneln mögen und so sehr sich entsprechende Metaphern aufdrängen, so gibt es doch insbesondere einen entscheidenden Unterschied: Bauwerke sind vorwiegend statisch. Es sind Immobilien (lateinisch im-mobilis ‚unbeweglich‘). Software ist ''soft'', weich, veränderbar. Und so sehr man sich auch einbilden mag, den Use Case zu kennen, allein das Wissen um diese Veränderbarkeit sorgt dafür, dass stets Bedarf für Veränderung gefunden wird. | Den Softwareaspekt mal außen vorgelassen, so weckt der Begriff „Architektur“ doch gewisse Vorstellungen in uns. Der Architekt – hochgebildet und erfahren – plant und entwirft Bauwerke nach praktischen und ästhetischen Gesichtspunkten und überwacht die korrekte Ausführung. Doch so sehr sich die Konstruktion von Bauwerken und die von Software auf den ersten Blick ähneln mögen und so sehr sich entsprechende Metaphern aufdrängen<ref>„Metaphern sind wie Lügen, nur ausschmückender.“ (Terry Pratchett: Wachen! Wachen!)</ref>, so gibt es doch insbesondere einen entscheidenden Unterschied: Bauwerke sind vorwiegend statisch. Es sind Immobilien (lateinisch im-mobilis ‚unbeweglich‘). Software ist ''soft'', weich, veränderbar. Und so sehr man sich auch einbilden mag, den Use Case zu kennen, allein das Wissen um diese Veränderbarkeit sorgt dafür, dass stets Bedarf für Veränderung gefunden wird. | ||
Dies gilt umso mehr für Entwicklung von Videospielen. Hier ist das Ziel der Spielspaß, der schwer zu messen und höchst subjektiv ist | Dies gilt umso mehr für Entwicklung von Videospielen. Hier ist das Ziel der Spielspaß, der schwer zu messen und höchst subjektiv ist. | ||
== Der Nutzen guter Architektur == | == Der Nutzen guter Architektur == | ||
| Zeile 9: | Zeile 9: | ||
* Verständnis vorhandener Funktionalität | * Verständnis vorhandener Funktionalität | ||
* Veränderungen vornehmen | * Veränderungen vornehmen | ||
* | * Alle Arten des Testens (nicht nur Unit Tests, auch manuelle Tests durch den Entwickler, Integrationstests etc.) | ||
Und eben diese Aspekte nehmen die meiste Zeit in Anspruch, je größer ein Softwareprojekt wird. Schlussendlich gilt jedoch: Der Erfolg gibt Recht. Und erfolgreich kann man mit verschiedenen Ansätzen sein.<ref>Amy Brown, Greg Wilson, editors. The Architecture of Open Source Applications. Volume I and II. 2014. https://www.aosabook.org</ref> | Und eben diese Aspekte nehmen die meiste Zeit in Anspruch, je größer ein Softwareprojekt wird. Schlussendlich gilt jedoch: Der Erfolg gibt Recht. Und erfolgreich kann man mit verschiedenen Ansätzen sein.<ref>Amy Brown, Greg Wilson, editors. The Architecture of Open Source Applications. Volume I and II. 2014. https://www.aosabook.org</ref> | ||
| Zeile 29: | Zeile 29: | ||
=== In Use Cases denken statt in Implementierungsdetails === | === In Use Cases denken statt in Implementierungsdetails === | ||
=== | === Trennung nach Funktionalität === | ||
== Besonderheiten bei der Entwicklung von Videospielen == | == Besonderheiten bei der Entwicklung von Videospielen == | ||
| Zeile 36: | Zeile 36: | ||
* Auf '''Applikationsebene''' (also der Code, der unmittelbar für das Spielgeschehen verantwortlich ist) möchte man flexibel bleiben. Hier muss es nicht immer hübsch und korrekt zugehen. Man möchte schnell herausfinden ob Dinge funktionieren und ob es Spaß macht. | * Auf '''Applikationsebene''' (also der Code, der unmittelbar für das Spielgeschehen verantwortlich ist) möchte man flexibel bleiben. Hier muss es nicht immer hübsch und korrekt zugehen. Man möchte schnell herausfinden ob Dinge funktionieren und ob es Spaß macht. | ||
* Auf Ebene der '''Engine''' | * Auf Ebene der '''Engine''' sollte Stabilität im Vordergrund stehen. Damit ist nicht zwingend gemeint, dass der Code nicht verändert wird. Vielmehr geht es um das Interface und die Funktionsweise. Niemand will schließlich, dass neue Elemente plötzlich an den Anfang statt ans Ende einer Liste gehangen werden. Mehr als sonst lohnt sich hier die Beachtung der [[CleanCode]] Prinzipien. | ||
Jedoch ist auch hier der Übergang fließend. Gerade Datenstrukturen (z.B. ein Quad-Tree) sollten definitiv so stabil wie möglich sein und entsprechender Aufwand rentiert sich durchaus. Sollten im Spiel viele verschiedene Einheitentypen vorkommen, ist die Nutzung von Design Patterns ebenfalls zu empfehlen, damit diese ohne viel Copy&Paste implementiert werden können. Einmalige Spezialfähigkeiten hingegen können auch gerne mal schnell reingepfuscht werden. Das wichtigste Clean Code Prinzip „Don‘t repeat yourself“ ([[CleanCode#Don.27t_repeat_yourself_.28DRY.29|DRY]]) darf also im Videospielbereich durchaus ab und zu ignoriert werden. | Jedoch ist auch hier der Übergang fließend. Gerade Datenstrukturen (z.B. ein Quad-Tree) sollten definitiv so stabil wie möglich sein und entsprechender Aufwand rentiert sich durchaus. Sollten im Spiel viele verschiedene Einheitentypen vorkommen, ist die Nutzung von Design Patterns ebenfalls zu empfehlen, damit diese ohne viel Copy&Paste implementiert werden können. Einmalige Spezialfähigkeiten hingegen können auch gerne mal schnell reingepfuscht werden. Das wichtigste Clean Code Prinzip „Don‘t repeat yourself“ ([[CleanCode#Don.27t_repeat_yourself_.28DRY.29|DRY]]) darf also im Videospielbereich durchaus ab und zu ignoriert werden. | ||
