Code Complete的哪些部分没有经受住时间的考验？[关闭]

我在看书架上的Code Complete，心想：“在“神话般的月”之外，这可能是少数经受时间考验的大众市场软件工程书籍之一。因此，我正在考虑重新阅读它。

我很好奇-最近有没有其他人再次看过它？我是这样，您看到他有什么不对吗？

这不是攻击，也不是要求书评-我对多年来改变了哪些观念更感兴趣。

而且，请不要发表任何评论，“ Demarco / Spewak / Zachman经受了时间的考验……”​​我对Code Complete尤其感兴趣，因为它涵盖了广泛的领域，并且在该领域具有广泛的影响力。

完整代码涵盖了许多永恒的概念，例如：

• 强大的凝聚力
• 松耦合
• 良好的常规名称
• 防御性编程
• 自我证明代码
• 软件评论
• 单元测试

今天当然很重要。

现在，在CC中拥护的一些概念已在语法上以较新的语言强制实施，例如C＃不允许以隐藏超范围定义的方式定义子范围内的变量。

其他概念（例如，变量名的匈牙利符号表示法）在主流编程中已被抛弃（尽管仍在使用Win32 API的任何人都将激烈地争论它们还活着并且很好）。但是，变量命名约定背后的真正概念是传达必要的含义并阐明代码，我认为这些概念也是永恒的。

总而言之，从我的回忆（以及我那本古老的CC副本中快速浏览一下）中，我想肯定值得回顾一下。

但是，我不认为这会成为《神话人月》真正永恒的本性。MMM解决了谁在做这项工作，如何以及为什么做这些问题。以及（人类）通信的成本和复杂性。MMM解决的问题对于我们的工作至关重要。相比之下，CC专注于我们如何做到的务实问题。换句话说，如果一个项目落后于进度，并且经理决定将100名人员加入团队，那么编写可理解的代码并不会真正起作用。

CC并没有真正解决困扰我们行业的重大问题。但它确实为在通常不可能的情况下争取最佳结果提供了良好的基础。

我当然认为，对于那些关心软件开发的人来说，它们都需要阅读。并且我建议您在需要复习时重新阅读MM。如果您正在领导开发团队，设置组标准或培训新开发人员，则CC应该重读。除此之外，我个人发现我很早以前就将CC中的材料内部化并每天进行练习。

希望能有所帮助。他们当然是我的最爱中的两个。

总体而言，这本书还是不错的。但是，我确实有一些小问题：

• 第17章（“异常控制结构”）确实提到保护声明是从函数早返回的，但是第15章中有关“如果”语句的示例建议不要使用保护声明。（在书中称守卫条款/提前归还）
• 14.2节中的示例似乎与自己矛盾。首先给出一个“不良”代码的示例，以及如何使其“良好”。然后声明，将相关语句分组在一起时，按数据或按任务相似性将是“良好”的。这样，“坏”示例也应该被认为是“好”-而且，我认为，比“好”示例更容易阅读，因为所有数据的计算速度相同，因此您掌握的状态更少。
• 第23章，调试，其中打印语句在项目符号中被消除。虽然我同意它们不应该是唯一的工具，但是它们在减少发生错误的代码范围方面非常有用。根据您正在使用的代码，在整个过程中散布一些数据，看看数据突然不是您所期望的，这为调试提供了一个很好的起点。

我对另一个涉及函数参数的记忆模糊不清，但目前无法找到。可能是另一本书。