Viele Firmen haben eigene Richtlinien, wie der Code ihrer Embedded-Projekte auszusehen hat. Doch wenn es drauf ankommt, entscheidet meist jeder Entwickler für sich selbst, wie er den Code schreibt. Vorstöße einzelner Kollegen, etwas zu verbessern oder einheitlich zu arbeiten, sind kaum von Erfolg gekrönt. Denn dann müsste man unter Umständen seine Arbeitsweise ändern – und das kostet Zeit und gefährdet vielleicht den termingerechten Projektabschluss.
Dann gibt es auch die Firmen, die zwar Richtlinien haben, aber derer zu viele. Das schafft oft Unsicherheit, da bei zu vielen (sich eventuell widersprechenden) Regeln niemand weiß, an was er sich denn zu halten hat. Also macht doch wieder jeder „seins“.
Welche Gründe stehen hinter Programmierrichtlinien?
Oft gibt es klare Regeln, die jedoch viel zu weit gehen und den Entwickler in seiner Kreativität stark einschränken. Vermeintlich unsichere Konstrukte werden verboten, um die Sicherheit des Codes zu erhöhen. Zusätzlich verhindern diese strengen Regeln, dass moderne Programmiertechniken eingesetzt werden. Mitunter wird der Code aktuellen Anforderungen nicht gerecht, was die Sicherheit wiederum senkt.
Um das Richtlinien-Dilemma besser zu verstehen, muss man sich die Gründe für die Einführung von Programmierrichtlinien vor Augen halten:
Variante 1: Die Regeln sollen helfen, eine Codebasis zu schaffen, in der sich jeder Entwickler zurechtfindet. Der Code ist gut strukturiert und einfach zu lesen. Die Zusammenarbeit der einzelnen Teammitglieder soll reibungslos funktionieren.
Variante 2: Es wird ein strenges Regelwerk geschaffen, das alle als kritisch eingestuften Konstrukte verbietet, in dem Glauben, dass jeder Mitarbeiter im Projekt auch gut programmieren kann. Wird Know-how durch Regeln ersetzt, kann die Entwicklung effektiver und kostengünstiger in Billiglohnländer ausgelagert werden.
In Wissensvermittlung und Grundlagen investieren
Variante 2 wird wahrscheinlich nicht funktionieren – Know-how lässt sich nicht durch Regeln ersetzen. Probleme in der Softwareentwicklung sind nicht die Folge von zu wenigen Regeln, sondern von zu wenig Kenntnis. Das Hauptproblem besteht darin, dass die Komplexität von Software in den klassischen Industriezweigen unterschätzt wird.
Das Management vertritt häufig die Meinung: „Was nichts wiegt, ist nichts wert.“ Dementsprechend wird viel zu wenig in die Grundlagen investiert. Ingenieure bekommen eine Entwicklungsumgebung vorgesetzt, ohne die Grundlagen richtig erlernt zu haben. Deshalb muss vor jeder Regel erst einmal eine sorgfältige Wissensvermittlung stattfinden. Das klingt teuer, ist aber in der Summe die kostengünstige Lösung. Programmierrichtlinien können eine fundierte Ausbildung nicht ersetzen. Sie sind eine Ergänzung, um die Teamarbeit zu verbessern.
Regeln sollten auf ein A4-Blatt passen
Ein weiterer wichtiger Punkt ist die Motivation der Entwickler. Wenn der Sinn hinter den Regeln nicht klar vermittelt wird, wird es immer auch Verstöße geben. Im Endeffekt sollte der Entwickler der Hauptnutznießer der Regeln sein. Andernfalls haben die Regeln ihren Sinn verfehlt und werden nicht akzeptiert.
Zudem sollte die Menge der Regeln überschaubar sein, beispielsweise auf Vorder- und Rückseite eines A4-Blattes. In den wenigsten Fällen arbeitet ein Programmierer sich durch ein umfangreiches Regelwerk. Regeln, die die Formatierung des Codes betreffen, müssen automatisch geprüft werden. Ein Check-in darf mit Regelverstoß nicht möglich sein.
Zusammengefasst
Unterm Strich lassen sich somit drei Schlussfolgerungen festhalten:
Fazit 1: Programmierregeln können das Projekt nicht retten.
Fazit 2: Ohne ausreichende Ausbildung und Know-how der Entwickler werden auch die besten Regeln nichts retten können.
Fazit 3: Auf wenige, aber sinnvolle Regeln beschränken.
