すべての同僚がメタプログラミングを理解していなくても、メタプログラミングを使用しても大丈夫ですか？
反復的なタスクを回避し、より安全に使用できる抽象化を構築するために、多くのメタプログラミングを採用しています。
最近、私はより大きなチームで作業している新しい仕事に移りましたが、同僚が理解していないため、同僚の何人かが心配しています。
私は常に言語の可能性を最大限に活用しようとしていますが、同僚の一部（全員ではない）がリスクとして認識しています（一部はアプローチを歓迎します）。
チームの他の誰も理解できないコードを書くことが問題であることには同意します。一方、私たちはすべてプロのC++開発者であり、クラスを使用してCを作成するよりも高い水準を目指すべきだと思います。
私の質問は、誰が正しいのか、どうすればよいですか？
説明：言語の可能性を最大限に活用しようとしても、すべての問題でTMPをスローするわけではありません。 C++はツールボックスであり、私にとってC++の習熟度は、すべてのツールをボックスから使用できることと、特定のジョブに適したツールを選択することです。
メタプログラミングはOKです。あなたがやろうとしていることは大丈夫ではありません。
私は仕事でいつもメタプログラミングを使用しています。これは、より読みやすく保守しやすい方法で多くのことを実行するために使用できる強力なツールです。それはまた、そこにあるプログラミングのスタイルを理解するのが難しいので、本当にそれを維持する必要があります。 1000行のコードを50行に削減できるのが好きですが、そのように制限しようとしています。
問題はメタプログラミングではありませんが、これは：
一方、私たちはすべてプロのC++開発者であり、クラスを使用してCを作成するよりも高い水準を目指すべきだと思います。
ここで問題が発生します。あなたは意見を持っています。メタプログラミングが良いとの意見を持っていることは問題ありません。私たち全員がより優れたC++開発者になることを目指すべきであるという意見を持つことは問題ありません。
同僚との両方に、あなたの意見に同意するためにあなたが書いたコードを維持しなければならない将来の採用を強制することは問題ではありません。それはあなたの上司の仕事です。上司は、コードが長期的に保守可能であることを確認することに関心を持つ人です。彼らが（うまくいけば）より多くのビジネス経験を持っている。なぜなら私がそれをイデオロギーの決定ではなくビジネスの決定であると言ったとき私を信じるからです。
メタプログラムにしたいのは結構です。他の人にメタプログラムを教えたいのは問題ありません。しかし、メタプログラムを習得しないことを選択することは他の人にとっても良いことであることを理解してください。そしてそれは、あなたが権力の座に立つまで当てはまります。 （そして、業界の秘密として：あなたが最終的にリード開発者になったとき、あなたは権力の地位にいません。あなたは権力の地位にありません。権力にある巾着を制御している誰かがいます）。
メタプログラミングで問題ないように奨励したい場合は、start smallを使用します。単一のenable_ifこれにより、APIが読みやすくなります。次に、daylightsをコメントアウトします。次に、テンプレートメタ関数が10個の大きな反復クラスを10個の小さなヘルパーを持つ1つのクラスに変換するケースを見つけます。その中身をコメントアウトしてください。反応を得ます。人々がそれについてどう思うかを見つけてください。彼らはそれをしないように言うなら大丈夫です。メタプログラミングが徹底的に稼いでいるニッチを見つけて、あなたの同僚全員が（不本意ながら）それが仕事に適したツールであることに同意するようにします。
短編小説として、私は広範囲にわたるメタプログラミングを使用して、美しいライブラリをかつて書いた。それは、他のアプローチがリモートで接近することができなかったときに、私たちが当時必要としていたことを正確に実行しました。それは実際に私が書いていたアプリケーションの方向を変えました。しかしそれはメタプログラミングでした。私の会社全体で1〜2人だけがそれを読むことができました。
後で、私の同僚は問題をもう一度試しました。メタプログラミングを活用して正確に必要なことを行う代わりに、リーダーシップと協力して、メタプログラミングが不要になるような問題に課せられていた制約を緩和しました。 。おそらくより正確には、メタプログラミングはlessが必要でした。彼はそれをメタプログラミングが最も得意とすることに制限することができました。
結果として得られるライブラリは、著しく広い市場で使用できるようになりました。新しいコードは、はるかに広い範囲の開発者が保守できます。私はメタプログラミングの道を進んでいることを誇りに思っていますが、より多くの聴衆に届くのは私の同僚のコードであり、それには正当な理由があります。
何よりもまず、これはチームの問題であり、チームで解決する必要があります。特定の要素と構造を使用してプログラミングするためのチームからのバックアップがある場合は、それを実行します。そうでない場合は、彼らと話し合い、説得できず、「あなたのアプローチ」が明らかに優れている理由を強く主張できない場合は、それを使用しないほうがよいでしょう。
C++でのテンプレートメタプログラミングの使用は常にトレードオフであることに注意してください。確かに、アプリケーションの特定の部分をよりDRYで設計するのに役立つ場合があり、非常に効率的で再利用可能なライブラリを作成するのに間違いなく役立ちます。
一方で、これらの利点には一定のコストが伴います。コードはより抽象化され、多くの場合ずっと読みにくくなりますmuchデバッグが難しく、much保守が難しい。これは、アプリケーションプログラミングにおけるメタプログラミングの有用性を疑わしくします。したがって、次のSTLを作成しない場合は、メタプログラミングを使用したくなるたびに、それらの欠点が本当に価値があるかどうかを自問してください。また、不明な点がある場合は、コードレビュー中に同僚のレビュー担当者と話し合ってください。
私の一般的な意見：よくあることですが、次の3つのオプションから選択できる場合：
- 多くの重要なコード構造を繰り返し手作業で入力します。
- C++テンプレートのメタプログラミングを使用してコード生成を自動化します。
- マクロや他のプログラミング言語などの他のコード生成メカニズムを使用して、C++ソースファイルを生成する
次に、適切に行われたテンプレートメタプログラミングが、3つのオプションの中で最も読みやすく、保守しやすいものになります。これが私があなたの立場にあった場合、私がチームに対して行うであろう議論です。実際のコードの例は、それらを納得させるのに役立ちます。
繰り返しを避けるためにテンプレートメタプログラミング（[〜＃〜] tmp [〜＃〜]）を使用する場合は、それを使用して、十分に文書化され、慎重にテストされた抽象化を構築し、 TMPコード。正しいクライアントコードを簡単に記述できます。これは、C++標準ライブラリの設計です。
あなたが書こうとしているコードのタイプの例を見なければ、私たちが正しいか間違っているかを判断できるとは思いません。
ソフトウェア開発者は、機能する、明らかに機能する、テストできる、レビューできる、デバッグできる、変更が必要なときに適応できるコードを書くことを熱望する必要があります。 「C with classes」を書くことでこれが達成できれば、それで問題ありません。
そして、これらはあなたがあなたのコードを測定する必要がある標準です。特に：それは明らかに機能しますか、テストできますか、レビューできますか、デバッグできますか？必要に応じて調整できますか？
思いやりの引数：
あなたの仕事は、学習のための自由な時間を与えていますか、または代わりに、上司にこれらの言語機能を学習するための時間を割り当てるように説得できますか？
そうでない場合、それらを使用することは、本質的に彼らに余分な無給の仕事を与えています。 C++プログラマすべきは言語全体を知っていると思うかもしれませんが、そのようなことを学ばなければならないという負担は軽減されません。あなたの同僚には、子供、病んでいる両親、病気の配偶者、または地獄があり、C++の学習を必要としない合理的な社会生活があります。あなたの提案のより声の大きい反対者は怠惰かもしれません-または、彼らは大まかな時間を過ごすかもしれません、そして今彼らの人生で余分なたわごとを必要としないかもしれません。
コードは、人間が読み取れるように最初に記述し、コンパイラが解析するのは偶発的にのみ記述してください。
ささいなTMPについて覚えておくべきことは、そのコードを読むことができる人の数を制限しているということです。それは正当なトレードオフになる可能性がありますが、ライブラリなどでは、妥当なトレードオフのほうがはるかに多いと私は主張します専門家の小さな専門家チームは、より大きなアプリケーションです。
本のすべてのトリックを引き出すと、他のすべての人に費用がかかります。これは、あなたが悪用したすべての弁護士のコーナーケースを含む言語を理解する必要があるためです。また、バーを引き上げたことで、雇用に費用がかかります。有用な方法でアプリケーションに取り組むために、今ではそれは価値があるかもしれませんが、コストを監視してください...
私にとっては、もう少しタイピングが必要ですが、コードの重複も考えられますが、変更が必要なときに「クラスとSTLを使用したC氏」の前に配置できるので、自分だけが維持できる非常にエレガントなTMPのほうがはるかに便利です。 （したがって、永久に維持されます）。また、Cクラスの男はたまたま主題の専門家であり、その専門知識は通常、言語弁護士よりもはるかに価値があることも覚えておいてください。
だれが言ったか忘れてしまいますが、「そもそもデバッグの方が難しいのは誰でも知っているので、できる限り巧妙にプログラムしたら、どうやってデバッグするのでしょうか」。
普段は書きたくない最新のC++を実際に書き出すことができたとしても、メンテナンスプログラミングの負担を減らす必要があります。
いいえ、できません。あなたは、仕様を満たすコードを作成するために雇われています。このコードは、エゴトリップではなく、保守可能でなければなりません。明日はバスにひかれる可能性があるので、誰かがあなたのコードを拾って、手元にあるタスクを進める必要があります。ただし、新しい技術をプログラミング標準に組み込むように雇用主を説得しようとすることは前向きです。
コンテキストでこの質問に答える唯一の方法は、特定の問題と、メタプログラミングでそれらを解決する特定の方法を見ることです。ここにコードを投稿しない限り、存在しない問題を「解決」するだけで楽しい不要な複雑化に陥っているかどうかはわかりません。または、他の方法では利用できないシンプルでエレガントなソリューションを作成するために言語を最大限に活用したかどうか。
後者の場合は、チームと一緒に続行することをお勧めします。すべての優れたチームは、スタイルだけでなく、問題だけでなく、プログラマーのソリューションが最適なアプローチを使用するか、適切な言語機能を使用するか、保守可能でテスト可能かなども。アプローチを拒否するプログラマーは、代替手段（Perlを使用したコード生成、コードの複製など）をレイアウトし、ソリューションと比較して、前述の基準に対してどのように機能するかを示す必要があります。あなたの仕事は、議論の中で彼らの友好的な「対戦相手」として、それが仕事を速く終わらせる方法であること、メンテナンスが簡単、テストが簡単であること、そしてハードルを超えたらコードが実際に読めることを示すことです面白い文法を解析しています。 （戦略的である場合は、事前にオフィスの友人に見せて、それが本当にクールだと彼または彼女に納得させることができます。あなたが一人ではないので、それは議論の助けになります。）
ほとんどのプログラマーは怠惰で、エレガントで小さなソリューションを楽しんでいます。あなたのものが1つの場合、特に実証された代替案が不十分な場合は、それらを説得できる可能性があります。
この質問に対する単一の正解はありません。
あなたが最初に自問すべきなのは：あなたはどのような状況であなたの雇用によって置かれていますか？実際に仕様をコード化するためのコードモンキーとして雇用されている人もいれば、チームプレーヤーとして雇用されている人もいれば、ナレッジワーカーやエキスパートとして雇用されている人もいます。
基本的にこれは従業員であることを意味するので、唯一の一定のボトムラインはあなたが雇用主の観点からそれを見る必要があるということです。時には、あなたの雇用者にとって最良の利益になるのは、同僚を微調整して高度な技術を習得することです。しかし、別の状況では、多くの問題と責任を生じさせ、関与しているプロジェクトの成功を危険にさらすだけかもしれません。