1.专业

2.但是不迂腐，很接地气

3.但是不屌丝，很有情怀

 

由此可见，《构建之法》是一本当代软件工程大学教育急需的好书。

 

本人在大学上的软件工程课用的也是较老的课本，讲的是瀑布式的环节，带着对这门课残留的记忆参加实习的时候，最大的不适应就是对需求变化的反感，当时还不知道“迭代”这个词，只觉得做事情是要“谋定后动”的，“庙算多者胜”，怎么能大概了解下需求就开始动手呢？“需求分析”难道不该做的认真、准确、达到一劳永逸的效果么？由于自己是深思型的人，偶像是林彪元帅，当时在思考之后得到一个“林总体”的结论——领导催，组长骂，都要顶住，反正我要准备好了（指分析、设计）再动手！

 

——当时已经是2010年，《敏捷开发宣言》却还听都没听过。

 

后来看到了，“响应变化胜过遵循计划”，第一反应是排斥，时至今日我也认为“拥抱变化”的提出有取悦某些人的成分，当然，作为一种方法论，想要推广，必须满足市场最大的需求，而这个行业最大的需求，就是业务的变化。因此理想化的一劳永逸的需求分析是不可能的。但“响应变化胜过遵循计划”用偏了就成了不想就做，边做边想，反而容易在整体上失去设计，这句宣言的“拥抱一切可能性”的精神，反而会因整体上的缺乏设计，而能够修改的空间很小，当需求变化的目标与一开始的代码很不兼容的时候，或者大幅度重构（工作量接近重写，而且重构没有重写那样顺畅的体验），或者采用“小修小补”的方式，以不断降低代码质量来“拥抱变化”，饮鸩止渴，至于“持续重构”，其风险和工作量又没人愿意承担，不是说“重构的第一原则就是不要重构”么？

 

这让我产生了非常大的疑惑，因为我心中的真理是“不谋全局者，不足谋一域”，需求变化自有其范围，我们要做的其实应该是，在计划的过程中考虑到种种变化的可能性并预留出空间，而不是把希望寄托在“随机应变”的不确定性上，“战已合而不知胜负者，无算也”，被“做了再说->修补->走人->接手人员骂娘”坑了的不是一个两个，当然这种现象应该归因于人员素质低下而不应把黑锅丢给敏捷，敏捷自有其建模、重构的方案，但我们往往想得太少，敲得太多，而对“响应变化胜过遵循计划”的错误解读可能会让人想得更少，敲得更多——而且返工得更多。

 

这是我当时对敏捷的怀疑，但出于对Martin Fowler等大师的敬仰，一直在认为是自己修为不够，不能理解精髓。直到看到酷壳网上的博文，才知道怀疑者大有人在，直到翻开《构建之法》112页，“敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论”，才恍然大悟，自己果然是深中迷信权威的毒，“没有银弹”，“兵无常势，水无常形，能因敌变化而取胜者，谓之神”，这些话，怎么就想不到呢。

 

就更想《构建之法》的好，如果大学就看到这本书，要少死多少脑细胞啊，读君一本书，胜思三年考，什么“终日而思”“须臾之学”的，说的就是这个。

 

回过头想想在学生毕业成为职业程序员的过程中，《构建之法》能雪中送炭的点。

 

首先，这是一本全景式图书，会让你更了解这个行业，能让毕业生在对行业从陌生到熟悉的过程中，较少地感到惊讶和出乎意料，这是一本与现实接轨的教材。

 

其次，这是一本最佳实践式的书，涵盖了科学、健康的软件工程开展中的每个方面，介绍了种种方法论，但不是高高在上、纲领性的方法论，而是方法论的最佳实践，确实可用，拿来就用。

 

第三，这本书让人有情怀，学生对“古老的”瀑布教材或“舶来的”敏捷书籍，难免会缺乏信心：这东西行吗？适用于现代吗？适用于中国吗？而如果到各大论坛、社区、或者询问“过来人”，往往会收获更多的负面信息，让本来有情怀的学生失望，让本来就缺乏情怀的学生甘心。但很明显我们这个行业需要的是更有情怀的人才、更好的职业道德和素养，如果学生在毕业前就俯首认输，行业还有什么希望可言？邹欣老师的教材会让学生知道“应该如此”而且“可以如此”，从这点上看，功德无量。

 

第四，这本书在介绍方法论的同时，居然会介绍方法论不适用的场景，介绍方法论在现实中是怎样跑偏的，这就好像讲下棋，“这样走，之后的发展会怎样怎样，所以不行”，怎样做会对，怎样做会错——什么叫宏观视角？什么叫最佳实践？什么叫算无遗策？就像画一棵决策树，向哪个分支走，结果会怎么样，清清楚楚，明明白白，让人信服。

 

第五，这本书在介绍方法论的时候，并没有把“人”放到“方法论”的下层，而是介绍了种种角色、有血有肉有情绪的人，能让学生了解到工作中接触的种种角色及其想法、诉求，避免“以程序为中心”思考问题，而懂得以人为中心来思考，毕竟程序要解决的，是人的事情。这个思想的转变，对程序员来说，至关重要。

 

这本书涵盖了现代软件工程的全部，每个章节甚至每个段落拿出来，都可以在实践中作为指导。

 

这是一本浓缩了无数精华的好书，搞软件的应该人手一册，就像每个兵家必备一本《孙子兵法》一样。