今天几乎被代码复杂度搞定，还好是几乎。

　　想了想，之所以对代码复杂度要求这么高，应该是和自动测试有关的。自动测试当然是好东西，代码写完或者修改完，跑一遍就知道有没有引入新的错误，这多好。

　　好归好，但是自动测试也是代码，自动测试的质量怎么保证？再引入一个自动测试的自动测试吗？

　　当然不是。代码复杂度就是一个解决的办法。通过低的代码复杂度来保证被测试的代码是“比较简单的”。这样不仅仅是对看代码的人来说更容易懂，更重要的是，用来测试“比较简单”的代码的测试用例就可以“更加简单”。如此一来，自动测试就可以写的数量上不会多的无法完成，质量上也应为“更加简单”而得到保证。

　　也就是低复杂度的代码对于自动测试来说存在这两个意义，第一是低复杂度的代码需要的测试用例的数量是比较少的，避免了需要写大量自动测试用例增加的工作量；第二是低复杂度的代码的每一个测试用例设计起来也是比较简单的，不会太复杂，设计一个简单的测试用例总比一个设计一个复杂的测试用例更能保证正确性——当然，这里来保证正确性的，就是人了。

　　然后，既然这里的“低复杂度”是针对自动测试来说的，就有可能采用量化的指标，因为这是程序对程序。如果是针对人来说，什么是“低复杂度”的指标就很难说，更难以统一了。可能是这个原因让我在降低代码复杂度的时候，感觉程序里的“低复杂度”标准很奇怪。

　　总之，最后掌握标准、做出保证的，还是人，工具只是极大的降低和减轻了人的负担（怎么让我联想到了政治教科书。。。果然放之四海而皆准）。

一点参考资料：

http://en.wikipedia.org/wiki/Software_metric

　　

[原文在百度空间已经关闭]