Indikator #1 Zu lange Methodennamen

Zum einen macht es Sinn, Methoden einen sprechenden Namen zu geben. Der Methodenname muss dabei beschreiben was die Methode macht, und es tunlichst vermeiden funktionalitäten zu verstecken. Beispiel:
class Items : IItems<IItem> {
   /* Manipulator -> Verb */
   void Remove(IItem item) {...
   
   /* Builder -> Noun */
   Item Item(ISelector selector) {...
   
   /* A code smell -> does too many things */
   Item ChangeDeliveryDateAndSaveItem(IItem source) {... 
}
Den Gedanken im Kopf, passiert es, das Methoden sehr lange Namen bekommen können. Wenn man nun als Entwickler in der Situation ist und das bemerkt, fängt man an zu überlegen, wie man ihn kürzen kann. Manchmal löst man das Problem durch bessere Namensgebung, aber oftmals liegt das Problem nicht im Methodennamen, sondern in der Klasse selbst. Muss man mehrere funktionalitäten Beschreiben, ist es vermutlich die Klasse die zu viele Dinge tut. Im Beispiel oben, führt das zu mehreren Problemen: 1. IItems wird um methoden immer weiter erweitert und damit erschwert sich deutlich der Zukünftige testaufwand der Klasse. 2. Die Anpassungen an IItems sind spezifisch für den Fall, und eine Wiederverwendung ist immer unwahscheinlicher um so mehr Methoden enthalten sind. Im schlimmsten Fall führt es dazu, dass das Interface mit vielen NotImplementedExceptions genutzt wird. 3. Wird die Klasse bzw. das Interface um weitere Methoden erweitert, so leidet auch die Wartbarkeit. Oftmals sind es Methoden mit Rückgaben, die erklären was verändert wird und was zurückgegeben wird. Hier auch mit alternativen:
String StringWithRemovedCarriageReturnAndLineFeeds() {...

/* Alternative I */
new ModifiableString().RemoveAll(„\r\n”)

/* Alternative II */
new ClearedString {
 public ClearedString(
   string source,
   string valueToRemove
) { ...

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.

„Sisyphos, DRY oder auch „nicht nochmal“!“ weiterlesen