软件构建的核心就是管理复杂度

首先，软件构建的核心就是管理复杂度。虽然书中有不少的篇幅来讨论变量、语句等等这些编程的基本要素，还包括代码改善和调整的策略和方法，可谓不无巨细。不过深入理解一下，这些内容都是围绕着上面这句话展开的，也就是软件构建的核心就是管理复杂度。而这一目标产生的根源就在于人脑智力同软件项目复杂程度之间的矛盾。书中常常会提到几个数字，差不多在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.”现在我的理解，恰恰是这种艺术与科学相互融合的产物带给程序员无比的满足感。