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?

Dez 082014
 

Bei der Entwicklung von Unittests für mein privates Windows Store und Windows Phone Projekt bin ich bei der Konvertierung der alten Unittests für die Portable Class Library (PCL), die in dem Projekt verwendet wird, darüber gestolpert, dass auf einmal das „ExpectedException“ Attribut nicht mehr gefunden wird. Dieses Attribut verwendete man in den Unittests, um Tests zu kennzeichnen, die eine Exception werfen müssen. So richtig sauber war das allerdings irgendwie noch nie, da man eigentlich die einzelnen Bedingungen mittels „Assert“ geprüft hat. Es ist also nur konsequent, dass das Attribut mittlerweile entfernt wurde und durch eine entsprechende Methode in der Assert-Klasse ersetzt wurde. Folgendes kleines Beispiel zeigt die Verwendung der Methode „ThrowsException“:

Simpel, oder? Hat mich allerdings trotzdem etwas Zeit gekostet, da ich mit dieser Änderung erst mal nicht gerechnet habe.

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