Dezember 2009 - Einträge

Auswertung Restriktiv vs. Robuste Entwicklung

Auf meinen Blogeintrag hin zu "Rebuste vs. Restriktive Programmierung", wo ich die Behauptung aufgestellt habe, dass es eine Frage des Charakters des Entwicklers sei, gab es mittlerweile mehr als 30 Fremdkommentare. Ein spannendes Thema, dass ich nun hier einmal zusammen fassen möchte.

Ausgangsthese war die Betrachtung des eigenen Programmierstils in Bezug auf Robustheit bzw. Restriktivheit von API-Methoden. Am Beispiel der Methode LoadCustomer(string alphaNumber), wobei die Kundennummer alphanumerisch sei, bedeutet Restriktiv (für mich wohlgemerkt), dass eine Methode nur dann einen Kunden findet, wenn die Kundennummer exakt übereinstimmt. Also keine Leerzeichen, kein null, Groß- und Kleinschreibung stimmt, alle Bindestriche und Sonderzeichen sind exakt eingegeben. In allen anderen Fällen wird eine Exception geworfen und der Kunde konnte nicht gefunden werden. Robust bedeutet, dass z.B. einfach mal Leerzeichen Links und rechts abgeschnitten werden, weil so die Chance, mehr Eingaben als gültig zu erkennen höher ist. Bei null gibts natürlich auch da ein Problem, aber Bindestriche könnte man z.B. auch ersetzen oder versuchen zu behandeln, wenn das Format der Nummer klar ist.

Es sei noch kurz erwähnt, dass ich oft mit Client-Entwicklung zu tun habe und deswegen oft von dem Szenario ausgehe, dass unter anderem Benutereingaben (bzw. ungeprüfte Eingaben woher auch immer) direkt an die API übergeben werden. Als Beispiele wurde zum Beispiel genannt, dass Controls.Add(null) oder label1.Text=null einfach nichts macht. Es stürzt nicht ab und wirft keine Exception, eine meiner Meinung nach sehr robuste und gute Entwicklungsweise.

Andere Beispiele für Restriktive Entwicklung wurden genannt, so zum Beispiel "simpler Datentyp".Parse oder auch alles was mit Sicherheit zu tun hat.

Zusammenfassend kann folgendes gesagt werden:

1. Alle beteiligten sind sich einige, dass, egal was auch immer eine Methode macht. Es muss irgendwo stehen und dokumentiert sein.

2. Eine Methode sollte im Namen schon soo viel wie möglich darüber aussagen, was sie auch tut. Als Beispiel hierfür gibt es die ganzen coolen ExtensionMethods, die da z.B. heissen First<>() oder FirstOrDefault<>(), wobei First eine Exception werfen kann (restriktiv) und FirstOrDefault einfach den Defaultwert zu dem Datentyp zurückgibt (robust). Namen wie "LoadCustomerByNumderOrDefaultAndTrimAndCaseSensitiveAndOtherSignsAreHandledToo" (ich übertreibe leicht), sind natürlich ungünstig.

3. Ein grober Nachteil meines Favoriten, nämlich der robusten Entwicklungsmethodik, ist der Fakt, dass unter Umständen Fehler "verloren" gehen könnten. Dabei sind sich auch alle einig, dass dies niemals der Fall sein sollte. Leere catch-Blöcke sind nur in Ausnahmesituationen ok und ansonsten sollte eine Exception, wenn sie schon nicht nach aussen weitergereicht wird, zumindest irgendwie irgendwo protokolliert werden. Andere Entwickler erkennen Fehler schneller und besser, wenn eine Exception geworfen und nach aussen gereicht wird.

4. Oft ist es eine Frage der Umgebung und der Anforderung, wie und wo eine API eingesetzt wird und ob sie sich an dieser Stelle restriktiv und robust verhalten soll. In Sachen Sicherheit sollte eine API immer restriktiv sein. Also hier kann nicht mal eben versucht werden, dem Benutzer unter die Arme zu greifen und seine Eingabe doch noch richtig zu interpretieren. Wenn ein Kennwort nicht exakt stimmt, dann ist es falsch. Das ist klar.

5. Es wurden einige Vorgehensweisen und Situationen genannt, die, wenn sie richtig durchgeführt und eingehalten werden, viele Fragen von vorn herein beantworten, damit nachher niemand da steht und nicht weiss, was er genau machen soll (und so vllt. eine Exception wirft oder auch nicht...). Ein Ansatz war immer vorher gut durchdachte Kontrakte zu erstellen, und wenn diese klipp und klar sind, dann stellen sich auch später keine Fragen wie :"Ja soll ich dem Benutzer nun unter die Arme greifen und Leerzeichen wegmachen bei der Eingabe einer Kundennummer???". Weiterhin wurde gesagt, dass, wenn alle Teammitglieder gut, oft, offen und ordentlich mit einander kommunizieren, es dann auch einfacher ist, Methoden die man geschrieben hat, für andere Entwickler bereitzustellen. Leider ist dieser Perfektionissmuss, der notwendig ist, damit wirklich immer alles glatt läuft, so wie es im Buche steht, oft nur Theorie. Die echte Praxis unterscheided sich aus vielerlei Gründen oft, was wohl jeder bestätigen kann, der schon in unterschiedlichen Projekten mit unterschiedlichen Kunden und unterschiedlichen Anforderungen gearbeitet hat...

6. Es kam heraus, dass die Mehrheit der Entwickler eher zur restriktiven Gruppe zählen würden, als zur robusten. Sie würden viel eher hier und da mal eine Exception mehr werfen, als eine zu wenig. Eine gute Alternative ist es aber, z.B. in seiner API einstellen zu können, ob man lieber ne Exception haben will oder nicht. So verhält sich die API entweder robust oder restriktiv.

7. So, im Endeffekt könnte man da bestimmt noch weiter diskutieren. Ich selbst habe mit meiner robusten Enwicklungsart mehr positive Erfahrungen gemacht als mit der restriktiven Variante und meine Kunden auch (Endbenutzer sowie auch andere Entwickler). Deswegen werde ich wohl dabei bleiben. Andere widerum haben genau andere Erfahrungen gemacht. Deswegen bleiben diese bei ihren Methoden. Wieder Andere sagen, wenn man sich überhaupt zwischen restriktiv und robust entscheiden muss (das macht man meiner Meinung nach aber auch oft im Unterbewusstsein), dann is schon von vorn herein irgendwas falsch.

Also die eine klare Endlösung gibt es nicht. Die Meinungen gehen auseinander aufgrund der Erfahrungen der Entwickler hier. Beide Versionen haben Vor- und Nachteile, wie Alles in der Welt. Wichtig ist nur, dass man sich überhaupt mal bewusst ist, dass es da einen Unterschied gibt und in welche Richtung der eigene Charakter aufgrund von Erfahrungen geprägt wurde...

Restriktiv vs. Robust

Hat sich schon mal jemand von euch Gedanken über Restriktive Programmierung vs. Robuste Programmierung gemacht? Dahinter stecken keine Pattern oder sowas, sondern Charaktere von Entwicklern.

Hinter restriktiver Programmierung steht ein Charakter der aussagt: "Ich will diese schlechte Welt verbessern".

Hinter robuster Programmierung steht ein Charakter der aussagt: "Ich lebe mit dieser schlechten Welt und mache trotz Fehlern weiter".

Wenn ihr also eine Methode entwickelt, die einige Parameter bekommst, zu welcher Art von Entwicklern zählt ihr euch? Seit ihr Entwickler, die bei jeder noch so kleinen Ungereimtheit sofort eine Exception werfen (das wäre die restriktive Variante) oder nehmt ihr die Parameterwerte, analysiert sie und versucht trotzdem, egal was da kommt, das beste draus zu machen (das ist die robuste Variante)?

Natürlich kann dies nie pauschalisiert werden, und natürlich spielen auch die Anforderungen eine Rolle, aber dennoch kann man, so denke ich, seinen Charakter einer dieser beiden Varianten zuordnen. Ich persönlich bevorzuge die Robuste Variante, denn so kann meine Methode von mehreren Entwicklern genutzt werden, und in den meisten Fällen kommt trotzdem das erwartete Ergebnis heraus. Und nur selten ertönt ein Stöhnen und die Worte "Oh man, was is denn nun schon wieder mit der Scheiß Methode? Kann die nich einfach mal funktionieren??” hehe

Ein Paradebeispiel is übrigens ein Parameterwert vom Typ string. Alle meine Methoden, die einen string erhalten, stürzen niemals ab, wenn z.B. ein null kommt (Es sei denn es ist so gewollt oder sowas). Ein null interpretiere ich eigentlich immer einfach als Leerstring. Aber es gibt auch viele Entwickler, die dann ne ArgumentNullException werfen (oder es erst gar nicht prüfen und in eine NullReferenceException laufen)... Das ist in meinen Augen eine falsche Einstellung. So nach dem Motto: "Och nö, ich mag jetzt nicht nachdenken, ich werf einfach mal ne Exception, sollen die anderen mal drüber nachdenken, und wenn ich nich exakt genau das bekomme, was ich haben will, ja dann bin ich halt bockig..." hehe

 

Was meint ihr dazu? Schreibt mal eure Meinung dazu. Ich denke, in dieser Sache einige andere Sichtweisen könnte meine eigene Sichtweise stark erweitern…

.NET Tipps (Teil 1/n)

Nun wo ich endlich meinen neuen Blog habe, möchte ich meine .NET-Tipps-Sammlung erneut aufleben lassen. Selbst wenn man jahrelang mit dem .NET-Framework gearbeitet hat, gibt es immer wieder Ecken, wo man vorher noch nie drin war. Tipps und Tricks, die man im Laufe eines Entwicklerlebens mal so nebenbei herausfindet, sind oft mit die wertvollsten Informationen, weil sie entweder die tägliche Arbeit erleichtern, oder Antworten geben auf Dinge, "die man schon immer mal wissen wollte"...

Ich hab mir mal ein paar Kleinigkeiten herausgesucht, die vllt. noch nicht jeder weiß, und die man einfach wissen sollte. Leider merkt man, wenn man jahrelang als Entwickler arbeitet, manchmal schon gar nicht mehr, was man vllt. so noch nicht wissen könnte.

Zusammenfassung am Anfang

Falls jemand meine ganzen Aus- und Abschweifungen oder Sonstiges nicht lesen mag, für den hier kurz und knackig die Tipps zusammengefasst. Für Erklärungen musste dann aber doch unten lesen :-)

 

System.Reflection.MethodBase.GetCurrentMethod();
newItem = oldItem ?? new ItemClass();
using WCF = System.ServiceModel.Channels;
string.IsNullOrEmpty()
System.Threading.Interlocked
System.Security.SecureString
GC
employee.Work += employee_Work;
System.Math.Max(myIntValue, 1);

 

So, nun mal noch zu den einzelnen Punkten:

Infos zur Klasse MethodBase

Habt ihr gewusst, dass es in der Klasse MethodBase eine statische Methode gibt, die da heißt "GetCurrentMethod()"??? So kann man nicht nur die aktuelle Methode und das Objekt herausfinden, in der oder in dem man sich gerade befindet, das coole an dieser Methode ist, dass sie auch für statische Klassen funktioniert.

Der ??-Operator

Kennt ihr schon den ??-Operator? Dieser Operator prüft den linksstehenden Term auf null. Ist der null, so wird der rechte Term zurückgegeben. Ist in dem kleinen Beispiel hier oldItem = null, dann wird new ITemClass() zurückgegeben, ansonsten, wenn oldItem ein gültiger Wert ist, wird oldItem zurückgegeben...

newItem = oldItem ?? new ItemClass();

DateTime.Now

Das wissen wahrscheinlich die meisten, aber ich sags trotzdem. Wenn nur ein einziger dabei ist, ders noch nicht weiß, hat es sich gelohnt. In DateTime.Now findet man die aktuelle Uhrzeit mit dem aktuellen Datum.. :-)

Using-Alias

Manche Entwickler binden mit Absicht die usings nicht ein, weil “man so ja sofort sieht, woher die Klasse kommt”. Diese Argumentation kann ich teilweise nachvollziehen, deswegen könnte man anstatt immer den gesamten WCF-Namespace auszuschreiben, einfach das hier nutzen: “using WCF = System.ServiceModel.Channels;”

IsNullOrEmpty in System.string

Die Klasse string beinhaltet eine statische Methode namens "IsNullOrEmpty". Viele wissen nicht, dass strings auch null sein können. Wenn man z.B.

string name;

name.Lenght

macht, so schmiert einem sein Progrämmchen ab. Und einfach nur auf "" prüfen is auch nich so dolle. Viel sicherer ist if(string.IsNullOrEmpty(name)), dann... erst weitermachen. Im übrigen gibt es auch string.Empty. Das ist ein Leerstring, vergleichbar mit "", aber sauberer ist es, string.Empty zu nutzen.

Atomare Methoden der Interlocked-Klasse

Wer viel mit Threads programmiert, sollte die Interlocked-Klasse kennen. Sie beinhaltet atomare Methoden, also Methoden, die nicht unterbrochen werden können. Es ist ja so, dass so ein simples "i++" keine atomare Methode ist. Es sind mehrere Registerumräumungen nötig (sichern, inkrementieren, zurückschreiben). Wenn dabei ein anderer Thread dazwischenhaut, arbeitet der vllt. auf einem falschen Wert. Deswegen lieber das Inkrement der Interlocked-Klasse nutzen, damit passiert das nicht.

SecureString für sichere Strings im Speicher

Ihr wollt eine Anwendung schreiben, wo man auch mal ein Passwort im Speicher halten möchte? Um es möglichen Angreifern wenigstens ein wenig schwerer zu machen, gibt es die Klasse "SecureString" im Security-Namespace. Damit wird der String verschlüsselt im Speicher abgelegt... Kann manchmal bestimmt nicht schaden.

Ein wenig Garbage Collection 

Mit "GC" kann man einfach mal eben so auf den GarbageCollector zugreifen. Der sammelt die alten toten Objekte ein. Hier kann man das Einsammeln manuell starten, oder auch festlegen, dass Objekte nicht eingesammelt werden sollen.

1.0 == 0.9Periode9 = true... ???.   <-- Hää?

Zu guter letzt. Habt ihr gewusst, dass die beiden folgenden Ausdrücke genau das Gleiche sind?
"eployee.Work += new EventHandler( employee_Work );"
und
"employee.Work += employee_Work;"
Ja, doll. 1 ist ja auch exakt das gleiche wie 0,9Periode9... aber wir wollen ja nicht mit Mathematik anfangen...

Na wenn wa eh gerade bei Mathe sind

Schaut euch mal um in der Klasse “System.Math”. Die beinhaltet sehr viele statische Methoden, die auch nützlich sein können, wenn man keine mathematische Anwendung schreiben will. Zum Beispiel habe ich eine int-Property, die aufgrund von Konventionen immer mindestens 1 zurückgeben muss. Also return System.Math.Max(myIntValue, 1);

Nico Franze Herzlich Willkommen auf meinem Blog. Ich bin Nico, freier Softwareentwickler sowie Autor für Fachzeitschriften. Hab mit .NET Version 1.0 begonnen (damals noch VB.Net) und bin dann schlussendlich bei C# gelandet. Mehr Infos gibts unter www.nfranze.de


Suche

Los

Translator Widget

Dieser Blog

Syndikation


Locations of visitors to this page