Archive for August, 2009

Im Podcast “Talking with Jeremy Miller about ALT.NET” spricht James Avery mit Jeremy Miller über ALT.NET und die Community allgemein.

Beim ALT.NET Open Spaces in Seattle wurde wieder eine sehr negative Session angesetzt, “Why so mean?”. Scott Hanselman stellt hier sehr provokant die Frage, warum die Community immer mehr Energie aufwendet um zu Kritisieren, anstatt die neuen Technologien positiv nach aussen zu tragen. Dies kann ich nach meinen jetzigen Erfahrungen beim .NET Open Spaces in Ulm nicht bestätigen. Bei uns habe ich keinerlei negative Energie gespürt.

Andererseits sehe ich es genauso wie Jeremy: Ansätze, die teilweise gegeneinander arbeiten. DDD widerspricht meiner Meinung nach oft den bisher genutzten Kapselungen. Was nun besser oder schlechter ist kann ich derzeit noch nicht sagen, dazu kenne ich selbst DDD zu wenig. Die Mehrheit der ALT.NET Community hat wohl noch nicht einen allgemeingültigen Weg zur Verfügung, der aus dem bisher eingebrachten Wissen entstanden ist.

Was wohl langfristig nötig ist, dass wir uns über den Grundgedanken von ALT.NET wieder bewusst werden. Der entstehende Code soll clean, korrekt und erweiterbar sein. Also eine auf den Code zentrierte Produktentwicklung. Der Weg mit CCD sehe ich damit als den Richtigen und CCD spricht auch gerade einen positiven Aspekt an.

Seht ihr ähnliche Tendenzen wie Jeremy in der deutschen Community?

kick it on dotnet-kicks.de

Comments 3 Comments »

Wir fragen uns seit langem, wie man internal Methoden testen kann, da eins klar ist, die Kapselung darf nicht wegen der Testfähigkeit verletzt werden.
Letzte Woche hatte zum Glück auch jemand anderer dieses Problem und er hat gleich bei CCD-GoogleGroup nachgefragt. Und so haben wir auch erfahren, wie die Lösung lautet:

für “internal”-Elemente gibt es auch die Option mit [assembly:
InternalsVisibleTo(“TestAssembly”)] zu arbeiten. Alternativ kannst du die zu
testenden Klassen auch per “Add existing item” und dann “Add as link” (siehe
kleines Dreieck neben dem “Add”-Button) zum Testprojekt hinzufügen.

(Danke Alex)

Danach war nur noch ein wenig Surfen nötig, um alles zu erfahren:

msdn sagt:

InternalsVisibleToAttribute Class

Specifies that types that are ordinarily visible only within the current assembly are visible to another assembly.

User comment:
It is not documented anywhere to my knowledge, but if you want to grant “InternalsVisibleTo” permission to more than one assembly, you need to understand the syntax.

To do this you should NOT insert multiples instances of:

[assembly: InternalsVisibleTo("FirstAssembly")]

Instead do this:

[assembly: InternalsVisibleTo("FirstAssembly"),
InternalsVisibleTo("SecondAssembly"),
InternalsVisibleTo("ThirdAssembly")]

The former syntax is legal but fails, because each instance simply redefines and replaces any earlier ones, the latter syntax works as required.

kick it on dotnet-kicks.de

Comments 1 Comment »

Wir haben es gerade geschafft, die ganzen Infos vom .NET Open Space Süd zu ordnen, und schon ging es mit der Anmeldung für den nächsten Open Space in Leipzig los!
Der Andrang war so groß, dass innerhalb von ein paar Tagen die Teilnehmerliste voll wurde.
Nach meiner Erfahrungen in Ulm, kann ich das voll verstehen, da wird einem das Wissen mit goldenem Löffel serviert 😉 Und man darf auch noch selbst bestimmen, über welches Thema und wie detailliert man erfahren möchte. Und das von den besten Köpfen der Branche, eventuell sogar neben einem Bier, was möchte man/frau mehr ??

Unter dem Titel Agenda steht folgendes:

* wir fangen Samstag und Sonntag um 9 Uhr an, der Rest findet sich, die Organisation ist jeweils schon ab 8 Uhr da und führt Smalltalk mit dir und dem Rest, wenn du Lust hast
* auf den .NET Open Space kommen die richtigen Leute, denn es kommen nur die, die in den benannten Themenbereichen motiviert sind – der Rest bleibt Zuhause oder geht woanders hin
* am .NET Open Space kannst du teilnehmen, ohne ein Guru zu sein, deine Motivation zählt
* erachtest du dein Thema als wichtig, nimmst du eine mögliche Diskussion selbst in die Hand und findest interessierte Teilnehmer
* die Agenda wird von den Teilnehmenden zum Beginn des .NET Open Space selbst erstellt

Wir haben heute unsere Zimmer reserviert, Betten verteilt ;). Mit einem Wort: wir sind bereit!

Kommst du mit?

Comments No Comments »

Clean Code

Da es für einen Entwickler wichtig ist, sich ständig weiterzuentwickeln, sollte man sich durch Austausch mit anderen Entwicklern, aktives Programmieren oder eben Bücher weiterbilden. Das Buch, das ich gerade lese, heißt Clean Code von Robert C. Martin a.k.a. Uncle Bob. Ich bin momentan bei der Hälfte des Buches und muss sagen, dass ich von dem Buch ziemlich begeistert bin. Da ich denke, dass es vielen Entwicklern helfen würde, besseren Code zu schreiben, habe ich den Text ein wenig verkürzt und zusammengefasst – was natürlich nicht heißt, dass man dieses Buch nicht lesen muss. Meiner Meinung nach ist es absolute Pflichtlektüre für jeden Entwickler, der was auf sich hält.

Hier also meine kleine Zusammenfassung.

Kapitel 1 Clean Code

In diesem Kapitel wird beschrieben, was Clean Code ist und dass man „Clean Code“ schreiben muss, um sich selbst einen professionellen Softwareentwickler nennen zu dürfen. Was Clean Code ausmacht, hat Christina schon in ihrem Artikel „Clean Code Developer – The Yellow Brick Road of the Coder“ beschrieben. Außerdem wichtig sind :
LeBlanc’s Gesetz : Later equals never
und
die Boy Scout Rule : Leave the campground cleaner than you found it.

Kapitel 2 Meaningful Names

Benennung in einem Projekt ist sehr wichtig, sei es um das Gesuchte zu finden oder um den Sinn einer Variablen oder einer Methode ohne langes Überlegen zu erkennen. Man sollte bei der Vergabe von Namen so gründlich vorgehen, wie man es für seinen Erstgeborenen tun würde. In der heutigen Zeit ist die Ungarische Notation absoluter Quatsch. Die IDE kennt den Typ, warum sollte man das in den Variablennamen integrieren?

Kapitel 3 Funktionen

Die erste Regel von Funktionen lautet: Sie sollte klein sein.
Die zweite Regel von Funktionen lautet: Sie sollte noch kleiner sein als das.
Eine Funktion sollte nur eine Sache tun. Macht sie mehr als eine Sache, steigt die Komplexität. Und Komplexität ist schlecht.
Eine gute Benennung der Funktionen ist, wenn der Name beschreibt, was die Funktion macht. Dabei darf der Name ruhig lang sein, wenn es der Lesbarkeit des Codes dienlich ist.
Flagargumente sind verboten! Durch dieses Flag macht die Methode schon mehr als eine Sache und wir wären wieder bei der Sache mit der Komplexität. Böse.
Die ideale Anzahl von Parametern einer Funktion ist 0! Aber da nicht immer alles ideal laufen kann, sind 1, 2 auch okay. Aber mehr als 3 ist verboten. Okay?
Last but not least eine sehr wichtige Grundregel: Don’t Repeat Yourself!
Denn: Durch Verdopplung des Codes steigt der Wartungsaufwand proportional.

Kapitel 4 Kommentare

Kommentare sind schlecht, denn sie lügen! Ja, LÜGE! Code wird häufig verändert durch neue Anforderungen oder Refaktorisierungsmaßnahmen, der dazugehörige Kommentar aber meist nicht, wodurch schlechte bzw. in die Irre führende Kommentare entstehen. Es gilt also: Keine Kommentare sind besser als schlechte Kommentare. Man sollte die Zeit, die man für das Schreiben von Kommentaren aufbringen würde, lieber für die Refaktorierung der Methode verwenden. Denn Code sollte sich selbst erklären und ist außerdem die aktuellste Dokumentation. Nur schlechter Code muss kommentiert werden.
Auskommentieren des Codes ist verboten! Andere Programmierer, die den auskommentierten Code sehen, werden diesen nicht löschen, da sie denken, dass es einen Grund haben muss, dass er dort steht und dass er zu wichtig ist, um gelöscht zu werden. Somit bleibt dieser “Kommentar” auf ewig dort und müllt unseren “Clean Code” zu. Heutzutage muss man nichts mehr auskommentieren. Durch Versionskontrolle geht nichts mehr verloren.

Kapitel 5 Formatting

Eine perfekte Formatierung gibt es nicht, vielleicht für jeden Einzelnen, aber nicht für ein Team. Jeder hat seine Vorlieben. Letzendlich ist nur wichtig, dass sich das Team auf EINE Formatierung einigt. Jeder in diesem Team muss sich daran halten, auch wenn es für einen selbst nicht die optimale Lösung ist. Der Nutzen einer gemeinsamen „Sprache“ ist einfach zu groß, denn Kommunikation ist das A und O.

Kapitel 6 Objects and Data Structures

Es wird grundsätzlich zwischen Objekten und Data Structures unterschieden.
Objekte enthalten Businesslogik und sollten ihre interne Struktur nach außen hin verbergen, also keine Properties, welche die Member-Variablen des Objekts zurückgeben oder verändern lassen. Nur das Objekt selbst sollte seinen internen Status ändern können, wobei bei Objekten auf das Gesetz von Demeter zu achten ist:
Es besagt, dass Objekte nur mit Objekten in ihrer unmittelbaren Umgebung kommunizieren sollen.
Also:
Methode m der Klasse k sollte nur Methoden nutzen von:

  • k
  • Ein Objekt, dass von m erstellt wurde
  • Ein Übergabeparameter an m
  • Ein Memberobjekt von k

Data Structures sind zum Beispiel Data Transfer Objects, kurz DTOs. Das sind Klassen ohne Methoden, also reine Datenträger. Eine spezielle Form von DTOs sind Active Records. Diese Objekte haben Methoden wie Save() und Find(), enthalten jedoch keine Businesslogik.

Kapitel 7 Error Handling

Moderne Programmiersprachen haben ein Feature namens Exceptions. Das sollte man auch nutzen. Fehlercodes oder ähnliches sind veraltet. Eine gute Exception sollte allerdings so viel Information liefern, dass man auch ohne Debuggen den Fehler identifizieren kann, sonst kann man sich die ganze Mühe auch sparen.
Außerdem noch 2 wichtige Grundregeln:
Don’t Return null – somit wird es unnötig auf null zu prüfen
und
Don’t Pass null – null an eine Methode zu übergeben ist noch schlimmer als null zu returnen

Kapitel 8 Boundaries

Man sollte unbedingt das Adapterpattern anwenden, wenn man 3rd party Code verwendet. 3rd party code sollte an so wenig stellen wie möglich verwendet werden, um Abhängigkeiten zu vermeiden.

Kapitel 9 Unit Tests

Die 3 Gesetze von TDD:

  1. Man darf keinen produktiven Code schreiben, solange man keinen fehlgeschlagenen Unit Test geschrieben hat.
  2. Man darf nicht mehr als nötig schreiben, um einen Unit Test fehlschlagen zu lassen, und Fehler beim Kompilieren bedeutet einen fehlgeschlagenen Test.
  3. Man darf nicht mehr produktiven Code als nötig schreiben, um einen fehlgeschlagenen Test zu reparieren.

Außerdem gilt: Tests sollten genauso “Clean Code” sein wie produktiver Code. Tests sollten genauso evolvierbar sein. Denn wenn sich der Code verändert, muss sich der Test auch verändern.
Ein Test sollte nur ein Szenario abdecken – wieder das Thema Komplexität.

Clean Tests folgen noch 5 anderen Regeln:
Fast
Independent
Repeatable
Self Validating
Timely

Teil 2 gibt es hier

kick it on dotnet-kicks.de

Comments 5 Comments »