Tag: Agile (Seite 3 von 4)

Wie misst man Clean Code?

Als Software-Entwickler stehe ich am Ende des Tages mit einer mal mehr, mal weniger großen Menge neuen Codes da und stelle mir die Frage: Wie gut ist das, was ich heute geschrieben habe?

Genauso wie viel andere neige ich aber dazu, nicht immer 100 % objektiv zu sein, wenn ich die Qualität meines Codes selber beurteilen muss. Deswegen ist in unserer „Definition of Done“ festgelegt, dass jeder Code durch einen Kollegen revidiert werden muss. Dadurch erhalte ich eine zweite, unabhängigere Sicht auf meinen Code.

Falls man aber gerade keinen Kollegen zur Hand hat, hilft es auch, nacheinander die Prinzipien des Clean Codes durchzugehen und den Code darauf zu überprüfen, wie gut die Prinzipien dort umgesetzt sind. Und um dem eigenen, wohlwollenden Blick ein wenig Objektivität zur Seite zu stellen, hat es sich für mich bewährt, ein paar Code-Metriken zur Unterstützung heranzuziehen.

Bridging Gaps – Connecting People – Die REConf 2015 und unser Vortrag über den Anforderungsmanager in agilen Großprojekten

Die REConf ist die größte Konferenz zum Thema „Requirements Engineering“ im deutschsprachigen Raum. Nachdem wir im letzten Jahr mit unserer Fokus-Gruppe Requirements Engineering innerhalb der it-economics richtig durchgestartet sind, war diese Konferenz natürlich Pflicht – zumal sie auch noch in München stattfand. Die Kür für uns war allerdings, dass wir bei der Konferenz direkt mit einem Vortrag im Track „Agile“ angenommen wurden.

Mit der Abrissbirne zu besseren Unittests – Erkenntnisse beim Kaffeetrinken mit Uncle Bob

Durch glückliche Umstände hatte ich vergangenes Jahr die Möglichkeit, an einem zweitägigen Workshop mit Robert C. Martin – besser bekannt als „Uncle Bob“ – teilzunehmen. Ich hatte zu dieser Zeit bereits einige Erfahrung mit testgetriebener Entwicklung gesammelt, sowohl in Coding Dojos als auch in der täglichen Projektarbeit. Die Arbeitsweise durch das Vorgehen nach TDD (test-driven development) hatte signifikant positive Auswirkungen auf die Qualität der Software, die wir bauten, und gab uns ein Gefühl für eventuelle Schwachstellen der Anwendungen.

Agile Festpreisprojekte

In diesem Blogeintrag werden die wesentlichen Erfahrungen aus der Durchführung von agilen Festpreisprojekten zusammengefasst. Der Autor hat viele agile Festpreisprojekte in einer Größenordnung von bis zu 3000 Manntagen pro Release/Vertrag durchgeführt. 

Das Interface Segregation Principle – Nicht nur auf den Schnitt kommt es an

In unserem heutigen SOLID-Beitrag geht es um das „Interface Segregation Principle“. Wie wir im Blog sehen werden, ist dabei weniger die Trennung nach Interfaces das Problem, als vielmehr die an manchen Stellen wieder benötigte, sinnvolle Zusammenführung von Funktionalitäten aus verschiedenen Interfaces eines Objekts.

Vorweg: Die Fachabteilung war ganz begeistert, dass wir neulich die Anforderung zur Aufnahme von nicht registrierten Kunden so schnell und sauber umsetzen konnten. Die ausführliche Geschichte und wie die Anwendung des Liskov Substitution Principle zu einer sauberen Lösung beigetragen hat, kann man im „L“-Blog unserer SOLID-Reihe nachlesen.

Allerdings hat diese Erweiterung den Einfallsreichtum angespornt. Die neue Vision: Zukünftig sollen weitere neue Kundentypen im System eingeführt werden können. Außerdem soll es möglich sein, bestehende Kunden in einen anderen Kundentyp zu wandeln ohne dazu den Kunden im System neu anlegen zu müssen. 

Das – Liskov Substitution Principle – LSP

ubtypes must be substitutable for their base types. 

So, das „S“ und das „O“ der SOLID-Prinzipien haben unser Design hinsichtlich der Qualitätsmerkmale wie Wartbarkeit, Testbarkeit und Erweiterbarkeit bereits erheblich verbessert. Wir haben gesehen, dass es Sinn macht, einer Klasse möglichst nur eine Verantwortlichkeit zu übertragen (Single Responsibility Principle) und Programmcode offen für Erweiterungen, aber geschlossen für Änderungen zu implementieren (Open Closed Principle).

Das Open-Closed Principle (OCP)

Software sollte lesbar, modular und wartbar sein. Leider entsteht im Laufe der Entwicklung, vor allem aber auch bei Weiterentwicklungen, immer wieder schlechtes Software-Design. Im schlimmsten Fall treten Programmfehler bei bereits längst getesteten Funktionalitäten auf. Die Beachtung der SOLID-Prinzipien objektorientierter Softwareentwicklung kann helfen, diese Fehler zu vermeiden und Programmcode wartbar zu halten. Insbesondere die Wartbarkeit ist von großer Bedeutung, da man selten Softwareentwicklung auf der grünen Wiese betreibt, sondern in den allermeisten Fällen auf vorhandenem Programmcode aufbaut.

Das Single Responsibility Principle (SRP)

There should never be more than one reason for a class to change.

Heute beginnen wir mit dem ersten SOLID–Prinzip: Eine Klasse sollte immer eine einzige Verantwortung haben, oder anders ausgedrückt: Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern (Single Responsibility Principle, SRP).

Das SRP wendet man an, um übersichtliche, leicht erweiterbare und einfach zu wartende Software zu konzipieren.

Aufwandsschätzungen in Softwareentwicklungsprojekten – hätten Sie’s lieber klassisch oder agil?

In meinem letzten Blog „Gut geschätzt ist halb gewonnen“ habe ich verschiedene Verfahren zur Aufwandsschätzung vorgestellt, die – so wie ich selbst – allesamt ihre Wurzeln im klassischen Projektmanagement haben. Bewusst hatte ich dabei die agile Methodik ausgeklammert. Heute möchte ich eine kleine Brücke zwischen den damals vorgestellten „klassischen“ Verfahren und dem Schätzverfahren nach Scrum schlagen. Zu häufig höre ich Postulate wie „Scrum ist etwas völlig Neues“, „Nur der agile Ansatz ist richtig“ oder „Das klassische Projektmanagement ist altmodisch, out, zum Scheitern und zum Aussterben verdammt“.

SOLID – ein Schritt zu mehr Professionalität in der Software-Branche

Schon vor vielen Jahren saß ich mal in einer Straßenbahn, wir standen an einer Haltestelle, es ging nicht weiter. Plötzlich hörten alle Motoren auf zu summen, alle Lichter gingen aus – und nach einiger Zeit wieder an. An der Anzeige über dem Fahrer blinkte die Firmware-Versionsanzeige auf. Was war passiert? Offenbar war die Straßenbahn „abgestürzt“ und der Fahrer hatte sie in seiner Not einfach neu gebootet.