Category: Development

Daily Sharp, DevelopmentLeave a comment

Codegenerierung aus Modeling Projects – Part 3

Michael (Mike) Kaufmann

In Part 1 und Part 2 der Serie habe ich schon die Generierung von Code aus Visual Studio Modeling Projects und die Anpassung der T4-Templates beschrieben. In diesem Teil geht es um die Erstellung eines eigenen “Profiles” mit neuen Stereotypen. Ein eigenes Profile muss als Visual Studio Extension (.vsix) erstellt werden. Dazu ist das Visual Studio SDK nötig. Ist dieses installiert, dann kann über den Dialog “Neues Projekt” eine neues “Visual Studio Package” erstellt werden. Die Angaben in Wizzard sind eigentlich selbsterklärend. Da das Paket nur als Container benötigt wird, können fast alle Optionen deaktiviert werde. Dem Projekt muss man … Continue reading Codegenerierung aus Modeling Projects – Part 3

Daily Sharp, Development1 Comment

Codegenerierung aus Modeling Projects – Part 2

Michael (Mike) Kaufmann

In Part 1 der Serie habe die Grundlagen der Generierung von Code in Class-Diagrammen in Modeling Projects beschrieben. In diesem Teil geht es um die Verwendung von unterschiedlichen T4-Templates und deren Anpassung. Die Auswahl der T4-Templates erfolgt über die Eigenschaft “Text Template Bindings”. Hier werden bei der ersten Generierung Standardtemplates für Class, Enum, Interface und Struct hinterlegt. Die Templates haben folgende Eigenschaften: Titel Beschreibung Name Name des Templates Overwrite Gibt an ob die Zieldateien überschrieben werden. ProjectPath Name des VS-Zielprojektes. Ist das Projekt nicht vorhanden, dann wird es erstellt. Hier sollte man immer das Projekt ändern, da der Standard <name_model_project>Lib.csproj … Continue reading Codegenerierung aus Modeling Projects – Part 2

Daily Sharp, Development1 Comment

Codegenerierung aus Modeling Projects – Part 1

Michael (Mike) Kaufmann

Visual Studio unterstützt die Generierung von Code aus einem Modeling Project heraus. Dabei kommen t4 Templates zum Einsatz. Diese können auch erweitert und angepasst werden. Hier eine kleine Anleitung, wie man sinnvoll Code aus einem Model generieren kann. In Teil 1 ist die Standardfunktionalität beschrieben. In Teil 2 werde ich die Anpassung von den T4-Templates beschreiben. In Teil 3 werde ich schließlich ein eigenes Profil mit eigenen Stereotypen erstellen und die Codegenerierung “customizen”. Beginnen Sie zunächst mit einem Package. Dem Package können folgende Eigenschaften zugewiesen werden: Der Name des Paketes entspricht dem C#-Namensraum und optional einem Ordner im Zielprojekt. Über … Continue reading Codegenerierung aus Modeling Projects – Part 1

DevelopmentLeave a comment

Strukturelle Integrität

Michael (Mike) Kaufmann

Wenn man als Entwickler in ein neues Projekt kommt, dann fällt es einem fast immer schwer sich im bestehenden Code zu orientieren. Entweder es gibt zu wenig Struktur, d.h. alle Dateien liegen in wenigen oder keinen Projekten/Ordnern, oder zu viel, d.h. alle Dateien verstecken sich hinter einer tiefen Struktur an Ordnern mit mehr oder weniger sinngebenden Namen. Deshalb die Frage: wie müssen wir Code strukturieren, dass sich neue Teammitglieder schnell und problemlos in der Struktur zurecht finden? Es geht mir an der Stelle jetzt erst mal gar nicht um die Aufteilung in eigene Komponenten. Dies alleine kann ganze Büche füllen. … Continue reading Strukturelle Integrität

Daily Sharp, Development3 Comments

Fluent Assertions

Michael (Mike) Kaufmann

Was mir bei NUnit besser gefällt als bei MSTest ist die Aussagekraft von den Assertions. “Assert.That(something, Is.EqualTo(anotherthing);” finde ich viel aussagekräftiger als “Assert.AreEqual(anotherthing, something). Besonders die generischen Variante “Assert.AreEqual<string>(expectedstring, actualstring)” finde ich auf den ersten Blick nicht leicht verständlich. Deshalb kam ich auf die Idee eine eigene Lösung mit einem Fluent-Interface für MSTest zu entwickeln. Allerdings hat eine kurze Suche bei Google ergeben, das es hier schon etliches auf dem Markt gibt. Näher angesehen habe ich mir bisher Fluent Assertions. Die Lösung steht auf GitHub zur Verfügung – kann aber bequem über NuGet installiert werden. Die Lösung funktioniert sowohl mit … Continue reading Fluent Assertions

DevelopmentLeave a comment

Wichtiger als Qualität?

Michael (Mike) Kaufmann

Was gibt es wichtigeres als Qualität in der Softwareentwicklung? Wenn man die Frage so stellt, bekommt man immer “Nichts!” als Antwort. Trotzdem ist das dann aber nicht das, was wir in der Praxis sehen. Schulung? Keine Zeit. TDD? Keine Zeit. Code Reviews? Keine Zeit. Warum tappen wir in der Softwareentwicklung immer wieder in die gleiche Falle? Schlechte Qualität führt unweigerlich in eine Spirale. Es entstehen Bugs, die wir in nachfolgende Sprints oder schlimmstenfalls sogar Projekte “mitnehmen”. Diese Bugs sind extrem schwer zu planen. Sie sind viel Aufwändiger als gleich gute Qualität anzuliefern. Und sie hindern uns wieder daran “wichtiges” zu … Continue reading Wichtiger als Qualität?

Development, RequirementsLeave a comment

Geschnitten oder am Stück?

Michael (Mike) Kaufmann

Eine der großen Herausforderungen bei agiler Softwareentwicklung ist der Umgang mit Anforderungen. In der Theorie ist alles ganz einfach: die Anforderungen werden als UserStories definiert. Jede UserStory beschreibt ein Stück Software-Inkrement das auslieferbar ist und einen Kundennutzen erfüllt. Das Inkrement muss ein funktionierendes Stück Software sein, dass der Anwender “benutzen” kann. Abbildung 1 zeigt die Schematische Struktur in einer 3-Tier-Architektur. Abbildung 1: Erstellen von Software in Inkrementen Warum fällt es dann in der Praxis den meisten Entwicklern so schwer Inkremente für UserStories zu liefern? Schauen wir uns erst mal an, wie in den meisten Projekten Anforderungen in das “Backlog” gelangen. … Continue reading Geschnitten oder am Stück?

DevelopmentLeave a comment

„Entwickler sind die schlechtesten Tester“

Michael (Mike) Kaufmann

Diese Aussage habe ich noch vor einigen Jahren öfter benutzt. Die Argumentation war, dass Entwickler ja die zu entwickelnde Applikation kennen und deshalb immer nur das testen, was auch funktioniert. Wer mich kennt weiß, dass ich heute eine ganz gegenteilige Meinung habe. Aber warum? Testen ist ein elementarer Teil der Softwareentwicklung. So wie es niemandem einfallen würde einen nicht kompilierten C# Code an einen Kunden auszuliefern würde auch niemand eine ungetestet Software ausliefern. Jeder Entwickler testet deshalb auch den ganzen Tag. Alle paar Minuten (oder spätestens nach ein paar Stunden) wird wieder die neue Funktionalität getestet. Nur leider machen die … Continue reading „Entwickler sind die schlechtesten Tester“