开发时与同事打交道，需要建议[关闭]

我开发了当前的项目架构，并开始自行开发（达到revision 40）。

我们正在开发一个简单的地铁路线框架，我的设计似乎做得非常好- 几个主要模型，相应的视图，主要逻辑和数据结构均按“应有的方式”建模，并且与渲染完全分离，并且还实现了算法部分除了主要模型之外，交叉点数量很少。

我将这种设计称为可扩展，可定制，易于实现的设计，它主要基于“黑匣子交互”进行交互，而且很好。

现在，完成了什么：

• 我开始了相应接口的一些实现，移植了一些方便的库，并为一些应用程序部分编写了实现存根。
• 我有描述编码风格的文档以及该编码风格用法的示例（我自己的书面代码）。
• 我强迫使用或多或少的现代C++开发技术，包括no-delete代码（通过智能指针包装）等。
• 我记录了具体接口实现的目的以及应如何使用它们。
• 单元测试（大多数情况下是集成测试，因为没有很多“实际”代码）和所有核心抽象的一组模拟。

我缺席了12天。

我们现在拥有什么（该项目是由团队的其他4位成员开发的）：

• 3个不同的编码风格遍布项目（我猜，他们两个人同意使用相同的样式:)，同样适用于我们的抽象的命名（例如CommonPathData.h，SubwaySchemeStructures.h），它们基本上头宣布了一些数据结构。
• 绝对缺乏有关最近实施的零件的文档。
• 我最近称之为“ single-purpose-abstraction现在”的事件至少可以处理2种不同类型的事件，与其他部分的关系紧密等等。
• 现在，一半的已使用接口包含成员变量(sic!)。
• 原始指针的用法几乎无处不在。
• 单元测试已禁用，因为“ (Rev.57) They are unnecessary for this project”。
• ... （可能不是全部）。

提交历史记录表明，我的设计被认为是一种过大的技巧，人们开始将其与个人自行车和重新实现的车轮结合起来，然后在集成代码块时遇到了问题。

现在-该项目仍然只执行其少量工作，我们存在严重的集成问题，我假设有一些内存泄漏。

在这种情况下有什么办法可以做？

我确实意识到我的所有努力都没有任何好处，但是截止日期很快就到了，我们必须做些事情。有人有类似情况吗？

基本上，我认为为该项目做好一个良好的开端（好吧，我已尽力）可能会带来一些好处，但是，我知道我错了。

毫不留情地重构，摆脱混乱！

采用占可用样式大部分的编码样式，并将其用于本项目。

最糟糕的是，您必须回滚到修订版40，并且您的程序员接受了为期12天的培训，这使他们对该主题有了更好的理解。

如果您的程序员对纯净代码有足够的了解，那么十二天是您最少的延迟。

解释您的问题-“我离开了几个星期，不同意我离开后团队的工作，如果我不在这里，我如何让他们做我想要的事情？”

我告诉你，这不是技术问题，而是管理问题。我的看法（如果我错了，请原谅我）是您规定了一支小兵的技术解决方案，而他们出于某种原因不能或不同意或理解您的解决方案。

如果只花12天的时间对您的设计造成如此大的损害，那一定是有原因的。设计脆弱吗？设计过度了吗？还是团队只是出于恶意而这样做？您的截止日期和交货时间如何？紧？他们只是想见一个人吗？

我看到的一个案例是，技术领先者远远领先于游戏，以至于普通开发人员（我）无法跟上。技术负责人未能设计出商业上可行的代码，因为他是唯一可以维护该代码的人。如果一个研究生开发人员不能维护它，那么对于商业世界来说太复杂了。在所有其他情况下，在管理方面完全缺乏人员管理技能。

团队动力被打破了。您可以（根据其他人的建议）花费时间重构混乱，并在下次请假时再次进行所有操作。您可能需要提高团队成员的技能，但是我认为您首先需要解决团队动态问题，因为无论您认为多么丑陋，他们似乎都有足够的技能来完成工作。

对。

什么你所描述的是很多做是正确的，技术上的独奏。是的，您试图记录文档，试图强加标准-但您（显然）无法沟通。

好吧，您的团队刚刚与您进行了非常深刻的交流。他们说：“嘿，Yippie-您没有沟通！” 我知道最有效的交流方式是配对。对。直到他们得到它，或者直到他们说服您做不同的事情。

正如布鲁克斯在过去30年左右对我们所说的那样，概念上的完整性是任何项目中最重要的部分。对于任何不重要且完整的子系统，应该只有一个人负责其设计并有权指导其实施。您的项目中的这一部分出了点问题。不管是什么，唯一的解决方案是回滚到发生该问题之前存在的存储库中的代码。与维护损坏的设计的费用相比，损失12天是什么。我还会想办法从该项目的进一步工作中撤出参与这项工作的人员，因为事实证明他们没有能力。

对于初学者来说，我要做的一件事就是获得一个好的代码检查工具，使用它来标记错误的代码并记录为什么它不好，以及（在概念上）应如何做。现在，据我了解，有很多坏事要做，因此需要进行大量的工作进行审查；假设您是唯一看到代码错误的人，那么自己检查所有内容可能并不可行。但是，您可以标记最严重的违规行为，并将其转变为问题跟踪系统中的条目，并分配给编写相应代码的人员。

编写高质量代码的最佳动机是知道，如果不这样做，将来会困扰您。您的同事似乎并不在乎这一点，因此最好的药物就是让他们自己重构错误的部分并学习。

如果有时间，您可以重新访问有问题的代码其他部分，然后再次将其分配给原始（不良）作者。一段时间后，他们会第一次意识到做好工作的好处。

我假设您不考虑将回滚到原始版本是一种选择-换句话说，尽管您的同事写了糟糕的代码，但他们添加了一些功能，并且当前版本的净值高于原始版本。我还假设即使不是这种情况，您也没有政治资本来进行回滚并使其重写代码（因为地球上很少有人拥有这种资本）。这些以及更多是判断我自己没有遇到的情况的复杂性，但我希望我的两分钱能对您有所帮助。

我还没有提到一件事，但是最近在我工作的地方出现了“开发人员孤岛”和“购买”问题。

在当前项目的开始，我基本上是一个人设计了一个核心库。（就像您已经完成了第40版一样）。然后，当我完成它时，我向团队的其他成员介绍了并告诉所有人他们可以开始使用它了。在随后的几个月中发生的事情是，人们继续实施与该库中其他地方相同的东西。CTO（积极编写代码）指出，团队的其他成员从未对图书馆的体系结构/设计/公共接口表示认同。

好吧，我们刚刚对该库进行了一次重大重写，可以说已经改进了总体设计以更好地适应我们当前正在做的事情，但是开发人员再次将该库作为他们的唯一项目，在该库上工作了几周，然后介绍一下。“ Voila！在这里！很漂亮吗？”

现在，我必须使用新版本，并且存在相同的问题-我讨厌他这样做的方式。而且他遗漏了必要的东西，因为他在工作时未能与其他任何人合作。再说一次，我开始在其他地方以及为我需要做的工作方式实现相同的东西。

长话短说-如果您想提高代码质量并保持一致，我建议您将整个团队召集起来以建立标准，样式等。此外，任何时候只要有人要构建您的基础或核心产品，在应用程序方面，我建议负责人领导整个团队设计类等，以便最终，整个团队必须考虑整个应用程序体系结构。另外，如果他们知道其他团队成员的代码是如何工作的，则他们不太可能以适合他们的方式再次实现它。

您是该团队的高级开发人员（或高级开发人员之一）吗？如果是这样，听起来您需要举办一些有关最佳做法的培训研讨会。您可能应该还原许多已完成的工作，与团队举行会议，并以维护现有设计的方式说明实施所需功能的正确方法。

鉴于您面临紧迫的期限，您可能必须按原样发送代码，并在发布后进行重构（重写？）。

听起来您还需要定义和执行一些通用的代码惯例。您的工作中是否有代码审查流程？如果没有，听起来现在是实现这一目标的时候了。顺便说一句，代码审查是一种教导新的开发人员最佳实践的好方法。

编辑：

最近我遇到了类似情况。我公司的管理层坚持认为，我们使用合同开发人员来编写许多应用程序。他们产生的代码很糟糕（客气地说），但是我们被迫使用它。截至今天，我已经重写了承包商为我们编写的代码的80％。它充满了错误，无法通过新功能进行扩展。再过几个月，我的团队将全部重写，从而有效地浪费了用于合同开发的资金。

错误的代码确实会花费金钱，这是您可能想与经理讨论的事情，因为您可能需要他们的帮助来实施和实施编码标准。

您付出了努力，但实际上没有人负责。“但是我更喜欢我的编码风格”，不要胡闹。我想整天从事我的个人项目，但仍能获得报酬。

希望您可以将此呈现给当下的力量，并向他们展示与进行了两周的“ 狂野西部表演”相反的情况。似乎您将不得不采取一些措施，但是会继续跟进缺乏控制和一致性的问题。

专注于您的计划中所涉及的少数几个，并尽一切可能使他们帮助解决此问题，并在将来的项目中让他们加入您的团队。如果他们无法将其余部分汇总在一起，您可能只需要拒绝其余部分。