Dez 222014
 

Was soll man eigentlich viel über Clean Code schreiben? Es ist ja eigentlich offensichtlich, dass man im Sinne der Wartbarkeit, Einheitlichkeit und Verständlichkeit seinen Quellcode formatieren sollte. Dennoch wird es nicht auf Anhieb gelingen 100%ig sauberen Code zu entwickeln, aber dafür gibt es ja Tools wie bspw. StyleCop, die in den Buildprozess eingebunden werden und den geschriebenen Code analysieren und entsprechend Warnungen oder Fehlermeldungen ausgeben. Ich selbst habe mich bspw. beim Schreiben meines Codes immer an den Klassen des .NET Frameworks gehalten und auch versucht bei unseren Frameworks die angebotenen Methoden daran zu orientieren. Das fällt nicht immer leicht, ist aber notwendig, um den Anwender einen schnellen Einstieg zu ermöglichen. Selbst in privaten Projekten habe ich mittlerweile begonnen, mich an diverse Regeln zu halten, brav Unittests zu schreiben und StyleCop in den Buildprozess zu integrieren. Das kann zwar nervig sein, da man so nicht mal eben schnell ein kleines Tool entwickelt, das man gerade braucht, aber irgendwie habe ich mich daran gewöhnt so zu arbeiten und fühle mich dabei besser. Auf der anderen Seite habe ich mir dadurch aber auch schon einige Zeit gespart, die sonst bei der Fehlersuche verloren gegangen wäre.
Dennoch brandete bei einem Vortrag vor kurzem die Diskussion auf, ob Clean Code überhaupt notwendig sei. Schliesslich komme es nur auf Variablenbenennung und Methodennamen an, den Code kann man dann schon lesen. Tools wie StyleCop würden „Fingerpointing“ betreiben und die Entwickler an den Pranger stellen, wenn die Warnings oder Fehler im Buildprozess auftauchen. Man solle also den Entwicklern lieber ihre Freiheiten lassen.
Ich frage mich, ob es wirklich so ist, dass Entwickler nicht kritikfähig sind und es nicht vertragen, wenn man gewisse Vorgaben und Regeln bei der Implementierung einhalten soll. Das kann ich mir eigentlich gar nicht vorstellen. Sucht man selbst nicht permanent nach Möglichkeiten, den eigenen Code zu verbessern und effizienter zu arbeiten? Ich verstehe, dass man nicht auf einen Schlag den bisher geschriebenen Code Refaktorisieren und auch nur schwer argumentieren kann, dass bereits funktionierender Code noch einmal angepasst werden soll – er funktioniert ja und macht nachher letztendlich das Gleiche. Leider wird es bei dieser Argumentation von gewichtiger Stelle dann aber auch sehr schwierig, diese Methodik einzuführen.
Wie sieht es bei euch aus? Dürft ihr die Clean Code Prinzipien anwenden? Wie konntet ihr Clean Code einführen oder gab es auch Vorbehalte gegen Clean Code?

Nov 102014
 

Weiterbildung spielt in unserem Beruf eine große Rolle – zumindest habe ich das immer so gesehen und suche eigentlich tagtäglich nach neuen Möglichkeiten mein Wissen zu erweitern und meine Arbeitsweise effizienter zu gestalten. Das Tolle ist auch, dass sich in unserem Beruf immer wieder Neues ergibt und man eigentlich gar nicht stehen bleiben kann. Es wäre ja langweilig, wenn man jahrelang ausschließlich auf seinem Wissensstand bleiben und nicht Neues mehr kennenlernen würde, oder?
Eine für mich neue Möglichkeit, die ich seit kurzem nutze, ist die kostenlose Microsoft Virtual Academy (MVA). Die MVA bietet jede Menge Kurse zu den unterschiedlichsten Themen aus dem Microsoft Umfeld an. Sei es die Softwareentwicklung mit C#, plattformübergreifende Anwendungen, Spieleentwicklung mit unterschiedlichen Spieleengines (bspw. Construct 2, GameMaker oder Unity) oder die Azure Dienste – hier werdet ihr fündig. Durch das Abarbeiten erhaltet ihr Punkte, die euren Rang auf der Plattform widerspiegeln. Die Qualität der Kurse ist meist auch recht hoch und beim Abschluss eines Kurses erhaltet ihr ein Teilnahmezertifikat. Schaut euch doch auch einfach mal ein paar Kurse an. Vielleicht gefällt es auch auch.

Okt 272014
 

Hattet ihr auch schon einmal das Problem, dass ihr in eurer Software eine Enumeration verwenden wolltet, aber eigentlich zwei Enumeration benötigt wurden, weil ein anderer Programmteil mehr Werte benötigt? Ich schon :-). In meinem Fall ging es um Messbereiche von unterschiedlichen Hardwaregeräten. Zum Beispiel besitzt Gerät A die Messbereiche „Low“ und „High“, während Gerät B die Messbereiche „Low“, „High“, „Medium“ und „Aux“. Der Entwickler soll in seinem Programm aber nicht mit der Hardwareabhängigkeit konfrontiert werden und wählt über den Namespace das entsprechende Gerät und damit auch die Implementierung der Enumeration.
Da „Low“ und „High“ die gemeinsamen Messbereiche abbilden, werden sie in der Hauptklasse verwendet, von der alle Erweiterungen dann ableiten. Der eigentliche Trick besteht aber darin, dass diese Klasse statische Klassenvariablen anbietet, die nur innerhalb dieser Klasse und ihrer Ableitungen initialisiert werden können. Überläd man außerdem noch die Operatoren kann man auch einfach die Werte miteinander vergleichen. Hier ein Beispiel, wie diese Klasse aussehen könnte:

Möchte man diese Klasse nun erweitern, braucht man nur eine neue Klasse anlegen, die von dieser Klasse ableitet und den Konstruktor der Basisklasse aufrufen. Hier das Beispiel für das oben genannte Gerät B:

Im Hauptprogramm kann man jetzt einfach eine Variable vom Typ „MeasurementRange“ deklarieren und die statischen Variablen der beiden Klassen zuweisen. Dabei ist es vollkommen egal, von welcher Klasse die statischen Variablen herkommen. Nachfolgend ein paar Zeilen Programmcode, die das auch noch verdeutlichen:

Für unsere Implementierung war das genau der richtige Ansatz. Solltet ihr das Extendable Enum in einem eurer Projekte einsetzen oder andere (elegantere?) Ansätze für das Problem haben, dann schreibt doch einen Kommentar. Würde mich freuen :-).

 

Okt 162014
 

Ok, zugegeben… eine etwas komische Überschrift, aber so ein wenig trifft sie dann doch das, was ich mit diesem neuen Blog hier vor habe. Wie bereits auf meinem Weblog angekündigt, ist das „Devlog“ eine Abspaltung meines Blogs, in dem es zukünftig Beiträge rund um die Softwareentwicklung gehen soll – quasi also alles, was man so als Softwareentwickler tagtäglich an der Arbeit antreffen kann. Der Hauptfokus wird auf der .NET Plattform von Microsoft liegen, aber auch allgemeine und grundlegende Dinge sollen hier beschrieben werden. Regelmäßige Beiträge wird es aber auch hier nicht geben. Wenn ich mal über irgendwas stolpere, das ich interessant finde, dann wird es hier abgelegt und natürlich bin ich auch offen für eure Anregungen. Wenn ihr also spannende Themen habt, dann nichts wie her damit. Auf meinem Weblog wird in Zukunft der Fokus eher auf meinen privaten Projekten liegen, wobei sich sicherlich gewisse Überschneidungen nicht vermeiden lassen. Mal schauen, wie ich das in Zukunft lösen werde.
Zum Auftakt habe ich erst einmal alle relevanten und nicht zu alten Beiträge zum Thema .NET und Softwareentwicklung aus meinem anderen Blog hier eingefügt. Also viel Spaß mit dem neuen Blog :-)!

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen