ReFUCKtoring

Nach 110 Beiträgen auf phphatesme.com solltet ihr jetzt die ein oder anderen Regel für schönen Code mitgenommen habe. Vielleicht habe ich auch die Liebe zur Softwaretechnik bei euch entfacht.

In der Uni wird einem erklärt, dass Testen der einzige destruktive Prozess im Softwareentwicklungsprozess ist. Dem stimme ich nicht zu, denn das gute alte ReFUCKtoring gibt es ja auch noch. Was, ihr kennt ReFUCKtoring nicht? Unglaublich! Naja, ich glaube auch nicht, dass es den Audruck in irgendeinem Wörterbuch gibt und wahrscheinlich stellt sich da auch jeder etwas anderes darunter vor. Aber ich will heute mal meine Definition dieses Begriffes zu “Papier” bringen.

ReFUCKtoring ist neben Testen, die einzige destruktive Tätigkeit, in der modernen Softwaretechnik. Es hat sich zum Ziel gemacht architektonisch einwandfreien Code zu unterwandern, um seine Kompatibilität und Qualität zu minimieren. Dabei werden Techniken wie Copy & Paste, Anti Pattern und gewöhnlichen Frickeln angewendet um sicherzustellen, möglichst einfache Strukturen aufzublähen und für die Nachwelt unbrauchbar zu machen.

Ich sollte echt beim Duden anfangen. Eine bessere Definition kann man glaube ich kaum schreiben. Ich will ReFUCKtoring aber mal ein einem einfachen Beispiel vorstellen. Nehmen wir an, wir haben ein Blogsystem und wollen es um eine bestimmte Funktion erweitern. Ganz wichtig dabei ist, dass wir uns kein bisschen mit der Architektur des Systems auskennen und wir auch keine Lust haben dies zu ändern. Ok, suchen wir eine Stelle, wo wir unser Feature unterbringen können. Der Code wird natürlich direkt in die vorhandenen Klassen geschrieben; wir wollen ja sichergehen, dass wir kein Update mehr fahren können. Updates sind nämlich etwas für Warmduscher und C++ Entwickler. Ganz angenhnem ist es auch die Logik einfach in die View zu schreiben, denn meistens braucht man ja ein Feauture genau dort. Dokumentation sollte auch nicht vorhanden sein, denn einer unserer wichtigsten Programmierparadigmen lautet: If it was hard to write, it should be hard to read. So ich glaube, wir haben jetzt genügend Schaden angerichtet. ReFUCKtoring vollendet.

Leider habe ich schon sehr viele Projekte gesehen, in denen dies genau so funktioniert hat. Aber wir haben ja alle mal klein angefangen.

4 Kommentare »

• 
  

  Peter Rother

  am 21. November 2008 um 09:45 Uhr

  Hallo Nils,

  genau dieses habe ich leider auch schon bei viel zu vielen Projekten gesehen und muss auch zugeben dies selber am Anfang so gemacht zu haben (wer nicht?). Aber irgendwann sollte und muss man als Programmierer doch ein bißchen dazu lernen, was aber nicht immer vorkommt und die Leute diese Angewohnheit bei behalten.

  Das Wort “ReFUCKtoring” geht jetzt übrigens in meine Wörter des Jahres Liste mit ein.

  Gruß
  Peter

• 
  

  test

  am 21. November 2008 um 14:17 Uhr

  Die Aufgabenstellung, Lösungen und Ziele des Codes sollten nicht im Vordergrund stehen, das wäre oberflächlich und nicht zeitgemäss. Vielmehr sollte es ein 100 % test-driven, beautiful, well documented Code mit mindestens 0.1358 % Effektivität/Nutzen sein.

• 
  

  Nils Langner

  am 21. November 2008 um 16:40 Uhr

  @test, klingt toll … hab aber kein Wort verstanden.

• 
  

  Nils Langner

  am 24. November 2008 um 07:32 Uhr

  Irgendwie habe ich das Gefühl, dass ich wirklich der erste bin, der diesen Ausdruck im deutschen Raum geprägt hat. Zumindest ist es der einzige Eintrag, den man in google finden kann.

RSS-Feed für Kommentare zu diesem Artikel. TrackBack-URL

Einen Kommentar hinterlassen