Zum Thema Code ReviewLob hören die meisten von uns gerne, Kritik am eigenen Code, oder Code für den man zumindest derzeit verantwortlich ist, kann problematisch sein. Sicher - jeder wird sagen er habe kein Problem mit "konstruktiver Kritik", aber selbst die konstruktivste Kritik kann am Gemüt nagen, wenn sie quantitativ bestimmte Grenzen überschreitet oder gar mit einer Prise Salz & Pfeffer vorgetragen wird. Daher ist es mir besonders wichtig hier ein paar Dinge so glasklar wie möglich
klarzustellen:
- FHEM ist ein großes und altes Projekt und funktioniert prinzipiell... prinzipiell gut. Selbst die schärfste Kritik an irgendeinem Aspekt kann nicht bedeuten "es wäre besser der Code wäre nie entstanden". Egal wie der Code jetzt ist - es ist besser als wenn er nicht wäre.
- Perl ist nur ein Tool. Wenn mir jemand sagt mein Perl Code ist doof, bedeutet das nur ich kann mit dem Tool (noch) nicht umgehen. Es ist vollkommen unabhängig von der Tatsache, dass ich in dem Bereich für den ich das Modul schreibe, durchaus absoluter Experte sein kann. Und darüber hinaus ein guter Artzt/Ingenieur/Manager/Steuerberater und überhaupt ein guter Mensch bin. Kritik - auch am eigenen Code - nicht persönlich nehmen!
- Der Verfasser dieser Zeilen hat die gewöhnungsbedürftige Eigenschaft gute Sachen als normal (nicht der Rede wert) anzusehen und konzentriert sich nur auf die problematischen Sachen. Dadurch kann der Eindruck entstehen "Alles sei schlecht". Dieser Eindruck täuscht - bitte sich ab und zu daran erinnern.
- Es ist keine Schande etwas nicht zu wissen/zu können. Es ist aber ein Problem nichts lernen/ändern zu wollen.
Merke: Ein Code Review und Kritik sind in erster Linie
Hilfe und kein Torpedo.
Zum Thema PerlPerl sei eine atiquierte Sprache. Es verleite zu schmutzigem Code, der früher oder später unwartbar wird. Es fehlten die ganzen Features moderner Programmiersprachen. Das und sicher noch einiges mehr wird man über Perl hören oder mal gehört haben. Keines dieser Vorurteile stimmt, aber es wäre jetzt müßig mit einer forensischen Widerlegung zu beginnen. Perl ist eine Sprache die - wie alle Sprachen - ihre Stärken und ihre Schwächen hat und daher für bestimmte Einsatzgebiete geeignet ist und für andere nicht.
Perl hat sich relativ früh den Spitznamen "Swiss-Army Chainsaw" (gemeint ist: Ein Schweizer Taschenkettensägenmesser) eingehandelt, oder auch "Perl the glue that holds the internet together" - also der Kleber, der das Internet zusammenhält. Diese Vergleiche kommen nicht von ungefähr: Perl redet mit allem und mit jedem - und gerne!
Für einen Anwendungsfall wie FHEM, wo man vielleicht eine heterogene Umgebung bändigen muss/möchte und in der mal eben Somfy mit HomeMatic und X10 und weissgottnochwasallem "reden soll" ... ist dieses Kettensägenmesser wie gemacht. Gute Wahl! Richtiges Tool!
"Ja der Code ist aber schlimm - deswegen sind wir ja hier!". Richtig. Es ist aber ein Trugschluss zu denken Perl hätte zu schmutzigem Code
verleitet. Man muss nur wissen wie man den Mustang zähmen kann. Wenn man das schafft, kann man mit ihm so manches Rennen gewinnen. Wenn nicht - kickt er einem die Zähne raus.
Zum Thema Perl und Zukunft in FHEMMan sieht FHEM sein Alter an. Ich denke, es macht keinen Sinn sich in dieser Hinsicht irgendwas vorzugaukeln. Man hat halt mal vor langer Zeit irgendwie angefangen mit dem was an Skills und Technologie da war, dann kamen weitere Mitstreiter, haben das was sie vorgefunden haben kopiert und angepasst ... naja und nun sind wir im Jahr 2020, haben ein Projekt das sich ca. um die 1 mio. Codezeilen bewegt und hinsichtlich Technologie und Architektur schon ziemlich festgefahren ist.
Es gibt nach qualifizierten Schätzungen Berufener so 20-30k FHEM User und da natürlich deren Umgebung - eval und Konsorten sei dank - ziemlich mit der internen Architektur von FHEM verquickt ist, sind grundlegende Änderungen die irgendwas bei den Nutzern kaputtmachen ein Minenfeld das es zu vermeiden gilt. Das Ziel kann aber nicht sein konservative "Besitzstandswahrung" zu betreiben und zuzuschauen wie die FHEM Nutzerbasis vielleicht gerade mangels Modernisierung immer kleiner wird bis sie irgendwann komplett sublimiert.
Anstatt also wie ein Kaninchen im Scheinwerferlicht zu erstarren, muss das Ziel vielmehr sein jedem bestehenden und jedem potentiellen künftigen Nutzer von FHEM eine langfristige Perspektive zu bieten: "Dieses Projekt lebt, es wird proaktiv weiterentwickelt (und nicht nur gepatched) und - warum nicht? - hat sogar Ambitionen zu einer führenden Smarthome Lösung zu werden." Das geht aber nur, wenn man am Puls der Zeit bleibt und der Puls der Zeit ist sicher kein Perl Code der Jahrtausendwende.
Würde ich mich für FHEM als Smarthome-Lösung entscheiden, "wenn sich da nicht mehr viel tut"? Sicher nicht.
Und hier kommt der alte Hase ins Spiel: "Der Puls der Zeit" ist auch nicht alles. Aktuelle hippe "modernste" Lösungen in Swift, Java/TypeScript die noch dazu von großen Firmen SIEM*hust*ENS gepusht sind, werden auch erst ihr implizites Wissen sammeln müssen (Coaty 2.0 gibt sich aufgeräumt:
https://www.heise.de/developer/meldung/Internet-der-Dinge-Coaty-Framework-2-0-gibt-sich-aufgeraeumt-4684445.html - wollen wir hoffen, sie sind dann nach 13 Jahren und bei Version 6.0 immer noch so aufgeräumt.)
Projekte wie FHEM startet man auch nicht neu auf der grünen Wiese. Die Arbeit, aber vor allem das implizite Wissen was in dem Code in über einem Jahrzehnt aufgebaut wurde, schüttelt man nie "auf Zuruf" aus dem Ärmel. Man kann jedoch FHEM Schritt für Schritt modernisieren.
Refactoring ist das Schlüsselwort.
Und wenn man dann behutsam Planke für Planke bei dem
https://de.wikipedia.org/wiki/Schiff_des_Theseus ausgetauscht hat, dann wird einem das Schiff nicht fremd - die morschen Planken sind aber weg. Das ist ein beträchtlicher Aufwand, vergleiche Restaurierung mit Neubau. Aber auch wenn die Phrase bereits von einer Dame in Führungsposition abgedroschen wurde - Ich bin der Ansicht "Wir schaffen das."
Thema: Ein paar Worte zur Motivation (Gelesen 5530 mal)