Steven C. McConnell is an author of many software engineering textbooks including Code Complete, Rapid Development, and Software Estimation. In 1998, McConnell was named as one of the three most influential people in the software industry by Software Development Magazine, along with Bill Gates and Linus Torvalds.
From Wikipedia: Steve McConnell
N年前，也不知道多少天了，终于啃完了大部头Code Complete。经典就是经典，确实受益匪浅。
总结一下，其实让我记忆深刻的主要是两点：
首先，软件构建的核心就是管理复杂度。虽然书中有不少的篇幅来讨论变量、语句等等这些编程的基本要素，还包括代码改善和调整的策略和方法，可谓不无巨细。不过深入理解一下，这些内容都是围绕着上面这句话展开的，也就是软件构建的核心就是管理复杂度。
而这一目标产生的根源就在于人脑智力同软件项目复杂程度之间的矛盾。书中常常会提到几个数字，差不多在6、7左右变化，因为这是人脑智力管理的极限，多了，就管不过来了，呵呵。所以，书中会有一些结论性的建议。
比如构建可工作的类，内部成员应该控制在7(+-)2，也就是5个或者9个左右，如果都是Native Type的话，9个成员变量能管的过来，如果都是对象成员的话，5个也能保证你的头脑始终清晰。还有，比如程序中的嵌套结构，类似于If，循环啊什么的，要保持嵌套层次不能多于6层，而据实际调查，一般3层以上的嵌套就会使程序员非常的困惑和抓狂了；还有比如子程序的参数个数尽量保持在7个以下，要不然也记不住，别说7个了，没有现代IDE的帮助，我连4个以上的参数我都记不住，呵呵。
我想满足这些指标并不是很难的事情，而这些东西也给出了对于代码进行改善时候可以依据的标准。不过想要管理这种复杂度，从作者的书中总结一下，具体可能是以下几点：
第一，分割，既然大脑管不过来，那就把系统进行分割，也就是从设计角度上抽象出若干部分，每次让大脑focus在一个部分上，这点我是有深刻体会，虽然我现在完全自己做的东西超不过15000行，不过也不能妄想自己把所有的部分都记住，如果抽象的不好的话，我就特别头疼，每天在代码中翻来翻去的，效率非常低；
第二，清晰理解，其实这点跟上面一点是差不多的，只有清晰理解了抽象的含义，才能做好每个封装每个接口，这样在关注别的抽象部分的时候，其他部分需要记住和管理的更清晰也更简洁，因为不需要关注其他部分是如何实现的，只要按照接口和抽象来做就好了；第三，清晰表达，在程序中应该清晰表达逻辑和抽象含义，也就是增加程序的可读性，唉，这点太重要了，书上也围绕着这个不断的论述，上面提到那些事无巨细的部分反复的说着这一点，甚至连命名都有专门的一章来讨论。
第二点我觉得记忆深刻的就是：以程序员为本。可惜国内的我见过的企业做不到这些。其实以程序员为本不是说一个公司的文化，也不是说单纯就是项目管理人员的事情，其实，最底层的程序员也应当遵从这一条。代码首先是为了人而写的，不是为了机器。机器只会对机器码感兴趣，高级语言自然是留给人来看的。所以说，即便是最底层的程序员也应当奉行这一条，合作中更讲究这个。
话题又回到了上面提过的可读性的问题。当然，以程序员为本也可以延伸到企业文化或者项目组文化，毕竟在这个过程中，程序员追求的技术满足程度外行可能无法理解，不过理解起来也很容易，就像画家对于自己的油画，建筑师对于自己的建筑那种感觉。
“Programming is neither fully an art nor fully a science. As it's typically practiced, it's a "craft" that's somewhere between art and science. At its best, it's an engineering discipline that arises from the synergistic fusion of art and science.”现在我的理解，恰恰是这种艺术与科学相互融合的产物带给程序员无比的满足感。
至于《代码大全》究竟有多牛？我想每一个读过它的人，都会有自己独特的体会，推荐你开始阅读它吧～
《代码大全》和《人月神话》我都在自己对软件处于不同理解阶段的时候读过。《人月》通读了两遍，《代码》大概读了三分之二。老实说，《代码》虽然成书晚，讲的具体细微，其质量并不如《人月》。很多观点也值得商榷。
比如说，《代码》虽然列举，但是贬低把软件开发视为 organic grow 的过程。反而把建筑的比喻作为讨论的基础。我并不同意。为什么我不喜欢用建筑比喻软件 。软件的构建是团队知识的固化过程，而建筑并没有「知识固化」这个过程。
而且，用建筑来比喻软件，往往是搞错了软件的设计和生产。曾经有很长一段时间，人们认为软件的高层设计是「设计」，而 coding 是「生产」软件。错！Coding 就是 design —— Code as Design: Three Essays by Jack W. Reeves。所以，软件构建的大部分时间，相当于建筑的蓝图绘制阶段。当你用建筑的蓝图绘制来比喻软件的 planning，本身就是会错了意。软件的 planning 相当于建筑里开始绘制蓝图之前的非正式构思。
另外，为了 Unit Test 引入的各种 trick，我也不能认同。
Code complete的意思是完成代码，而不是大全。这本书是教你如何一步步完成开发，避免遇到各种作者在实践中遇到的问题，和大全不大全无关。
一本书的作者何以被提到跟比尔盖茨和Linus一样的高度？你说，它，有没有那么牛
326
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
