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

代码简洁性 » 代码简洁性

代码简洁性：如何应对软件公司中的代码复杂性

2015年1月6日，作者：Max Kanat-Alexander

这里有一个显而易见的陈述，但蕴含着微妙的影响：只有个体程序员能够解决代码复杂性。

也就是说，解决代码复杂性需要个体人员对代码的关注。他们当然可以使用适当的工具来简化任务，但最终，是人类的智慧、关注和工作的应用简化了代码。

那么，这又怎样？为什么这很重要？更明确地说：解决代码复杂性通常需要在个体贡献者层面进行详细的工作。

如果经理只是说“简化代码！”然后就此打住，通常什么也不会发生，因为（a）他们不够具体，（b）他们不一定具备关于每个代码片段所需的知识来做到具体，（c）理解问题的一部分实际上是经历解决问题的过程，而经理并不是编写解决方案的人。

经理在公司中的级别越高，这一点就越真实。当首席技术官、副总裁或工程总监发出“提高代码质量”这样的指令，但没有更具体的内容时，往往会发生的情况是公司里有很多动作，但代码库并没有显著改善。

如果你是软件工程经理，很容易提出广泛、全面的解决方案来解决影响大范围的问题。这种方法在应对代码复杂性时的问题是，问题通常由许多不同的小项目组成，需要个体程序员的详细工作。因此，如果你试图用同样的广泛解决方案处理所有事情，该解决方案将不适合大多数需要处理的情况。你尝试的广泛解决方案实际上会适得其反，软件工程师会感觉他们做了很多工作，但实际上并没有产生可维护、简单的代码库。（这是软件管理中的常见模式，它助长了代码复杂性是不可避免且无法解决的错误信念。）

那么，作为经理，如果你有一个复杂的代码库并想解决它，你能做什么？诀窍是从个体贡献者那里获取数据，然后与他们合作帮助他们解决问题。大致顺序如下：

1. 要求团队中的每个成员写下他们对代码感到沮丧的清单。 代码复杂性的症状包括对代码的情绪反应、对代码的困惑、感觉一碰就会坏、优化困难等。所以你想要回答诸如“系统中是否有部分在修改时让你紧张？”或“代码库的某些部分是否让你感到沮丧？”等问题。

   每个个体软件工程师都应该写下自己的清单。我不建议实施某种系统来收集清单——只需让人们以对他们来说最简单的方式写下问题。给他们几天时间写这个清单；他们可能会随着时间的推移想到其他事情。

   清单不必只关于你自己的代码库，还可以是关于开发人员必须使用或工作的任何代码。

   此时你寻找的是症状，而不是原因。开发人员可以尽可能笼统或具体地列出这个清单。

2. 召开团队会议，让每个人带上他们的清单和可以访问代码库的电脑。 像这样的团队会议的理想规模大约是六到七人，因此你可能需要将其分解为子团队。

   在这个会议中，你要浏览清单，并为每个症状关联一个特定的目录、文件、类、方法或代码块的名称。即使有人说“整个代码库没有单元测试”，你也可以说“告诉我一个具体的时间这对你产生了影响”，并用回应来缩小现在最需要编写单元测试的文件。

   你还要确保你真正得到了问题的描述，可能更像是“重构代码库很困难，因为我不知道我是否破坏了其他人的模块。”那么单元测试可能是解决方案，但你首先想尽可能缩小问题所在的具体位置。（确实，几乎所有代码都应该进行单元测试，但如果你没有任何单元测试，你需要从一些可行的任务开始。）

   总的来说，这里的想法是只有代码才能被实际修复，所以你必须知道哪段代码是问题。可能存在广泛的问题，但该问题可以分解为受影响的特定代码片段的特定问题，一个一个地解决。

3. 使用会议中的信息，为每个命名的目录、文件、类等提交一个描述问题（而不是解决方案，只是问题！）的缺陷报告。 缺陷可以简单到“FrobberFactory难以理解”。

   如果在会议中提出了解决方案，你可以在缺陷中注明，但缺陷本身应主要关于问题。

4. 现在优先排序。 首先要做的是查看哪些问题对最多开发人员的影响最严重。那些是高优先级问题。通常优先排序的这一部分由对团队或公司中的开发人员有广泛了解的人完成。通常，这是经理。

   也就是说，有时问题有一个解决顺序，与它们的严重性不直接相关。例如，问题X必须在问题Y解决之前解决，或者解决问题A会使解决问题B更容易。这意味着问题A和问题X应该首先修复，即使它们不如它们阻塞的问题严重。通常，存在这样的问题链，诀窍是找到堆栈底部的问题。错误处理优先排序的这一部分是软件设计中最常见和主要的错误之一。它可能看起来是一个小细节，但实际上对于解决复杂性的努力成功至关重要。在所有情况下，良好软件设计的本质是以正确的顺序采取正确的行动。强迫开发人员不按顺序处理问题（不考虑哪些问题是其他问题的基础）会导致代码复杂性。

   优先排序的这一部分是一项技术任务，通常最好由团队的技术负责人完成。有时这是经理，但其他时候是高级软件工程师。

   有时，直到你在某段代码上进行开发并发现先修复另一段代码会更容易时，你才真正知道先处理哪个问题。话虽如此，如果你能提前确定顺序，这样做是好的。但如果你发现为了确定顺序，你必须实际找出解决方案，那就暂时跳过它。

   无论你是提前做还是在开发过程中做，个体程序员必须意识到在他们被分配的任务之前有一个基础任务要处理。他们必须被授权从当前任务切换到实际阻塞他们的任务。这有一个限制（例如，为了修复一个文件而将整个系统重写为另一种语言不是对时间的良好利用），但通常，“找到堆栈底部的问题”是开发人员在执行此类清理时最重要的任务之一。

5. 现在你将每个缺陷分配给一个个体贡献者。 这是一个相当标准的管理过程，虽然它肯定涉及一些详细的工作和沟通，但我想大多数软件工程经理已经熟悉如何做。

   这里的一个棘手部分是，一些缺陷可能关于不由你的团队维护的代码。在这种情况下，你必须通过组织适当地工作，让适当的团队对问题负责。在这里，与另一个团队共同的经理的支持会有所帮助。

   在一些组织中，如果另一个团队的问题不太复杂或详细，你的团队也可能自己进行更改。这是一个你可以根据你认为对整体生产力最有利的判断 call。

6. 现在你已经提交了所有这些缺陷，你必须弄清楚何时处理它们。 通常，正确的做法是确保开发人员定期修复你提交的一些代码质量问题以及他们的功能工作。

   如果你的团队为一段时间（如一个季度或六周）制定计划，你应该在每个计划中包含一些代码清理。最好的方法是让开发人员首先进行会使他们的特定功能工作更容易的清理，然后让他们进行功能工作。通常这甚至不会减慢他们的整体功能工作。（也就是说，如果做得正确，开发人员通常可以在一个季度内完成相同数量的功能工作，即使他们没有进行代码清理，这证明代码清理已经在提高生产力。）

   不要完全停止正常的功能开发来只进行代码质量工作。相反，确保持续进行足够的代码质量工作，使代码库的质量始终在整体上提高，而不是随着时间的推移变得更糟。

如果你做这些事情，那应该让你走上实际改进代码库的道路。实际上，关于这个过程有很多要知道的——可能足够写另一整本书。然而，上述内容加上一些常识和经验应该足以在你的代码库质量上做出重大改进，甚至可能改善你作为软件工程师或经理的生活。

-Max

附言：如果你确实发现自己需要更多帮助，我很乐意来你的公司演讲。只需告诉我。

分享 点击在Facebook上分享（在新窗口中打开） Facebook 点击在LinkedIn上分享（在新窗口中打开） LinkedIn 点击在Hacker News上分享（在新窗口中打开） Hacker News 点击在Reddit上分享（在新窗口中打开） Reddit 点击在Threads上分享（在新窗口中打开） Threads 点击在X上分享（在新窗口中打开） X

15条评论 留下回复

Kenneth Bowen 说：2015年1月7日上午8:00 你在这里给出了一些很好的建议。然而，在多年的软件开发中，我从未听过经理，更不用说有C级头衔的人，呼吁代码简洁性或质量。在我能想到的每一个案例中，开发人员自己领导了清理代码的冲锋（即：抓、挠和乞求）——通常通过减少错误、维护成本和未来敏捷性来推销。

我可以数出关心代码质量的经理的数量，一只手就够了，只需要两个手指就能找到一个能识别它的人。

我喜欢这里的建议，但它似乎更适用于开发负责人。

回复

Max Kanat-Alexander 说：2015年1月9日下午12:34 是的，我知道你在说什么。实际上，我认为经理们确实关心，但他们不会将其表述为对“代码质量”或“代码简洁性”的担忧。相反，他们往往关心的是速度、稳定性和系统的性能。他们关心发布的速度以及发布后发现的错误数量。这就是我通常处理这个问题的角度——处理代码复杂性处理了这些问题。

-Max

回复

Naz-Al Islam 说：2015年11月18日下午12:16 嗨，max， 你的建议非常有效。我是计算机科学系的学生，我正在学习更多关于编码和管理错误的知识。我认为，我们能写的代码越简单，我们能开发的软件就越智能。为此，良好的规划是必须的一步，而经理正是处理这个问题的人。

回复

Peter Williams 说：2016年4月28日凌晨2:37 好观点，但编码人员如何在时间限制下表现？在处理复杂代码时管理工时非常重要。你对这方面有什么建议吗？代码的复杂性可以随着时间的推移解决，然而，如果它是时间限制的，情况就会变得混乱。

回复

SoftwareEngineerCareers 说：2016年5月2日下午6:44 我也没有经历过任何经理指示开发人员追求代码简洁性。经理或项目经理感兴趣的是满足进度，同时生产高质量产品，最小化缺陷逃逸到生产。一些经理甚至不关心质量或可维护性，因为他们只专注于满足可能在某一点被缩短的进度。

回复

Liam Evans 说：2016年6月1日上午8:57 你认为使用“更简单”（没有这样的东西）的语言，例如Native Script，怎么样？快速回顾：http://webcreek.com/2016/04/08/what-is-nativescript/

回复

Max Kanat-Alexander 说：2016年9月18日晚上10:20 这是一个技术选择，就像任何其他一样。在书中，我有一章关于如何做出技术选择。一些编程语言对于某些任务比其他更好，但有很多关于如何为给定项目选择正确语言的考虑因素。

-Max

回复

teche 说：2016年6月22日凌晨12:08 好观点，但在现实生活中很难，因为你有时间限制

回复

John 说：2018年5月9日凌晨3:34 每次你交付过于复杂的代码时，你都在刷技术债务信用卡。随着时间的推移，你的速度会减慢到爬行，上级会开始认为你的团队无法交付。你甚至可能一段时间夜以继日地工作以试图跟上。代码的各种部分将只被你的开发人员的子集所知，因为它们对其他人来说太难了。不可避免的崩溃即将到来。如果你立即支付你的技术债务，你就不会淹没在“利息”支付中。

回复

X-mx Solutions 说：2016年9月21日凌晨2:50 管理太大、太长、太昂贵但我們做以下事情的复杂项目 处理软件公司中的代码复杂性。 – 规划项目 – 自适应管理方法补充传统实践 – 范围最小化是成功的关键 – 选择团队成员和维护团队健康 – 开发和交付解决方案

回复

Siamak 说：2016年12月3日下午5:23 Max， 感谢分享你的经验，我想说你的方法实际上有效。 在较小的公司中存在一些障碍，因为缺乏资源（人员）和团队试图推进的项目数量。 我是加州托伦斯一家零售公司的软件开发经理。 我还在洛杉矶地区提供软件服务。 http://www.siamakheshmati.com 再次感谢！

回复

divp 说：2017年3月21日凌晨1:05 感谢分享你的经验..好一个

回复

python quiz 说：2017年4月11日凌晨2:10 只要你同意，对我来说你是一个永恒的神

回复

telcomet 说：2017年7月31日凌晨2:55 出色的发布..非常信息丰富的点需要详细解释..感谢发布..保持下去…！

回复

Xeffect Studio 说：2017年9月14日上午6:06 太棒了。非常好的信息。谢谢

留下回复取消回复

联系 关于 书：理解软件 书：代码简洁性

输入你的邮箱… 订阅

© 2025 版权所有。由 The Fox 提供支持。

管理同意 为了提供最佳体验，我们使用像 cookie 这样的技术来存储和/或访问设备信息。同意这些技术将允许我们处理诸如浏览行为或本网站上的唯一 ID 等数据。不同意或撤回同意，可能会对某些特性和功能产生不利影响。

功能 功能 始终活动 技术存储或访问对于启用订阅者或用