Die Frage ist nicht wirklich, ob Metaprogrammierung in Ordnung ist oder nicht, sondern ob es in Ordnung ist, besser zu sein als die anderen im Team. Hier sind ein paar kontroverse Punkte, wie ich es sehe ...
Ich bin kürzlich zu einem neuen Job gewechselt, bei dem ich in einem größeren Team arbeite, und diese [Meta-Programmierung] beunruhigt einige meiner Kollegen, weil sie es nicht verstehen.
Sie haben Angst, dass du besser bist als sie. Das ist gut. Du wirst der neue Experte sein. Sie haben gerade ihre Status-Quo-Welt zerstört.
Ich versuche immer, das volle Potenzial der Sprache auszuschöpfen, aber einige (nicht alle) meiner Kollegen sehen dies als Risiko an (einige begrüßen den Ansatz).
Sicher, niemand mag es, weniger geschickt zu sein als jeder andere. Deshalb versuchen sie, Sie davon abzuhalten, Techniken anzuwenden, die für ihn zu komplex sind. Sie können es entweder nicht verstehen oder werden es nicht verstehen, weil sie sich jetzt sicher fühlen.
Ich bin damit einverstanden, dass es ein Problem ist, Code zu schreiben, den niemand im Team verstehen kann.
Ich nicht. Ich denke, es zeigt Ihr Fachwissen.
Meine Frage ist, wer hat Recht, was soll ich tun?
Sie sollten alle Ihre Fähigkeiten nutzen, um den besten Code zu schreiben, den Sie schreiben können, und nicht auf diejenigen schauen, die ihn nicht verstehen. Andernfalls bleiben Sie auf ihrem Niveau stecken und sind nur ein gewöhnlicher Programmierer. Es ist gut, besser zu sein als andere, und es ist gut, sich zu bemühen, besser zu sein als sie. Sie werden nie neue Erfahrungen sammeln, wenn Sie nicht versuchen, etwas Neues zu verwenden oder Dinge anders zu machen.
Ich weiß, dass ich abgelehnt werde, aber so sieht es aus. Es ist kein Verbrechen, besser als andere im Team zu sein, und es ist kein Verbrechen, seine Fähigkeiten einzusetzen. Es ist nur so, dass jeder Angst hat, es zuzugeben ... weil sie auf der unqualifizierten Seite sind und es hassen, dass der Neue plötzlich etwas kann, was sie nicht können. Wenn sie klug wären, würden sie Sie um Hilfe und Rat bitten und Ihren Code nicht als unverständlich kritisieren.
BEARBEITEN
Es scheint viel Verwirrung um diese Frage zu geben. Wie die Kommentare zeigen, denken viele Menschen, dass es um die allgemeine Lesbarkeit von Code geht. Nein, ist es nicht. Es geht darum, ob bestimmte Sprachmerkmale / Konstrukte verboten oder vermieden werden sollten, weil einige Teammitglieder sie nicht verstehen.
Meine Antwort ist nein . Sie sollten nicht verboten werden. Wenn du etwas verbieten willst, wie würdest du das tun? Sie müssten eine Art Fragebogen erstellen, um herauszufinden, was Ihre Teammitglieder können und was nicht - oder besser gesagt, nicht lernen wollen, da ich denke, dass alle sprachlichen Funktionen irgendwo nützlich sind. Daher ist es immer wichtig, sie zu kennen und sie zu verwenden Gut und je mehr Sie wissen, desto besser ist der Code, den Sie schreiben können. Sie benötigen auch eine Skala, um zu definieren, welche Funktionen Anfänger, Mittelstufe oder Fortgeschrittene sind.
Um zu demonstrieren, wie albern solche Einschränkungen sind, nehmen wir ein wirklich einfaches Beispiel: Sie werden als Softwareingenieur eingestellt, aber Ihr zukünftiger Chef teilt Ihnen mit, dass Sie keine do/while
Loops verwenden dürfen, weil ein paar Leute anwesend sind Das Team, das sie noch nie benutzt hat und auch nicht benutzt hat, weil sie immer for
Schleifen für alles benutzt haben, sodass sie do/while
Schleifen verwirrend finden.
Jetzt denkst du, das ist dumm und verrückt, nicht wahr? Das verbietet aber auch andere Funktionen. Einige Leute können sie benutzen und andere wollen sie nicht lernen.
Warum sollten Sie schlechteren Code produzieren, wenn Sie wissen, dass es etwas gibt, das es Ihnen ermöglicht, dasselbe mit viel weniger Aufwand zu tun und dennoch zu einem viel besser lesbaren, robusten Code zu führen?
Unabhängig davon, ob Sie nur grundlegende oder fortgeschrittene Sprachfunktionen verwenden, können Sie mit einer dieser beiden Funktionen einen ebenso unkomplizierbaren wie nicht verwaltbaren Code erstellen. Dies ist also ein völlig anderes Thema.