Sisyphos, DRY oder auch „nicht nochmal“!

Moment, das habe ich doch schon mal erklärt, Variablen sind so zu benennen, dass man erkennt worum es geht. Ableitungen von Klassen sind zu vermeiden und überhaupt, warum wird die Customer-Klasse von außen verändert?

In Code Reviews sind es oft die gleichen Dinge die besprochen werden. Die gleichen Designprobleme werden gefunden, und ebenso auch die gleichen Bugs. Das macht mich Müde, das laugt mich aus; wohingegen mir das am Anfang noch Spaß gemacht, einem „Junior Software Developer“ Dinge zu erklären. Ich  lernte vieles aus den Gesprächen, fands cool und das fühlte sich gut an. Aber das ist lange her, heute nervt es mich nur noch das zum 100ten mal zu erklären.

Nach einigen Jahren des Code und Architekur reviewens ist jetzt Schluss, aus, Basta. Ich werde diese Themen nicht mehr besprechen, keine Zeit verschwenden, sondern nur den Link zu weiter führenden Informationen weitergeben.

Ich wünsche mir ein gemeinsames Verständnis, ein gewisses grundverständnis wo wir als Entwickler stehen level, wo ich weis was ich zu erwarten habe und was nicht. Klar, dass der Student nur wenig Erfahrung hat und in der Regel noch klassische Vererbung nutzt. Aber es gibt ebenso Entwickler mit jahrelanger Erfahrung, die das auch tun. Sie haben Bücher gelesen und leben nach diesen, obwohl diese schon lange „überholt“ sind.

Ich habe die Punkte zusammengefasst, welche meistens Diskutiert werden. Das ist alles nichts neues, daher habe ich entsprechende Referenzen eingefügt.

Wartbarkeit macht langfristig glücklich.

Einer der wichtigsten Aspekte ist heutzutage die Wartbarkeit, da im Regelfall aufgrund der heutigen Hardware nicht mehr auf Code Performance Optimierung geachtet werden muss und auch die aktuellen Compiler ein großen Beitrag dazu steuern.

1. Premature optimization is the root of all evil (or at least most of it) in programming.
   https://en.wikiquote.org/wiki/Donald_Knuth
2. https://www.codeproject.com/Articles/547/Optimization-Your-Worst-Enemy
3. Compilers are awesome

Es gibt immer eine einfache Lösung, nur das Finden der Lösung ist schwer.

Code soll sich selbst erklären und selbst eine Laie,  soll in der Lage sein den Code korrekt zu interpretieren.

var SalesPrice =
  new HighestPrice(
    new SalesPrices(
      new ValidPrices(
        new Prices(
          new List<Prices>(){
            new ExchangePrice(
              new PriceFromString("190.00 USD"),
              new ForexExchange(),
              Currency.EUR
....      
new SalePrice

Standards braucht jeder, Coding Guidelines.

Erfinde das Rad nicht neu, nutze den bestehende Standard:

1. Microsoft Coding Conventions
   https://docs.microsoft.com/de-de/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
2. Microsoft Naming Guidelines
   https://docs.microsoft.com/de-de/dotnet/standard/design-guidelines/naming-guidelines
3. StyleCop
4. FxCop
5. StyleCop Fixer
6. Gendarme
7. Code Complete – https://www.amazon.de/dp/0735619670/ref=cm_sw_em_r_mt_dp_U_wN9RBbC7BVS04

P.s. wir prefixen interne Felder mit „_“ und Ausnahmen gibt es immer von der Regel.

Nur einer machts, und nur der darf das und machts auch richtig, Simple Responsibility Principle.

1. https://codeburst.io/understanding-solid-principles-single-responsibility-b7c7ec0bf80
2. https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137

Verstehe wie deine Programmiersprache funktioniert

Bleib am Ball, schau dir immer die Neuerungen deiner Programmiersprache an: https://channel9.msdn.com/Events/Build/2018/BRK2155.

1. C# Language Specification (ECMA-334.pdf)
2. Lies Bücher zum Thema Beispielsweise CLR via C#

Weniger ist mehr

Weniger Code == weniger Fehler == weniger zu lesen == schneller verstehen.

Private CacheItem CachedItem(Func<T> generator)
{
  if (_cache == null)
  {
    _cache = new CachableItem<T>(generateFunc());
  }
  return _cache;
}

Besser

Private CacheItem CachedItem(Func<T> generator)
  => _cache 
  ?? (_cache = new CacheableItem<T>(generateFunc()));

Namen und Methoden und Funktionen (Builders and Manipulators)

// Builder
Public string StringWithoutNumbers(string) ...

// Manipulator
Public void string RemoveNumbers(ref input) ...

Konstanten und Readonly, Versichere dich.

Benutze const und readonly wo immer es Möglich ist. Die Verwendung der entsprechenden Keywords erleichtert die Wartung dadurch, das explizit klar ist: Ich werde nicht verändert, ich bin immer so!

Variablen im generellen, sind ein Notbehelf

Je mehr Variablen vorhanden sind, desto höher ist das Risiko das die Wartbarkeit darunter leidet. Ebenso wie der Computer sich Speicherbereiche für Variablen „merken“ muss, ebenso  müssen wir dies auch tun.

Wenn wir schnell über den Code schauen, wollen wir uns so wenig wie möglich merken. Daher je weniger Variablen vorhanden sind, desto lesbarer ist der Code. Desto wenige Variablen müssen gepflegt werden.

Variable sind nur dann zu verwenden wenn dinge wiederverwendet werden sollen.

1. http://blog.ploeh.dk/2011/05/24/DesignSmellTemporalCoupling/
2. https://www.yegor256.com/2015/12/08/temporal-coupling-between-method-calls.html
3. https://techbeacon.com/why-unnecessary-variables-are-bad-your-code
4. https://www.yegor256.com/2015/09/01/redundant-variables-are-evil.html

Zu viele Parameter sind Böse

Es gibt keine offizielle Zahl, aber mehr als fünf Parameter ist ein Indikator für ein schlechtes Design.

Meist sind die gehörigen die übergebenen Parameter fachlich zusammen

public class Line(int startX, int starty, int endX, int endX)

Im Beipiel ist zu erkennen das startX und startY fachlich zu Point zusammengefasst werden kann.

public class Line(Point start, Point end)
...

public class Point(int x, int y) {
   ...
   Line line(Point endPoint)
}

Keine Verschachtelungen. Don‘t nest, return early

Verschachtelungen sind zu vermeiden, ein bekanntes Synonym dazu ist Pyramid of Doom, er steht für schlechtes Design. Je tiefer die Abfragestruktur, desto häufiger entstehen Fehler. Je komplexer sind die Testfälle die getestet werden müssen.

• https://softwareengineering.stackexchange.com/questions/18454/should-i-return-from-a-function-early-or-use-an-if-statement
• http://blog.timoxley.com/post/47041269194/avoid-else-return-early

Benutze Immutable objects

Objekte dürfen sich nach der Instanziierung nicht mehr verändern, damit ist der Satus der Instance immer identisch und klar vorhersehrbar, bzw. gleich. Nutze wo immer es geht immer Immutable Objects.

Dokumentiere deinen Code und deine Architektur

Nutze Anmerkungen

In dieser hierarchy:

1. Software System und die dazugehörigen use Cases
2. Kontainer Übersicht
3. Komponenten
4. Klassen

1. Visualize, Document, and Explore Your Software Architecture
   https://academy.realm.io/posts/gotocph-simon-brown-visualize-document-explore-your-software-architecture/

2. https://leanpub.com/u/simonbrown

Fail  fast, bewahrt dich davor episch zu versage

1. https://www.forbes.com/sites/sunniegiles/2018/04/30/how-to-fail-faster-and-why-you-should/#46c35948c177
2. https://dzone.com/articles/fail-fast-principle-in-software-development

Testen ist noch schwieriger als nur programmieren

Daher rechne damit das es mehr Zeit kosten wird, dein Code so zu schreiben, dass dieser überhaupt vernünftig getestet werden kann.

Sei Explizit und niemals implizit

Wenn Methoden oder Funktionen Dinge tun, dann muss die explizit erkennbar sein.

Das macht dich erfolgreich

1. 1. Lerne
      Hol dir immer aktuelle Informationen, abonniere Kanäle in verschiedenen Netzwerken. Suche Leute mit denen du dich über die Themen unterhalten kannst. Besuche Meetups, Konferenzen oder Organisiere selbst treffen. Lerne neue Programmiersprachen, APIs und Frameworks kennen.
   2. Lese
      regelmäßig und nimm dir dazu Zeit, plane Zeit ein um dich weiterzubilden. Schau dir Code von erfolgreichen Projekten an. Verfolge Bugs und wie diese gelöst wurden.
   3. Kümmere dich
      um die Leute die deinen Code verwenden und weiterentwickeln werden. Denke schon bei der Erstellung an sie, sie werden dein Code lesen und müssen ihn verstehen.
   4. Teste
      und probiere Dinge aus
   5. Kommuniziere
      dein Wissen, Blogge, Tweete was das Zeug hält. Frage Leute warum sie Ihren code so geschrieben haben und versuche es zu verstehen.