Ein paar Worte zur Motivation

[RichardCZ]

Zum Thema Code Review

Lob 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 Perl

Perl 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 FHEM

Man 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."

[KölnSolar]

nach den ersten 3 Sätzen hab ich aufgehört zu lesen.....

Du gehst einen falschen Weg. Hier zig Post wg. Perl zu machen ist völlig fehl am Platze. Ich werde mir weder ein Buch dazu kaufen, noch sonst meine Zeit, Perl in Perfektion zu lernen, verplempern. Erst gar nicht Deine Vielzahl von Posts lesen und meine Freizeit damit verbringen sie zu verstehen, geschweige denn umzusetzen.

Ich habe bisher Deine Posts immer überflogen, aber da platzt einem ehrlich gesagt der Kragen. Nicht weil Du Dich vielleicht tatsächlich mit Perl am besten auskennst und in der Sache recht hast, sondern wegen der Arroganz, die in JEDEM Deiner Posts mitschwingt.

Und nicht dass Du denkst, ich würde Dir bzgl. "alte Zöpfe abschneiden" nicht zustimmen, aber der von Dir gewählte Weg wird bei den meisten Entwicklern nicht funktionieren(hat Dir schon mal jemand geschrieben).

Wenn Du also wirklich helfen willst, dann schlage ich Dir vor, ein umfangreiches Mustermodul zu schreiben, am besten ein zweistufiges. Das guckt sich sicherlich jeder gerne an, um für sein nächstes Modul eine bessere Basis zu haben oder auch mal reinzugucken, wenn er gerade mal Zeit hat sein Modul, was das Coding anbelangt, zu überarbeiten.
Dazu überarbeitest Du noch die DevelopmentGuidelines oder schreibst eine PerlGuidlineforDummies mit do's and dont's.
Einen Entwurf kannst Du dann zur Diskussion stellen, wobei, es weiß ja eh keiner besser als Du.

Und vielleicht legst Du Dir mal eine FHEM-Installation mit einer 3-stelligen Anzahl devices zu. Dann verstehst Du möglicherweise was FHEM ist, was die Entwickler bewegt ein Modul zu schreiben. Glaub mir, die meisten würden es lieber erst gar nicht in Perl tun..., aber das ist (leider) der Ursprung.

Und noch ein Vorschlag: Warte in Deinem neuen Unterforum bis ein Entwickler mit einer konkreten Frage an Dich herantritt, weil ein User in seiner besonderen OS-Perl-FHEM-Umgebung(und da kommt dann noch Python, node ... dazu) ein Problem hat, welches bisher nie aufgetreten ist und möglicherweise durch schlechte Perl-Programmierung in der ganz bestimmten Umgebung verursacht wird. Er wird dankend Deinen Rat für eine Umprogrammierung annehmen. Aber warum soll ich Stunden verbringen Deine ganzen Posts zu lesen, obwohl kein User ein Problem hat ? Anders ausgedrückt: die User sorgen mit ihren Fehlermeldungen dafür, dass in der Regel die Module perfektioniert werden. Nicht bzgl. Perl, aber in ihrer Funktionsweise.

Und bitte antworte mir erst gar nicht. Mein Post ist meine Meinung und die ist nicht zu diskutieren, sondern nur zur Kenntnis zu nehmen und zum drüber nachdenken.

Grüße
Markus

[RichardCZ]

Ich bin so frei und antworte doch. Denn erstens darf ich das und wenn ich nach den ersten drei Sätzen aufgehört hätte zu lesen,
wäre mir die Aufforderung eh entgangen.

Du tönst also darüber was Du in Deiner Freizeit nicht machen wirst. Du urteilst darüber was an dem falsch ist was ich in meiner Freizeit mache.
Du hast eine Meinung über die man nicht diskutieren kann/sollte.

Ich entferne den verbalen Entgleiser. Es wurde darüber bereits mit Richard gesprochen.

Grüße
Marko (CoolTux)

---

Mustermodul, FHEM-spezifische Coding guidelines - ja, aber nicht morgen, das müssen wir uns (mich eingeschlossen) echt erst erarbeiten.
Nein, das ist nicht so, dass es keiner besser weiß als ich. Gerade weil ich (noch?) keine 10 Jahre FHEM Erfahrung auf dem Buckel habe.

Ich gehe schon davon aus, dass der Weg ein gemeinsamer ist. Ich gebe Perl KnowHow weiter, ich nehme FHEM KnowHow auf...
bin ja noch nicht einmal der Ansicht, das Perl KnowHow sei die wichtigere Komponente - denn wie schon geschrieben: FHEM tut ja (auch so).

Und wie ich in meiner Freizeit an anderer Stelle schrieb (aber da hast Du in Deiner Freizeit nicht die Zeit für), schreibe ich jetzt in meiner Freizeit nochmal: Es gibt keine Pflicht. Wer nicht will, muss nicht. Im Zweifelsfall einfach die Perl Ecke oder meine Posts meiden.

[KernSani]

Lieber Richard,

Ich weiß deine Bemühungen wirklich zu schätzen und ich glaube auch dass hier viele (mich eingeschlossen) sehr viel lernen können. Wenn du aber nicht anfängst dich ansatzweise sozialverträglich zu verhalten fürchte ich, dass das nix wird...

Grüße,

Oli

Edit: https://forum.fhem.de/index.php?action=rules;sa=additional

[RichardCZ]

Ansonsten verweise ich auf https://forum.fhem.de/index.php/topic,109515.0.html

[CoolTux]

Ich schließe den Thread. Ich denke was gesagt wurde wurde gesagt.

@Richard
Wenn Du hier noch was schreiben willst kannst den Thread natürlich gerne wieder auf machen.

Ich bin neu im Moderatorgeschäft. Daher übe ich auch noch.



Grüße