办公室官僚机构如何影响代码质量[关闭]

我对办公室官僚机构对最终代码质量结果有直接影响的故事感兴趣。

例如，一个朋友刚刚告诉我，在他以前的工作场所中，版本控制系统是如此庞大，以至于不允许程序员在未征得VCS许可的情况下创建新的“模块”（源树中的根目录）。结果是程序员不愿意经过额外的官僚主义步骤，并且没有适当地对其服务进行组件化，他们最终将不相关的功能堆放在了现有模块之上，即使这些功能只是与模块的当前定义或模块名称远程相关是过去的方式。（更不用说重命名模块了……）

我对办公室，运营或任何其他官僚机构的类似故事感兴趣，这些故事最终可能无意间影响了软件质量

我对办公室官僚机构对最终代码质量结果有直接影响的故事感兴趣。

我认为官僚机构对代码质量的影响不如个人动态和办公室政治影响那么大。官僚主义与程序有关。如果现有流程处理不当（或负面利用，请参见下文），则可能会对交付能力或对突然的变化做出反应产生负面影响。但是，缺乏流程将对代码质量产生一定的重大影响。或更确切地说，不控制代码质量的过程（也解释为缺乏代码质量过程）会影响代码质量。

也就是说，不是官僚机构本身，而是官僚机构中与QA相关的特定漏洞，这些漏洞会在被利用时（偶然或恶意地）影响代码质量。

然而，个人动态和办公室政治在错误代码中更是罪魁祸首。个人动力首先是缺乏职业道德。我真的不赞成人们编写错误的代码的论据，因为人们并不知道更好的东西或没有经过适当的培训。我见过没有CS相关学位的人编写了不错的代码。这是一种心态，是一个组织细致的个人事务。

办公室政治起着更加可怕的作用。上司不相信，只是编码咒语（尽管有时我们必须稍后编码并运送和清洁尸体）；即使现在要出门在外，也要坚持交付他们认为完美的代码的开发人员是至关重要的；有漏洞的代码审查者；小隔间之战等。这些事情加剧了有问题的个人动力。两者的结合会渗透到过程中的任何裂缝（官僚主义）或缺乏裂缝，从而导致代码质量保证失败。

如果有一种事后审查和持续改进的文化，可以解决官僚主义的漏洞。但是，负面的个人动力和破坏性的办公室政治阻止了对过程的这种纠正，从而使现有问题（包括与代码质量有关的问题）永久存在。

官僚主义本身很少是导致代码质量差的元凶。实际上，我会说代码质量和官僚主义都受到负面的个人动力和办公室政治的负面影响。

我停止在项目中的某些特定模块上工作，因为代码审查员是一个聪明的A $$

在最近的一个项目中，有素质的人员对正式的单元测试有很多要求（可追溯性，编码规则，正式审查等）。编码人员不再编写单元测试，而是仅调试其代码。这与刚刚重命名的任务相同，导致相同的技术结果，但是没有管理麻烦。