Als PDF, PPTX herunterladen
Hochgeladen vonStephan Volmer
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013
Das Dokument diskutiert die Einführung einer einheitlichen Architektur für vielfältige Anwendungen, wobei ein bottom-up-Ansatz empfohlen wird, um die Herausforderungen der Wiederverwendbarkeit von Code zu bewältigen. Es wird betont, dass reusable Code kostenaufwändig ist und strategische Planung sowie Schulung der Mitarbeiter erfordert, um langfristige Effizienz zu erreichen. Die Autoren plädieren für pragmatische Prinzipien und kontinuierliche Investitionen in Ausbildung, um die Zusammenarbeit zu fördern und die Entwicklungszeit zu verkürzen.
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfältigen Anwendungen lebt - Vortrag TeamConf 27.11.2013
- 1. Bottom-up anstatt Top-down Wie maneine einheitliche Architektur bei vielfältigen Anwendungen lebt Markus Rehrs @spontifixus Dr. Stephan Volmer @stvzeg
- 2. Eigentlich nichts Neues Aufgabe Einführungeiner einheitlichen Architektur für vielfältige Line-of-Business Anwendungen: • • Datenbank ist die zentrale Komponente • Hohe Test- und Integrationsaufwände • Development und Operations sind organisatorisch getrennte Einheiten • Hoher Anteil von externen Mitarbeitern • Heterogener Technologiestack • IMG_1080.jpg by Tom Page http://www.flickr.com/photos/tompagenet/6851860996/ Datengetriebene Anwendungen Entwickler erfinden das Rad immer wieder aufs Neue
- 3. Die vermeintliche Logik Reuse “Ifwe were to write all the code of a software, we would write a certain amount of code.” “If we could reuse some code from somewhere else that was written before, we could write less code.” “The more code we can reuse, the less code we write.” “The less code we write, the sooner we will be done.” “Get done faster!” Don't forget to recycle! by James Wang http://www.flickr.com/photos/10037058@N08/3696670712/
- 4. Die Realität siehtanders aus… Reuse “There is the time it takes to specify what the software should do.” “Multiply that by the time it takes to understand what the software should do.” “There is the time it takes to write the code.” “Multiply that by the time it takes to integrate with all other code, libraries, components, frameworks, databases, services, …” Debugging! Deploying! Testing! Stabilizing! Workshops! Meetings! Abandoned Boat by William Warby http://www.flickr.com/photos/wwarby/4859138371/
- 5. Aus der Krisein den Aufschwung? Reuse Frameworks Patterns OSS Libraries 2000 3GL 2010 1990 SOA 1980 1970 Software Crisis OOP Components
- 6. Reuse Irrtümer, Fakten undKonsequenzen “Writing code is the primary activity in getting a system done! “All code takes the same amount to write!” “If we just reused more code, everything would be better.“ “Code by itself is reusable anyway.” “In order to be reused, code must be generic, flexible, and replaceable.” “Code must be specifically designed for reuse!” “Reusable code is well over-engineered!” Shiny gold bar reflecting coins by Bullion Vault http://www.flickr.com/photos/bullionvault/3591732069/
- 7. Reuse Kosten und Nutzen KannIhr Unternehmen sich wiederverwendbaren Quellcode leisten? “Developing reusable code costs three times as much as single use code” The Mythical Man Month and Other Essays on Software Engineering, Frederick P. Brooks Jr. “Development teams which write reusable code waste their organizations a lot of time and money. Please pay this amount by miguelb http://www.flickr.com/photos/mig/8689212/ Reuse Myth - Can You Afford Reusable Code? Allen Kelly
- 8. „Was tun?“ sprichtZeus Reuse ? Should we not reuse? • There are genuine situations were reuse is the right answer. ! Look back, not forward! • • Bottom-up instead of top-down! • Rear view mirror by a.dombrowski http://www.flickr.com/photos/adombrowski/5285377223/ Don’t plan for reuse, but look for opportunities! Simplicity before generality!
- 9. Reuse Schwarz oder Weiß? JedesProjekt wählt Architektur und Technologie unabhängig von der umgebenden ITLandschaft. chess set by Ekkehard Streit http://www.flickr.com/photos/ekkionline/8846737835/
- 10. Reuse Schwarz oder Weiß? EinFramework-Projekt verschlingt viele Ressourcen ohnen einen direkten Mehrwert zu liefern. chess set by Ekkehard Streit http://www.flickr.com/photos/ekkionline/8846737835/
- 11. GALAP Bottom-Up APET Wilhelmine Wulff /pixelio.de MAYA DRY KISS Eine pragmatische Herangehensweise
- 12. Libraries und Templates Artefacts Quellcode EigeneVisualStudio Solution NuGet-Pakete zur Einbindung externer Komponenten NuGet-Pakete Klar umrissene Funktionalität Bereitstellung externer Komponenten über eigene Pakete VisualStudio-Templates Project-Template für die Applikation Item-Templates für die einzelnen Komponenten
- 13.
- 14. Artefacts Beispiele und BestPractices Beispielapplikation Produktive Applikationen Code Snippets
- 15. Ein Freies Elektron Process Team1 Team 4 Senior Developer Team 3 Team 2
- 16. Entwicklung mit Rückenwind Process Projekt1 Projekt 4 Blueprint Projekt 3 Projekt 2
- 17.
- 18. Semantische Versionierung Process Major Minor Revision • Breaking Changes • Keine Breaking Changes • KeineBreaking Changes • Wesentliche Veränderungen • Neue Features • • Alte Versionen werden weiter unterstützt Bugfixes und kleinere Features
- 19.
- 20.
- 21. Tools Entwicklungsumgebung Entwicklungsumgebung und Versionsverwaltung LokalesNuGet-Repository IDE Extensions von Drittanbietern und Eigenentwicklungen Tools zur statischen Codeanalyse
- 22.
- 23. Ein Basis-Check vordem Start Zeit Geld Wille Eignung geprüft
- 24. Wo ein Willeist... Ich möchte lernen wie ich effektiver und effizenter arbeiten kann! ...ist auch ein Unwilliger Ich hab das schon immer so gemacht!
- 25. Wo ein Willeist... Ich möchte lernen wie ich effektiver und effizenter arbeiten kann! ...ist auch ein Weg Ihr hat mich überzeugt! Da bin ich dabei!
- 26.
- 27. Thomas Alva Edison “Ireadily absorb ideas from every source, frequently starting where the last person left off.” Library of Congress, Digital ID: cph.3c05139
- 28. Das Vorgehen Am Anfangsteht ein Inkubatorprojekt Inkubator Inkubator Blueprint Projekt B
- 29. Das Vorgehen Generalize asLate as Possible Projekt Inkubator.Next Inkubator Blueprint Projekt B Projekt B
- 30. Aus Erfahrung gut! Conclusions • Startemit einem echten Projekt: Bottom-up anstatt Top-down funktioniert wirklich! • Plane kein Framework: Es entsteht im Laufe der Zeit von selbst! • Halte Dich an Prinzipien: Aber: Pragmatismus anstelle von Religion! • Setze Ziele jenseits eines Projektes: Die Kollegen werden lernen über den Tellerrand zu schauen! • Investiere in Ausbildung, nicht in Code: Das Know-How der Mitarbeiter ist bares Geld wert!
- 31. Langer Atem zahltsich aus Conclusions • Ein Framework ist nicht kostenlos: Ohne kontinuierliches Budget für das “freie Elektron” läuft das Framework Gefahr ins Koma zu fallen. • Unmittelbarer Return on Invest: Die Ramp-Up-Zeit für neue Projekte reduziert sich von fünf Monaten auf fünf Minuten! • Projektkosten sind besser planbar: Die Entwickler können sich auf die Implementierung der fachlichen Anforderungen konzentrieren. Achtung: Erfolg nicht ausgeschlossen!
- 32. Markus Rehrs markus.rehrs@zuehlke.com xing.to/mrehrs twitter @spontifixus Dr.Stephan Volmer stephan.volmer@zuehlke.com xing.to/stv twitter @stvzeg