如何应对软件公司中的代码复杂度

作者：Max Kanat-Alexander 发布日期：2015年1月6日

核心观点：只有程序员个体才能解决代码复杂度

这是一个显而易见却具有微妙影响的论断：只有程序员个体才能解决代码复杂度问题。

也就是说，解决代码复杂度需要个人对代码投入关注。他们当然可以使用合适的工具让任务变得更简单，但最终简化代码的是人类智慧、关注和工作的应用。

更明确地说：解决代码复杂度通常需要在个体贡献者层面进行细致的工作。

如果经理只是说"简化代码！“然后就不管了，通常什么都不会发生，因为：(a) 他们不够具体；(b) 他们不一定具备关于每个代码片段的具体知识；(c) 理解问题的过程实际上就是解决问题的过程，而经理并不是编写解决方案的人。

经理在公司中的级别越高，这一点就越明显。当CTO、副总裁或工程总监给出"提高代码质量"这样的指令但没有更具体说明时，往往会发生的情况是公司里有很多动作，但代码库并没有显著改善。

如果你是一个软件工程经理，面对复杂的代码库并想要解决它，该怎么做呢？

技巧是从个体贡献者那里获取数据，然后与他们合作帮助他们解决问题。流程大致如下：

请团队中的每个成员写下他们对代码感到沮丧的事项清单。代码复杂度的症状包括：对代码的情绪反应、对代码的困惑、感觉修改某部分会破坏系统、优化困难等。

你想得到类似这些问题的答案：“系统中是否有某个部分在修改时让你感到紧张？“或"代码库中是否有某个部分让你工作起来感到沮丧？”

召集团队会议，让每个人带上他们的清单和可以访问代码库的电脑。这种团队会议的理想规模约为六到七人。

在会议中，你要审查这些清单，并为每个症状关联一个具体的目录、文件、类、方法或代码块。

使用会议中的信息，为每个被命名的目录、文件、类等创建一个描述问题（不是解决方案，只是问题！）的bug报告。

首先查看哪些问题影响最多开发者且影响最严重。这些是高优先级问题。

有时问题有必须按特定顺序解决的依赖关系。例如，问题X必须在问题Y之前解决，或者解决问题A会使解决问题B更容易。

将每个bug分配给个体贡献者。这是一个相当标准的管理过程。

确保开发人员在完成功能工作的同时，定期修复一些已提交的代码质量问题。

如果你的团队制定了季度或六周等时间段计划，你应该在每个计划中都包含一些代码清理工作。

不要完全停止正常的功能开发来专门处理代码质量。相反，要确保持续进行足够的代码质量工作，使代码库的质量总体上始终在提高而不是随时间恶化。

如果你做了这些事情，你应该能很好地走上实际改进代码库的道路。

-Max

附言： 如果你发现自己需要更多帮助，我很乐意到你的公司演讲。只需让我知道。