问如何在一个背景/心态混杂的团队中有效地合作？

EN

好吧，我要对这件事大做文章，因为还没有其他人。

我的经验可能有点相似。一年多前，我从软件部门转到了工作场所的嵌入式软件部门，我肯定听到了你在这里表达的情感的呼应。

下面是我所做的一些观察，这些都是你在这里列出的内容。这些代表了不同群体的观点。

• 嵌入式程序员喜欢堆栈和RAII。如果你不需要，为什么要使用智能指针等等。这堆东西是邪恶的。他们对这件事的看法是对的。
• 软件程序员喜欢界面，因为他们看到了抽象带来的力量。有时候隐藏信息更好。依赖反转提高了可测试性。
• 嵌入式程序员经常做更好的功能测试，软件程序员做更好的单元测试。

我的一般外卖？嵌入式/EE背景常常带来较低的架构能力(特别是大型系统)，而软件背景更倾向于对不重要的事情更敏感，更注重理论上提高性能，而不是衡量和改进性能。你的里程可能会不同。

从团队建设的角度来看，我发现建立对相互观点的尊重是至关重要的。这是我的目标，我认为已经走了很多路。

从C++使用的角度来看，我想提出一些可能是痛苦的建议。请从我注意到的软件和嵌入式软件方法不同的角度来看待所有这些，而不是仅仅作为一篇关于风格的值得燃烧的社论。

• 虽然性能很重要，但在嵌入式设备上这是不太可能的。这意味着，如果你在处理一台现代计算机，许多典型的嵌入式技巧并不完全适用。尽管如此，有些人还是会这样做的，最好和球队谈谈，看看他们认为哪支球队会这么做。预先了解这些，就意味着你可以把它们放在心上！
• 元编程和简单的可重用接口之间是有区别的。坦率地说，我发现从可重用的角度来看，您将从拥有良好的正常接口中获得最大的好处。这是值得争取的..。但是..。
• 虽然我喜欢某些模板元编程，但我倾向于认为你“拥抱”它是一个可疑的指标.你真的需要推动元编程吗？或者可能是性格特征？或者可能是兰巴达？或者几乎没有任何C++ 11功能？我知道这些是你最喜欢的工具之一，但它们真的值得一争吗？坦率地说，我并不认为这些增长幅度会那么大。他们确实提高了程序员的生产力和其他东西，但这似乎是一个妥协可能是好的地方。
• 这里有一个存放普通旧数据的地方，也有一个不可闪存的类的位置。一般来说，坚持一些简单的约定，比如structsvs.class，并称其为good:如果您这样做，真的需要is_pod吗？
• 我认为引用是值得推广的，尤其是如果您正在进行大量基于堆栈的编程(您是这样的，对吗？)( RAII和所有的？)在过去，我也认为引用是邪恶的，因为我没有正确地理解它们的局限性和正确的用法。只要向他们展示，您就不必担心代码中很大一部分的空指针，也许他们会同意的。
• 你可能想先谈一下线程处理。嵌入式程序通常在带有调度器的单个线程上做大量工作，而高级软件则选择多个线程。可以说，调度程序的方式在某些方面更快(特别是在与多个线程结合时)，但我提出这个问题的原因是，您的工作分解方式可能会因您的方式而发生剧烈的变化。计划的工作往往发生在水平切片，线程工作在垂直的。而且，由于通常是单线程的特性，我经常看到一种稍微弱一些的方法来锁定嵌入端，这可能也是值得反复检查的。
• 模板通常是很棒的( STL!)，但是这里肯定有一些棘手的语法问题--我在看您，typename关键字。此外，请确保您的.h/.hpp等约定是明确的。我看到了嵌入式程序员对模板的不同看法--通常更多的是关于代码大小和复杂性，而不是速度。尽量不要写你的队友不会接触的代码。
• 我对打字很感兴趣。一方面，它们可以帮助抽象出一种类型，并使一些事情变得更容易。但是我见过有很多类型的代码，很难读到。我认为它们通常具有良好效果的四个地方是：( 1)公开范围用于抽象与硬件相关的类型；( 2)私有范围用于头字段的类型，以便您可以完成相当大的任务，但仍然可以；( 3)私有作用域用于迭代器；( 4)公开范围用于函数指针。超过这些的用例常常让我开始看到交叉眼，如果没有做到的话。

当然，你在一个房间里放了两个程序员，你得到了三个意见。我意识到了。但是在嵌入式软件和软件之间的界限上，我注意到了这一点。我希望它们能有所帮助。(但为了以防万一，我已经先发制人地穿上了这套耐热西装。)

最后一件事。从建立相互尊重和敬佩的角度来看，半途而废，或许看看模板寄存器访问之类的事情，并就这样的事情展开友好的讨论，也许不会有什么坏处。