Ein C#-Entwickler auf Abwegen

von am 07.04.2017
0
IMG_2807

Ich arbeite seit vier Jahren als Softwareentwickler bei Zühlke. In diesem Blogbeitrag möchte ich einen Einblick in mein Arbeitsleben geben und von meiner Erfahrung, die ich “außerhalb der Komfortzone” gemacht habe, berichten. Das hat mich gelehrt, auch neue, unbekannte Dinge auszuprobieren.

Zühlke? Genau meine Welt.

Als ich bei Zühlke anfing, hatte ich eine stark emotionale Meinung gegenüber C/C++: Für mich war beides zum einen “eh dasselbe”, zum anderen nur dafür gemacht, Entwicklern das Leben schwer zu machen.
Meine bevorzugte Sprache? Nein, nicht etwa Visual Basic oder Java, sondern eindeutig C#. Durch meinen Start bei Zühlke lernte ich zusätzlich zu C# noch WPF und das MVVM-Pattern kennen und hatte mich sofort verliebt: Das war genau meine Welt.

Das erste Embedded-Projekt oder wie ich C++ eine Chance gab

Dementsprechend war es für meine Kollegen überraschend, als ich auf den Wunsch meines Vorgesetzten ein Embedded-Projekt übernahm. Hierbei ging es nicht um ein Wir-tun-so-als-ob-Embedded-Projekt, bei dem man ein winziges Linux mit Mono auf dem Gerät laufen lässt und dann wie gewohnt mit C# entwickelt. Nein, es ging darum, eine Firmware für eine Teilkomponente eines Blutzuckermessgeräts mit C++ zu erstellen. Der Kunde, ein großes Pharmaunternehmen, möchte in dem Projekt ein neues Handheld-Gerät für die Analyse von Blutwerten mittels neuartiger Messmethoden entwickeln. Zühlke ist hier Partner für die Integration und Entwicklung der Messeinheit.

Wer sich nun fragt, warum sich ein C#-Entwickler mit Embedded-C++-Entwicklung beschäftigt, dem kann ich folgende Antwort geben:
Zum einen habe ich mich für das Projekt entschieden, weil ich primär ein Desktop-Tool mit C# und WPF entwickeln sollte, welches die Kommunikation mit dem Blutzuckermessgerät und die Konfiguration desselben während der Entwicklung stark vereinfacht. Zum anderen erhoffte ich mir, C++ ein bisschen näher kennen zu lernen. Neben der Entwicklung der C#-Toolchain sollte ich zudem langsam an den C++-Code herangeführt werden. Dabei setzte ich auf die  C++-Spezialisten und ihre Erklärkünste. Für mich gab es zwei Möglichkeiten: Entweder wird das bis dato für mich sehr umständliche C++ endlich verständlich oder ich beschäftige mich nicht mehr damit.

Spannende Herausforderungen: Learning by doing

Doch natürlich kommt es erstens immer anders und zweitens als man denkt. Das Projekt hatte bereits einen .NET-Entwickler für die Toolchain, den ich nach einer Übergangszeit ablösen sollte. Da bisher noch nicht viel Arbeit in der Toolchain nötig war, bestanden meine ersten Aufgaben darin, mich mit dem C++-Firmware-Code vertraut zu machen. Recht früh übernahm ich dabei die Aufgabe, ein bestimmtes Hardwaremodul des Gerätes anzusteuern. Dies stellte sich schnell als spannende Herausforderung dar, weil zur Einarbeitung in C++ noch die Herausforderung des Einarbeitens in die Embedded-Entwicklung dazu kam. So lernte ich einige Dinge kennen, die für mich komplett neu waren:

  • Datenblätter und Handbücher von Hardwarebausteinen lesen und verstehen
  • Direkt auf Register von Hardwarebausteinen zugreifen
  • Wie funktionieren ein Digital-Analog-Wandler (DAC) und Analog-Digital-Wandler (ADC)?
  • Wie spreche ich mit einem DMA-Controller?

IMG_2806_web

Gerade letzteres führte in einer Retrospektive zur überraschenden und stolzen Erkenntnis “DMA ist kein Hexenwerk”.
Das Bild meines Schreibtisches veränderte sich radikal. Zu Laptop, Bildschirm und Tastatur gesellte sich schnell eine PVC-Platte mit einem Entwicklungsaufbau der Hardware, viele Kabel und ein Oszilloskop, um periodische analoge Signale zu messen. Dadurch war ein Teilerfolg in der Ansteuerung der Hardware sofort auf dem Oszilloskop sichtbar. Dies sorgte dafür, dass für mich die Einarbeitung nicht nur herausfordernd, sondern auch spannend und mit Erfolgserlebnissen verbunden war.
Da das Projekt bereits lief, war ich auch nicht mit den Problemen konfrontiert, die das Aufsetzen eines neuen Projektes inklusive Umgebung mit sich bringen.
Diese erlebte ich jedoch privat, als ich eigene Versuche anstellte. Ein Gedanke, der mir noch in Erinnerung blieb, war: “Was? Für ‘new’ brauche ich eine externe Library?” Gemeint war natürlich die LibC.

Fortschritte während des C++-Projekts

In dem Projekt gab es für die Firmware bereits eine Infrastruktur. Ich arbeitete lediglich in dem Quellcode, der die von mir anzusteuernde Hardware kapselte.
Ziemlich schnell war ich begeistert, obwohl mein Verständnis für die Sprache nicht viel stärker war als bisher. Immerhin konnte ich mich jedoch mit meiner Erfahrung in C#, der Projektdokumentation, der Dokumentation der Hardware und häufigen Nachfragen zu Sprachdetails bei Kollegen von Teilerfolg zu Teilerfolg hangeln.
Langsam wurde es aber Zeit, meine Selbständigkeit in der C++-Entwicklung zu erhöhen, also fragte ich nach einer geeigneten Lektüre. Im Nachhinein betrachtet, finde ich es interessant, dass der eigentliche Durchbruch nicht durch ein Buch kam, das versucht dem Leser C++ zu erklären.  Meinen Durchbruch hatte ich mit einem Buch, das versucht C++-Entwickler vor typischen Fehlern zu schützen, indem es Coding-Guidelines vorschlägt. Hierbei geht es nicht um das berühmte Design-Pattern-Buch der “Gang of Four” [1], sondern um das Buch “Effective C++” [2].

Die Art der Beschreibung der Fallstricke sowie mein Interesse an Assembler während des Studiums sorgten dafür, dass sich meine persönlichen Fragestellungen wandelten: Anfangs beschäftigte mich vor allem die Frage: “Warum haben die das so umständlich gemacht?” Doch je weiter das Projekt und die Lektüre fortschritten, desto mehr stellte ich mir die Frage: “Wie liest der Compiler das?” und “Wie würde das in Assembler umgesetzt?”

Ich denke, ich muss nicht erwähnen, dass ich mir zu Beginn beim Debuggen oft auch den Assembler-Teil anschaute, um zu überprüfen, ob meine Vermutung (“Wie hätte ich das in Assembler gelöst?”) korrekt war oder nicht. Dies war unter anderem dadurch möglich, dass die Optimierungen im Compiler noch ausgeschaltet waren und so häufig der Assembler-Code der Erwartung entsprach. Dadurch verringerte sich mein Unverständnis gegenüber der unberechenbaren Kreatur namens “Compiler”, die immer wieder irgendwelche Umstände erforderte, um eigentlich einfache Sachverhalte darzustellen.
Tatsächlich würde ich jedem, der sich mit C/C++ schwer tut, empfehlen, die Hintergründe und Gründe für bestimmte Eigenheiten der Sprache zu erforschen.
In C++ ist vieles “historisch gewachsen”. Ein Satz, den man in Projekten meist verwendet um “Wir haben uns mal früher für den falschen Weg entschieden und keiner möchte das mehr gerade ziehen” politisch korrekt zu umschreiben. Allein die Kompatibilität mit C sorgt dafür, dass man einige umständliche Eigenarten in C++ hat, die man auch nicht einfach entfernen kann.

Mein Fazit

Inzwischen bin ich begeisterter Entwickler in C++, sowie in C#. Heimisch fühle ich mich aber nach wie vor in letzterem. Im Nachhinein betrachtet, finde ich es schon interessant, wie meine Neugier, meine Kollegen und auch die Kultur bei Zühlke dazu beitrugen, dass ich von einem fremdgehenden C#-Entwickler zu einem begeisterten C#/C++-Entwickler wurde. Es ist immer wieder spannend zu sehen, welche neuen Dinge man doch im Rahmen eines Projektes gelernt hat und inwiefern man seinen Wissensschatz erweitern konnte. Das ist einer der Gründe, warum ich mich bei Zühlke wohlfühle.

Warst du auch einmal in der Situation, eine Technologie zu verwenden, gegen die du eigentlich starke Bedenken hattest und hast am Ende gemerkt, dass das Entwickeln mit dieser Technologie genauso viel Spaß machen kann wie im vertrauten Umfeld? Ich bin gespannt auf eure Erfahrungsberichte in den Kommentaren.

Referenzen

[1] Gamma, Helm, Johnson, Vlissides – “Design Patterns: Elements of Reusable Object-Oriented Software” ISBN: 0-201-63361-2
[2] Scott Meyers – “Effective C++ Third Edition” ISBN: 9780132702065

Einen Kommentar hinterlassen

Ihre E-Mail-Adresse wird weder veröffentlicht noch weitergegeben. Pflichtfelder sind mit einem * markiert.