在我的绳子尽头[关闭]

我是一家大公司的承包商。目前，该项目有三位开发人员，其中包括我自己。

问题是其他2个开发人员没有真正得到它。“它”的意思是：

• 他们不了解我们正在使用的技术的最佳实践。在我和其他人给他们提供示例六个月之后，就使用了可怕的反模式。
• 他们是“复制和粘贴”程序员，主要产生意大利面条代码。
• 他们不断地破坏事物，执行更改，但不进行基本的冒烟测试以查看一切是否良好
• 他们拒绝/很少要求进行代码审查。
• 他们甚至拒绝/很少做诸如格式化代码之类的基本事情。
• 没有关于任何类的文档（jsdocs）
• 害怕删除无能为力的代码
• 即使我们具有版本控制，也应将注释的代码块保留在任何地方。

我发现自己在格式化其他代码，修复错误，发现已损坏的功能以及创建抽象结构以删除意大利面条时感到越来越沮丧。

我真的不知道该怎么办。我尽量不要沮丧，但这只是一团糟。我像这些人一样喜欢这些人，但是我觉得编码情况太糟糕了，如果他们整天只浏览Web，我可以更快地行动。

要求我们的经理审查其他svn提交访问权限是否不合时宜；提交只能由对我们正在做的事情有知识的人进行审核后才能完成？作为承包商，我不确定这是否是最好的选择。

有没有一种微妙/不是那么微妙的方式来弄清楚我要修复的东西？

我的团队中有这样的事情。我尽力使人们做正确的事，但是它没有按预期工作，所以我转向了另一个解决方案。

首先，我去找经理，我们达成了协议，除非代码被单元测试覆盖，否则任何代码都不会进入源代码控制。如果代码在没有单元测试的情况下进入，我拥有否决权，可以立即撤消提交，并ping对他们负责的人可以进行测试，然后推送代码。

有了这个规则，我定期运行代码覆盖工具（在这种情况下，jacoco在我们的SBT版本），以确保件正确覆盖，我也做的重构和代码审查不断地被他们推的任何代码。因为这是一个Java和Scala项目，所以我有很多工具可以帮助我捕获不应该存在的东西或不能按照我们认为的方式工作的东西，不确定如何使用JavaScript可以做到这一点，但也许有一个办法。

我认为最主要的是，我确实对我对项目的期望及其主要体系结构有了清晰的了解，因此，只要我看到不符合该观点的内容，就可以去那里修理它。您应该执行相同的操作，定义视图，应使用的模式，代码的编写方式，并始终掌握这些知识，并始终让他们（和您的管理层）了解正在发生的事情以及阻止项目继续进行的事情快点。

他们肯定会在某个时候放弃或者做正确的事，或者管理层收到消息并将其从项目中删除。

我敢肯定，到目前为止，您已经看到了我的评论和其他帖子，所以我不会假装我真的知道答案。我能提供的最好的是我从别人那里听到的/得到的总结，并将我自己的一些经验加进去。

首先，我想说的是，不久前我遇到了一个属于我们自己的程序员SE成员Martin Blore和IMO 的博客，这一篇有关TDD自我实现的特定文章非常准确。TDD是将所有内容联系在一起的最后一个最高级别，但是如果没有先前的级别，尤其是没有最大级别的，生成清晰可读代码的原理和实践，那么即使不是不可能，TDD也会非常困难。

在我的公司中，敏捷和TDD都是由管理层强加给我们的，起初我们只是因为被告知而这样做（这与敏捷相反）。我们已经尝试了TDD两次，尽管我大力支持使用自动化测试，但我个人却把团队在上一版中打败的所有东西都扔掉了。它们非常脆弱，巨大，复制/粘贴在wazoo中，并充满睡眠语句，这使它们运行起来非常缓慢且无法预测。我对您的团队的建议：暂时不要做...。

我不知道您的情况如何，因为您提到您已经在公司工作了6个月，而且您是承包商。您是该公司的长期目标还是合同即将到期？我问是因为即使您做某事，实际看到结果可能也要花费一些时间。

同样，当您加入团队时，通常需要一段时间才能获得足够的信誉和团队的尊重，他们（开发人员和管理人员）甚至会考虑您提出的任何建议。以我的经验，如果您扑灭了几次大火，并证明自己拥有其他人可以依靠的技能和知识，这将有所帮助。不知道6个月是否足够。经常有一个新的，有野心的人加入团队，然后在这里发帖询问他们如何改变世界。可悲的现实是他们根本做不到。

因此，假设您拥有团队的尊重和关注。怎么办？

首先，管理人员和开发人员都需要意识到存在问题。管理措施以交付的工作成果为依据。如果他们对功能的当前数量和质量感到满意，那么可悲的现实是他们不会听。正如其他人指出的那样，如果没有管理层的支持，将很难进行任何形式的改变。

一旦获得管理支持，下一步便是深入研究并找出导致团队运作的根本原因。下一个主题是一段时间以来我个人的追求。到目前为止，这是我的旅程：

1. 一旦获得了管理层的支持。您可以开始介绍MainMa针对我的问题建议的许多集中指导的实践/过程。我们已经做了很多（配对编程除外），您肯定会看到好处。代码审查尤其有助于标准化样式，文档，还使我们能够在团队之间共享知识/技术。即使规定了代码检查，团队实际上还是喜欢它们，我们会检查所有已检入的功能。但是...
2. 您会注意到，通常编写的代码仍然太耦合，设计不好或完全缺乏。代码审查抓住了其中的一部分，但是您只能重写太多了。为什么设计一开始就不好？-从未向许多开发人员介绍好的做法，也从未首先对它们进行过正式的OOD培训。无论执行什么任务，很多人都“简单地编码”。
3. 在管理层的支持下，您可以引入更多流程，例如在进行任何编码之前讨论设计。但是您只是一个人，似乎只要您不注意，团队就会恢复到他们以往所做的一切。为什么？
4. 是否可以引入和教导更好的做法或习惯，以使您不必经常监视？-事实证明这部分并不容易。
5. 为什么其他团队成员不愿意学习和采用新的实践，以及为什么在现代软件方法论文献中有如此多的论述时，他们却如此抗拒SOLID或DRY？有了我们团队中所有积极的变化，两周前我有一个论点，就是我重构了具有相同15行代码的2个函数，而审阅者称其为英勇，不必要的工作，因为复制/粘贴仅存在任何问题15行。我强烈不同意这种观点，但就目前而言，我们已经决定同意不同意。 - 那么现在怎么办？现在我们已经达到了我另一篇文章的主题。
6. 正如maple_shaft和nikie在回答中指出的（对不起，MainMa，您的票数最多，但落后5个步骤:)），您已经达到“流程”无法再为您提供帮助的阶段可以告诉您“修复”是什么。下一步是与一个人或一对一的人接触，或者一次或一次与他们交谈。问他们，什么有效，什么无效。现在，找出导致他们受害的根本原因的唯一方法是分别与他们交谈并找出来。作为此步骤的一部分，我最近遇到了一个完全不同的团队问题，但我认为乔尔的回答是，它非常详细和有见地，也适用于这种情况。总而言之，虽然将管理作为“短皮带”是几乎任何事情的一种可行方法，但我们需要记住，我们正在与人类打交道，因此要真正理解动机，除了纯粹的管理或技术领导之外，我们还需要更多地进入心理分析。
7. 所以现在您正在与队友交谈？你问他们什么？我不确定下一部分，因为我从未来过这里。这是一种可能的情况：问：为什么没有SOLID？答：我不需要。问：这可能有帮助。答：我照原样做。-不知何故，您需要产生一系列的声音，这些声音会离开您的嘴，并使听众意识到，如果它们给您所兜售的东西一个机会，那就会更好。如果您在这里失败，他们将永远不会相信他们所做的任何“过程”实际上都具有任何价值。另一方面，如果您超过了这一点，您可能会发现您甚至不再需要“过程”。
8. IMO从根本上讲，如果您的队友没有发现他们目前的习惯/做法有什么毛病，他们将不会学习。因此，也许所有这一切的下一步就是找到一种方法来说明，突出问题并使其变得明显。毕竟，我们并不是在使用SOLID / DRY原理来编写可读代码，也不是仅仅因为它给我们一种温暖而模糊的感觉而维护文档。我们这样做是因为它可以产生质量更好的代码，并且坦率地说可以使我们的代码更快。可以衡量吗？也许这就是软件指标进入的地方？
9. 这是个疯狂的主意，我不知道它是否会真正起作用（这可能是一种标准的行业惯例，或者可能完全无效。我只是在过去的24小时内提出了建议），但是我很想提出明年开始时立即进入表格：
   • 反对许多其他人的意见，为所有源文件引入作者/所有者的想法。正如实用程序员所建议的那样，这将使一个负责一段源代码的人拥有主人翁感和责任感。这并不意味着其他人不能修改代码，我们都在一个团队中工作，但归根结底，拥有代码的人有责任检查更改。
   • 创建一个源存储库触发器，以监视所有签入并专门查找那些已修复错误的触发器。使其成为一个过程，以使每个错误修复程序都在签入说明中预先添加一个引用标识符。现在编写一个脚本，该脚本将分析已更改文件的列表，并从文件头注释块中删除“作者”。创建一个SQL数据库，该数据库将跟踪每个文件/每个项目/每个作者中检入的缺陷数量。
   • 一旦有了足够的统计信息，希望您会发现您的代码中的缺陷/更改少于其他一些代码。这是您可以使用的硬数据。如果单个项目的缺陷率大大高于平均水平，则将其作为下一个清理/重构工作的候选人来偿还一些技术债务。
   • 如果项目或文件的缺陷率大大高于平均水平，并且有一个所有者，请与该人一对一交谈。毫无礼貌地问他们如何解决这个问题。由于他们是所有者，因此他们应该推动更改，但是会在您身边提供任何帮助。希望所有者可以将很多原因追溯到他们自己的意大利面条代码，并在他们寻求帮助时立即开始行动并放下一些SOLID。

我建议您与您的经理谈这个问题，但是几乎可以肯定，他不会想要审查每一个登机手续。

相反，我建议您建议将一组单元/回归测试挂接到SVN中，并在每次签入时运行。这至少将帮助您避免损坏的版本。您可以逐步建议其他最佳做法。

如果事实证明他是完全不能接受的，也许您应该越过他的头。如果您决定这样做，则需要带来最好的游戏。如果您这样做的话，基本上您将向更高层次的管理人员求职。