如何解决软件架构师的关切，但仍然维护集体代码所有权？

Question

我们的软件中的代码质量确实很差。当您在一个组件中更改一行代码时，它通常会破坏其他组件中的代码。

我们的软件架构师将此归咎于集体代码所有权。他认为，如果每个开发人员都对自己的代码负责，那么他会一直清理它，因为他会感觉到对组件的所有权。

在当前的情况下，开发人员在多个组件中更改代码，并且他们破坏其他组件，要么是因为他们不理解组件是如何工作的(因为他们使用了这么多组件)，要么是因为他们不关心他们的更改将如何影响组件的其他客户端(只要他们不受影响)。

如何解决软件架构师的关切，但仍然维护集体代码所有权？

Answer 1

当您在一个组件中更改一行代码时，它通常会破坏其他组件中的代码。...if每个开发人员都对自己的代码负责，然后他会一直整理它，因为他会感觉到对组件的所有权。

所以，等等，如果问题是更新组件会破坏其他人的组件(因为一个不可靠的体系结构，没有任何体面的解耦)，那么让组件被开发人员拥有，怎么会突然阻止其他人的组件神奇地解耦，从而不会在更新第一个组件时中断呢！

唯一的解决办法是正确地组织组件，使它们不再像现在这样交织在一起。以及记录它们之间的接口和数据契约。

我确实同意组件所有权，因为它不仅有助于提高代码的质量，还可以替代代码评审--毕竟，为了执行API并纠正每个组件的行为，有些人需要了解每个组件。在这种情况下，我认为代码评审只是实现所有权的一种方式。

Answer 2

当您在一个组件中更改一行代码时，它通常会破坏其他组件中的代码。

理想的世界场景:您应该在单元测试中对API进行形式化和API不变量的测试。如果涉及到这一点，当开发人员做了涉及不变量的更改时，测试就会失败。当开发人员做出破坏单元测试的更改时，他们应该考虑更新单元测试，或者更新API文档(并删除单元测试)。

我们的软件架构师将此归咎于集体代码所有权。

不是的。就是没有。据我所知，每个人同时跨多个组件临时修改代码都是一个问题。这不是代码所有权的问题，而是您的团队的方法没有形式化/尊重API契约和不变量的问题。

他认为，如果每个开发人员都对自己的代码负责，那么他会一直清理它，因为他会感觉到对组件的所有权。

这不现实。如果我编写了一段代码，而其他开发人员破坏了它，我不会放弃我正在做的来修复由上述开发人员引入的bug(因为我有自己的任务和截止日期)。

在当前的情况下，开发人员更改多个组件中的代码，并且他们破坏其他组件，要么是因为他们不理解组件如何工作(因为他们与许多组件一起工作)，要么是因为他们不关心他们的更改将如何影响组件的其他客户端(只要他们不受影响)。

开发人员改变多个组件(并打破随机的东西)以使他们当前的代码正常工作，这意味着您的API缺乏明确的/正式的定义(也就是说，此时没有明确的组件应该做什么)，并且您的API缺乏适当的文档(即开发人员输入函数来查看实现所做的事情，而不是阅读它的文档)。

您认为我们应该做些什么来解决软件架构师的问题，但仍然维护集体代码所有权？

• 将您的接口正规化并记录它们。确保API的文档始终是准确的(如果函数声明空值会产生抛出的MyException，那么最好有一个单元测试，用null调用API并捕获异常)。
• 放弃牛仔编码和“五分钟”修复任何缺陷。任何事情都没有“快速解决”的办法。缺陷修复应该涵盖所有这些：
  • API重新设计(这是在文档上完成的，然后是API声明)
  • 单元测试完成(为新行为添加单元测试，为修改的行为删除和编辑单元测试，只对不再实际的行为进行远程单元测试)
  • API实现更改
  • 所有测试通过

• 确保干净的代码和干净的差异(没有注释的死代码，没有异常排列的代码，等等)。

最重要的是，不要在失败的测试中接受公开提交，或者没有通过两轮代码评审(如果更改导致测试失败，它不是修复，而是一个或多个引入的缺陷)。两轮代码评审意味着：

• 审阅者检查更改并向开发人员提供反馈。
• 开发人员根据评审反馈执行更改。
• 审阅者再次检查更改，并给予批准/拒绝。
• 开发人员提交更改(批准后)

理想情况下，每个固定缺陷都将有一个新的单元测试添加到系统中，该测试将准确地检查缺陷中描述的行为。

当这样做时，一个单线“五分钟修复”变成了"30分钟或更多“的修复。最终，这不是浪费时间，而是您将花费在实现新功能上的时间，而不是花费在调试器上的时间。

Answer 3

这是对布朗博士的回答的补充/评论。

IMHO -软件架构师(SA)正在寻找一种将责任归咎于其他人的方法。我不知道是否每个人都在遵守这个计划。有些公司可能依赖于团队领导或整个团队来负责跟踪计划，因此架构师只在计划本身有问题时才参与其中。其他人可能会依赖SA来决定计划是否被执行。

有些计划比另一些好。试想一下，一位主厨的鸡肉菜谱很差，他依赖一位特别擅长的厨师(基本上，他有自己的菜谱)。有些晚上，另一位厨师不得不介入，因为他试图遵循糟糕的食谱(不加调味料)，因此受到指责。通常情况下，没有足够的优秀程序员来拯救一个糟糕的设计，或遵循一个计划，如果他们自己。

正如Doc在他的回答中所指出的那样，代码评审是确保这种情况与其他标准一起发生的最佳方法。有些人认为，如果人们必须修复自己的bug，他们将对代码负责。底线是，必须有人确保代码是可移植的，如果没有检查，您只是在冒险。