Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

embedded Clean code

Autor: Thomas Winz, softwareimotion

Beitrag - Embedded Software Engineering Kongress 2015

 

"Nerdy hatte die Nase voll von diesem DinoPark-Projekt. Obwohl man bereits der Terminplanung hinterherhinkte, verlangte InGen noch umfangreiche Modifikationen am System, war aber nicht bereit, dafür zu bezahlen; die Geschäftsleitung argumentierte, dies sei Teil des ursprünglichen Vertrages. Man drohte mit gerichtlichen Schritten." [Ref1]

Software ist ein wertvolles Gut, das im Umfeld größter Unsicherheit entsteht. Ohne eine ordentliche und vernünftige industrielle Softwareentwicklung sprengt dieser Spannungsbogen jewedige Kosten-/ Nutzung-Rechnung; genau hier setzt eCc (embedded Clean code) an.

Einführung

Moderne Ansätze der Personalführung haben zur Folge, dass kritische Projektentscheidungen im Tagesgeschäft durch einzelne Entwickler fallen. Die Ausweitung der Entscheidungsträger auf das gesamte Projektteam ist mit Risiken verbunden. Die klaren Regeln von eCc helfen dem Entwickler, sich bei der Codierung zu fokussieren und so dieses hohe Risiko bewusst zu tragen.

Hintergrund

embedded Clean code konnte 2014 auf dem Embedded Software Engineering Kongress seine Weltpremiere feiern. [Ref 2]. Das Regelwerk eCc dient als Fundament für ordentliche und vernünftige industrielle Softwareentwicklung (s. Abbildung 1, PDF).

Die 2014 vorgestellte Theorie umfasst drei große Themengebiete:

  • Überflüssige Codierung vermeiden
  • Gutes Design ist immer angemessen
  • Es ist immer einfacher, Code zu schreiben, als zu verstehen


Dieser Bandbeitrag baut auf diesen "best practice" Grundlagen von eCc auf und geht dieses Jahr auf die Aktivitäten von eCc ein.

Werte für Gruppenarbeit

Ohne Vertrauen und eine moralische Wertebasis können Menschen nicht zusammenarbeiten. Dies ist auch die fundamentale Überzeugung aller agiler Methoden. Die in eCc beschriebenen Aktivitäten werden gelebt, um Fehler zu vermeiden. Aber das bedeutet, dass der einzelne Entwickler seine Schwächen der Gruppe aufzeigen muss. Dazu muss der einzelne Entwickler Vertrauen in seine Kollegen aufbauen. Das heißt, dass nur in einer gesunden Gruppenkultur die eCc-Methoden überhaupt gelebt werden können.

Aber diese grundlegenden Werte würden die Umfänge von eCc sprengen. Deswegen wird sich darauf beschränkt, die Werte von "Extreme Programming" aufzuführen. Diese Werte zeigen seit 2004 in tausenden Projekten ihre Wirkung und sind somit eine gute Grundlage für eCc.

 

Wert

 

Beschreibung

Einfachheit

Einfachheit ist ein Zustand, der sich dadurch auszeichnet, dass nur wenige Faktoren zu seinem Entstehen beitragen.

Kommunikation

Alle Projektmitglieder sollen intensiv miteinander kommunizieren. Durch persönliche Gespräche lassen sich Missverständnisse schneller ausräumen.

Feedback

Um eine hohe Qualität zu erzielen, nämlich das zu erreichen, was der Kunde benötigt, werden sehr kurze Feedback-Schleifen verwendet, um den Kunden kontinuierlich die Entwicklung zu zeigen.

Mut

Diese Werte einzusetzen und dabei offen zu Kommunizieren erfordert sehr viel Mut, besonders für die Projektmitglieder, die das Handeln nach diesen Werten nicht gewohnt sind.

Respekt

Das Fundament dieser Werte ist der Respekt; Respekt bezeichnet eine Form der Wertschätzung, Aufmerksamkeit und Rücksicht gegenüber allen anderen Teammitgliedern.

 

Tabelle 1: Extreme Programming Werte [Ref 3]

Die grundsätzlichen Software-Aktivitäten

"Wenn es hart auf hart kommt, vertrauen Sie auf Ihre Disziplinen. Der Grund, warum Sie überhaupt diese Disziplinen haben, ist, dass sie Ihnen in Zeiten mit hohem Druck Orientierung geben."  [Ref4]

Gib der einfachen Umsetzung den Vorrang

Laut ISO-26262 ist ein Ziel vom Unit Test ein Beweis, dass Software kein unerwünschtes Verhalten aufweist [REF 5]. Wenn gewünschtes Verhalten als "durch Anforderungen definiert" verstanden wird, bedeutet dies, dass jede Funktionalität ohne Anforderung die Software unnötige kompliziert und potentiell gefährdet. So muss davon ausgegangen werden, dass nicht alle Abhängigkeiten bedacht worden sind (siehe dazugehörige Abbildung, PDF).

Verlasse eine Funktion verständlicher als vorgefunden

Wird eine Funktion nach ihrer Erstellung erneut geändert, ist davon auszugehen, dass weitere Anpassungen stattfinden werden. Deswegen ist es sinnvoll, diese höher frequentierten Codestellen rigide zu reinigen, um diesen Änderungsaufwand über die Projektlaufzeit insgesamt zu minimieren (siehe dazugehörige Abbildung, PDF).

Bei der Software-Optimierung ist Vorsicht geboten

Jede Optimierung ohne Ziel ist Zeitverschwendung, da die Verbesserung nur subjektiv vom einzlenen Entwickler gemessen werden kann. Nicht bedachte Abhängigkeiten zu weiteren Teilsystemen können schwerwiegend gestört werden. Nur statische und architektonische Analysen können als Legitimation für Änderung herangezogen werden (siehe dazugehörige Abbildung, PDF).

Entferne niemals Software unvorsichtig

Es ist absurd anzunehmen, dass eine Neuentwicklung besser als die vorhandene Funktion ist. Im Gegenteil, das Alter einer Funktion dient als Indikator für die Qualität der Funktion. Das Verhalten der Funktion, auch Abweichungen von den Anforderungen, sind bekannt und schon mehrfach erfolgreich umgesetzt worden. Somit kann davon ausgegangen werden, dass die Neuentwicklung bekannte Fehler erneut enthält (siehe dazugehörige Abbildung, PDF).

Lebe eine freie Review-Kultur

"… dass Reviews Kosten verursachen und als Ausgleich dafür bessere Qualität bekommt. … Richtig dagegen ist, dass man Qualität bekommt und zusätzlich Zeit einspart. [" Ref 6]

Viele Standards verlangen Reviews von Arbeitsprodukten, weswegen eine Vielzahl von Reviewarten existieren. Trotzdem kämpft diese Technik um Akzeptanz. Wichtig ist, dass ein Review weitestgehend automatisiert wird. Dazu zählt zunächst einmal die Durchführung. Die Kommunikation, Planung und Verfolgbarkeit sollten ohne Werkzeugbrüche erfolgen. Dabei muss auch das Management akzeptieren, dass dieser Aufwand vom Entwickler verbucht werden darf. Wichtiger ist aber, dass das Arbeitsprodukt mit Werkzeugen analysiert wird, um einfache Routine-Fragen an das Arbeitsprodukt zu erfassen. Dadurch wird das Review zu eine wissenschaftliche Methode. Persönliche Streits um Geschmäcker werden unterbunden. Anonymisierungen tragen dazu bei, dass Gruppenstreitereien nicht in Reviews ausgetragen werden.

Lebe eine konservative Codekonvention

"Die Modifizierbarkeit von Software beschreibt, mit welchem Aufwand dieselbe an neue, zukünftige Anforderungen angepasst werden kann." [Ref 7]

Modifizierbarkeit ist Teil der nicht-funktionalen Anforderung an die Wartbarkeit der Software. Je mehr der einzelne Entwickler seinen Abdruck in der Software hinterlässt, umso höher ist der Aufwand für andere Entwickler, dessen Willen zu erkennen. Konstrukte, die sonst über die gesamte Projektsoftware einheitlich verstanden wurden, müssen somit erneut im Sonderfall erlernt werden. Damit ist jeglicher Mehrwert der Individuallösung hinfällig. Dieses Verhaltensmuster ist aber mehr als eine willentlichen Irritation. Im Alltag mag es zu wesentlichen Einsparungen für den Einzelnen kommen. Die Fehlerfindung geschieht meist unter einem erhöhten Zeitdruck, somit kann im entscheidenden Moment diese schlampige Einstellung existenzbedrohend werden.

Periodisches Refactoring mit Hilfe statischer Analysen

"... debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? " [Ref 8]

Kosteneffiziente Umsetzungen erfordern Kompromisse zur bestehenden Architektur. Somit muss periodisch eine systematische Evaluierung erfolgen, ob die Software noch  der Architektur entspricht. Die "Workaround"-, "Bugfix"- und Durchbruch-Stellen werden identifiziert und in eine ordentliche Struktur gebracht. Wichtig ist, dass solche Evaluierungen mechanisch durch Werkzeuge unterstützt werden. Damit können leichter Strukturen aufgedeckt werden, und ein wissenschaftlicher Ansatz ersetzt die emotional Richtungsdebatten.

Zusammenfassung

Der Entwickler trägt die alleinige Verantwortung für die Softwarequalität und Wartbarkeit. Die nicht funktionalen Anforderungen wie Fehlertoleranz, Verständlichkeit und Portierbarkeit heutiger Industriesoftware können ohne die Fähigkeiten professioneller Entwickler nicht erfüllt werden. Mithilfe von eCc soll dem Entwickler ein Leitfaden an die Hand gegeben werden, um diese Werte auch im Alltagsstress zu leben.

Rechtliche Situation zu embedded Clean Code

Wir suchen Partner, um das Regelwerk deutschlandweit bekannt zu machen.
Das Regelwerk eCc ist unter der Creative Commons Lizenz veröffentlicht:

CC BY NC SA :https://creativecommons.org/licenses/by-nc-sa/3.0/de/

Quellenverzeichnis

Ref

Titel

Autor/ Link

1

Dino Park

Michael Crichton

2

embedded Clean code;

 eseKongress 2014

Embedded Clean Code

3

 

https://en.wikipedia.org/wiki/Extreme_programming

4

Clean Coder Verhaltensregeln für den professionelle Programmierer

Robert C. Martin

5

INTERNATIONAL

STANDARD Road vehicles — Functional safety

 

ISO 26262-1

First edition

2011-11-15

6

Populäre Irrtürmer und Fehleinschätzungen in der Reviewtechnik

Peter Rösler

7

 

https://de.wikipedia.org/wiki/Modifizierbarkeit

8

"The Elements of Programming Style", 2nd edition, chapter 2

Brian Kernighan

 

 


Beitrag als PDF downloaden


Agil & Scrum - unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Agil & Scrum.

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.


Agil & Scrum - Fachwissen

Wertvolles Fachwissen zum Thema Agil & Scrum steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.