即使不是所有的同事都了解元编程，也可以使用元编程吗？

我使用了大量的元编程来避免重复的任务，并建立更安全使用的抽象。

我最近搬到了一个新工作，在一个更大的团队中工作，这让我的一些同事感到担忧，因为他们不理解。

我总是尽力利用这种语言的全部潜力，但是我的一些（并非全部）同事认为这是一种风险（有些人欢迎这种方法）。

我同意编写团队中其他人无法理解的代码是一个问题。另一方面，我们都是C ++专业开发人员，我认为我们应该追求更高的标准，而不是使用类编写C。

我的问题是，谁是对的，我该怎么办？

澄清： 试图充分利用语言的潜力，并不意味着我在所有问题上都投入了TMP。C ++是一个工具箱，对我而言，C ++熟练程度是指能够使用包装箱中的所有工具，以及为特定工作选择合适的工具。

元编程可以。您尝试执行的操作不正确。

我在工作中一直使用元编程。这是一个功能强大的工具，可用于以更具可读性和可维护性的方式完成许多事情。它也是那里较难理解的编程风格之一，因此它确实需要保留。当我可以将1000行代码减少到50行时，我很喜欢它，但是我尝试这样限制它。

问题不是元编程，但这是：

另一方面，我们都是C ++专业开发人员，我认为我们应该追求更高的标准，而不是使用类编写C。

这就是您遇到麻烦的地方。你有意见 认为元编程很好是很好的。有观点认为我们都应该渴望成为更好的C ++开发人员，这很好。

强迫您的同事和未来的雇员都必须保持您编写的代码以同意您的观点，这是不合适的。那是你老板的工作。您的老板应该是确保您的代码从长远来看可维护的人。他们（希望）有更多的商务经验，因为当我说这是商业决定而不是意识形态决定时，请相信我。

想进行元编程很好。想教别人元程序很好。但是请理解，其他人也可以选择不学习元程序，这也很好，直到您处于有能力的位置时，这都是正确的。（而且，作为一个行业秘密：当您最终成为首席开发人员时，您拥有权力的职位根本就没有权力。有人控制着掌权的人）。

如果要鼓励他们对元编程没问题，请从小开始。从enable_if使API易于阅读的单一符号开始。然后从中评论日光。然后可能发现一种情况，其中模板元功能将10个大型重复类转换为1个带有10个小助手的类。对此发表评论。得到反馈。找到人们对此的想法。如果他们告诉您不要这样做，那就没事了。找到一个利基元，元编程可以在该利基中获得如此丰厚的收益，以至于您的所有同事（勉强地）都同意这是完成这项工作的正确工具。

简短来说，我曾经使用广泛的元编程编写了一个漂亮的库。当没有其他方法可以遥不可及时，它正是我们当时所需要的。它实际上改变了我正在编写的应用程序的方向。但是它是元编程。我整个公司中只有一两个人可以阅读它。

后来，我的同事又对该问题进行了调查。他没有利用元编程来精确地完成所需的工作，而是与领导层一起放松了对问题的限制，从而不再需要元编程。也许更准确，元编程是不太需要的。他能够将其限制在元编程最擅长的领域。

生成的库现在可以在非常广泛的市场中使用，并且由于新代码可以由更广泛的开发人员维护的事实而定，这在很大程度上不容小small。我为元编程铺平道路而感到自豪，但这是我的同事的代码将覆盖更广泛的受众，这是有充分理由的。

首先，这是团队的问题，您必须与团队一起解决。如果您从团队那里得到备份，可以使用某些元素和构造进行编程，请执行此操作；如果不是，请与他们讨论，如果您不能说服他们，并提出充分的理由说明“您的方法”显然更好，那么您最好不使用它。

请注意，在C ++中使用模板元编程始终是一个折衷：当然，它有时可以帮助将应用程序的某些部分设计为更干燥，并且对于创建高效且可重复使用的库绝对有帮助。

在另一方面，这些优势在一定的成本：代码变得更加抽象，往往多难读，多难以调试和多难以维持。这使得元编程在应用程序编程中的有用性经常令人怀疑。因此，假设您不打算创建下一个STL，则每次您尝试使用元编程时，都要问问自己这些缺点是否真的值得。如果不确定，请在代码检查期间与同行检查者讨论。

我的一般意见：如果您可以（通常）在以下三个选项之间进行选择：

• 手动重复输入许多非平凡的代码结构；
• 使用C ++模板元编程来自动生成代码；
• 使用其他一些代码生成机制（例如宏或其他某种编程语言）来生成C ++源文件

那么正确执行的模板元编程可能是这三个选项中最易读和可维护的。如果我在您的位置，这就是我要向团队提出的论据。带有实际代码的示例将有助于说服他们。

当您使用模板元编程（TMP）避免重复时，应使用它来构造有据可查，经过严格测试的抽象，这些抽象可以将TMP代码内的复杂性定位在本地，从而易于编写正确的客户端代码。这是C ++标准库的设计。

我认为，在没有看到您要编写的代码类型的示例的情况下，我们无法判断谁是对还是错。

软件开发人员应该渴望编写出行之有效的代码，该行之有效的，显而易见的，可以测试的，可以审查的，可以调试的，可以在需要更改的情况下进行修改的代码。如果编写“带有类的C”实现了这一点，那就很好了。

这些是您应该衡量代码的标准。特别是：它是否可以正常工作，可以进行测试，可以进行审查，可以进行调试以及在需要时进行调整吗？

来自同情心的论点：

您的工作是否有空闲时间来学习，或者您是否可以说服老板分配一些时间来学习这些语言功能？

如果没有，那么使用它们实际上是在给他们额外的无偿工作。您可能认为C ++程序员应该了解全部语言或类似的语言，但是从学术角度上讲，这并不能减轻您要加在他们身上的负担。您的同事有孩子，生病的父母，生病的配偶-或地狱，只是一种不涉及学习C ++的合理社交生活。您的提议中比较直言不讳的对手可能很懒惰-或者他们可能经历了一段艰难的时期，并且现在不需要他们的生活。

首先应该编写代码，以供人类阅读，而只是偶然地供编译器解析。

现在，要记住关于非琐碎的TMP的事情是，您限制了可以读取该代码的人员数量，这可能是一个有效的折衷，但是我认为，在图书馆中进行合理的折衷远不止如此，在这种情况下，小型的专家专家团队则可以在更大的应用中使用。

当您掏出书中的所有花招时，您就对其他所有人施加了成本，因为他们现在需要理解该语言，包括您所利用的所有律师特有的案例，您还因为提高了门槛而对雇用人员产生了成本。以一种有用的方式来处理应用程序，现在也许值得，但是要注意成本。

对我来说，键入更多，甚至可能重复一些代码，但是当需要修改时，我可以将其放在“带有类加STL的C先生”前面，这比只有我可以维护的一些非常优雅的TMP有用得多（因此将永远保持下去）。还请记住，具有C知识的C类人员可能恰好是主题专家，与成为一名语言律师相比，专业知识通常更有价值。

我忘了是谁说的，但是“每个人都知道，调试起来比写它首先要难，因此，如果您尽可能聪明地对其进行编程，您将如何调试它？”。

即使我真的不愿意在那里写现代的C ++，这也意味着我不必做太多的维护编程。

不，你不应该。您被雇用来生产满足规范的代码。此代码必须易于维护，而不是自我旅行。明天您可能会被公交车撞倒，所以有人必须能够拿起您的代码并完成任务。但是，尝试说服您的雇主将新技术纳入其编程标准是正面的。

在上下文中回答此问题的唯一方法是查看特定问题以及通过元编程解决它们的特定方法。除非您在此处发布代码，否则我们将不知道您是否沉迷于不必要的复杂性，这对您一个人来说很有趣，可以“解决”一个不存在的问题；或者您是否利用语言的全部力量来编写其他方式无法提供的简单，优雅的解决方案。

如果是后者，我鼓励您继续与您的团队一起这样做。每个优秀的团队都必须进行有意义的代码审查，这些审查不仅讨论样式问题，而且还讨论程序员的解决方案是否使用最佳方法，使用适当的语言功能，是否可维护和可测试等。您的元编程解决方案应填补一个此类的审查会议，很可能会整个下午。拒绝您的方法的程序员应该提出替代方案（例如，使用perl进行代码生成，代码复制等），并显示与您的解决方案相比，该方法如何按照上述标准执行。您的工作（作为参数中友好的“对手”）表明，这是一种快速完成工作的方法，维护简单，测试容易，并且一旦克服了障碍，代码实际上就可以读取。解析有趣的语法。

大多数程序员都很懒惰，喜欢优雅的小型解决方案。如果您是一个人，那么您很有可能说服他们，尤其是当所证明的替代方法落空时。

这个问题没有一个正确的答案。

因为您应该问自己的第一件事是：在什么情况下您受雇于工作？实际上，有些人被用作代码猴子来编写规范，其他人被用作团队成员，其他人被用作知识工作者或专家。

唯一不变的底线是您需要从雇主的角度来看待它，因为从本质上讲这意味着要成为一名雇员。有时候，促使您的同事变得更好并掌握先进的技术确实符合您雇主的最大利益。但是，在不同的情况下，您可能会造成很多问题和责任，并危及所涉及项目的成功。

问题并不是真正的关于元编程是否行得通，而是关于是否可以变得比团队中的其他人更好，所以这里有一些关于我如何看待它的争议点...

我最近搬到了一个新的工作中，在一个更大的团队中工作，这种[元编程]使我的一些同事感到担心，因为他们不理解。

他们担心您会比他们更好。那很好。您将成为新专家。您刚刚摧毁了他们的现状世界。

我总是尽力利用这种语言的全部潜力，但是我的一些（并非全部）同事认为这是一种风险（有些人欢迎这种方法）。

当然，没有人比其他人更喜欢没有技能，因此他们试图阻止您使用对他们来说太复杂的技术。他们要么无法理解，要么就不会去做，因为他们现在感到安全。

我同意编写团队中其他人无法理解的代码是一个问题。

我不。我认为它正在显示您的专业知识。

我的问题是，谁是对的，我该怎么办？

您应该使用所有技能来编写可以编写的最佳代码，并且不要忽视那些不了解它的人。否则，您将被困在他们的水平上，只是一个普通的编码器。变得比别人更好是一件好事，而要努力变得比别人更好是一件好事。如果您不尝试使用任何新事物或做不同的事情，您将永远不会获得任何新的经验。

我知道我会被否决，但这就是它的样子。超越团队中的其他人不是犯罪，使用技能也不是犯罪。只是每个人都害怕承认这一点……因为他们站在非技术方面，并且讨厌新来的人突然可以做一些他们做不到的事情。如果他们很聪明，他们会向您寻求帮助和建议，而不是因为您的代码难以理解而批评您。

编辑

这个问题似乎有很多困惑。正如注释所示，许多人认为这与常规代码的可读性有关。不，这不对。这是因为某些团队成员不理解某些语言功能/结构而应予以禁止或避免。

我的回答是不。他们不应该被禁止。如果您想禁止某事，您将如何做？您必须准备某种问卷调查表，以了解您的团队成员可以做什么和不能做什么-或者宁愿不想学习，因为我认为所有语言特性在某个地方都很有用，因此了解它们并能够使用它们总是好，您知道的越多，您可以编写的代码越好。您还需要一个比例尺来定义哪些功能是初学者，中级或高级的。

为了说明这种限制是多么愚蠢，让我们举一个非常简单的例子：您将被聘为软件工程师，但您的未来老板告诉您，do/while由于有几个人，您将不允许使用循环以前从未使用过并且也不会使用的团队，因为他们一直在for对所有内容使用循环，因此他们发现do/while循环令人困惑。

现在您认为这是愚蠢和疯狂的，不是吗？但是禁止其他功能。一些人可以使用它们，而另一些人则不想学习它们。

如果您知道有些东西可以让您以更少的精力完成相同的工作，却又能使可读性更强的代码，为什么还要生成更差的代码呢？

无论您仅使用基本语言功能还是高级功能，都可以使用其中之一来生成同样难以理解且无法维护的代码，因此这是一个完全不同的主题。