完美软件开发：方法与逻辑

　　本书是培养帅才的书。如果您只想成为一名悍将（比如，C++高手、Android高手），那本书不太适合您；但如果您想鸟瞰全局，运筹帷幄，带领团队攻城略地，那本书则是很有参考价值的。
　　本书在一定程度上可以终止某些争议。软件开发这个行业之中如果过度相信经验主义，则事实会证明效果并不好。几十年发展下来，各种理论依然纷争不断，比如，是做架构设计，还是测试驱动；是敏捷，还是CMMI等。本书在一定程度上可以包容这些矛盾，恰如黑格尔的辩证法可以包容康德的二律背反一样。
　　本书是一个开始而非结束。限于作者的眼界、能力、时间等，本书无法终结所提及的所有问题。希望能有志同道合者与作者一同继续研究这个题目，作者也希望能收到各种建议来不断提高自我。

相关图书推荐

　　本书深入剖析了软件开发中主要环节（管理、流程、开发模型、估算、需求开发和设计编码）的运作规律。
　　在剖析过程中，主要使用演绎法进行推导，同时使用实践中积累的经验对推导出来的结论进行验证。在这一过程中，借鉴了PMBOK、CMMI、敏捷、功能点方法、面向对象分析与设计等思想或方法的精华内容。

　　从读者的角度看，本书更适合有一定开发经验，希望在软件开发这个行业有所建树的读者；也适合不仅满足于完成手里的工作，还喜欢透过现象思考本质的人；毕业生可以用这本书来开阔视野，规划自己的发展方向，但有些地方可能会感到不容易理解。

前言
第1章 完美软件开发之解构
1.1 完美软件开发的定义
1.2 完美软件开发的构成
1.3 完美软件开发的前提
1.4 完美软件开发的用途
第2章 完美项目管理之解构
2.1 项目管理的存在意义
2.1.1 价值根源
2.1.2 定性分析
2.2 完美项目管理的要素
2.2.1 逻辑链1：意愿之价值
2.2.2 逻辑链2：物理环境
2.2.3 逻辑链3：文化环境之“意识形态”
2.2.4 逻辑链4：文化环境之“观点整合”
2.2.5 逻辑链5：制度环境之“势”
2.2.6 逻辑链6：制度环境之“量化管理”
2.2.7 逻辑链7：内耗之终结
2.2.8 逻辑链8：沟通之成本
2.2.9 逻辑链9： 组织行为之优化
2.3 完美项目管理
2.3.1 完美项目管理的形象
2.3.2 完美项目管理的关联要素
第3章 完美流程之解构
3.1 流程的存在意义
3.1.1 价值根源
3.1.2 定性分析
3.2 完美流程的要素
3.2.1 逻辑链1：正交的分解
3.2.2 逻辑链2：流程之尺度
3.2.3 逻辑链3：选择与集中
3.2.4 逻辑链4：共识之力量
3.2.5 逻辑链5：成本之计算
3.3 完美流程
3.3.1 完美流程的形象
3.3.2 CMMI与完美流程之异同
3.3.3 完美流程的关联要素
第4章 完美开发模型之解构
4.1 开发模型的存在意义
4.1.1 价值根源
4.1.2 定性分析
4.2 完美开发模型的要素
4.2.1 逻辑链1：预则立
4.2.2 逻辑链2：反纸上谈兵
4.3 完美开发模型
4.3.1 完美开发模型的形象
4.3.2 完美开发模型的关联要素
第5章 完美估算方法之解构
5.1 估算的存在意义
5.1.1 价值根源
5.1.2 定性分析
5.2 完美估算的要素
5.2.1 逻辑链1：标准单位的选择
5.2.2 逻辑链2：横看成岭侧成峰的应对
5.2.3 逻辑链3：软件类别的影响
5.2.4 逻辑链4：估算的终结
5.2.5 逻辑链5：反省是进步的阶梯
5.3 完美估算方法
5.3.1 完美估算方法的形象
5.3.2 完美估算方法的关联要素
第6章 完美需求开发之解构
6.1 需求开发的存在意义
6.1.1 价值根源
6.1.2 定性分析
6.2 完美需求开发的要素
6.2.1 逻辑链1：雾外江山看不真
6.2.2 逻辑链2：80/20法则
6.2.3 逻辑链3：需求开发的终结
6.2.4 逻辑链4：变化永恒
6.2.5 逻辑链5：偏好上的免疫力
6.3 完美需求开发
6.3.1 完美需求开发的形象
6.3.2 敏捷与完美需求开发的异同
6.3.3 完美需求开发的关联要素
第7章 完美设计和编码之解构
7.1 设计、编码和文档间的关系
7.1.1 【设计 = 编码】 VS 【设计 ≠ 编码】
7.1.2 文档的角色
7.1.3 设计知识归类法
7.2 设计和编码的存在意义
7.2.1 价值根源
7.2.2 定性分析
7.3 完美设计和编码的要素
7.3.1 逻辑链1：正交的分解
7.3.2 逻辑链2：层次的控制
7.3.3 逻辑链3：时序下的数据流
7.3.4 逻辑链4：信息的隐藏
7.3.5 逻辑链5：“名”与“实”的契合
7.3.6 逻辑链6：设计的终结
7.4 完美设计和编码
7.4.1 完美设计和编码的形象
7.4.2 完美设计和编码的关联要素
第8章 设计和编码的度量与改善
8.1 复杂度的度量
8.1.1 现有度量方法的考察
8.1.2 一种新的度量方法
8.1.3 从复杂度的视角考察Factory模式
8.1.4 从复杂度的角度考察Command模式
8.1.5 小结
8.2 设计方法的选择
8.2.1 一点历史
8.2.2 面向对象与结构化间的互补性
8.2 3 第一种互补关系
8.2.4 第二种互补关系
8.2.5 小结
第9章 案例：薪水支付与性能优化
9.1 案例1：薪水支付
9.1.1 设计决策1：雇员这一概念的边界
9.1.2 设计决策2：属性还是类层次
9.1.3 设计决策3：支付方式等与雇员类的关系
9.1.4 设计决策4：支付方式要不要用多态
9.1.5 设计决策5：支付时间表是应该独立还是放入Employee
9.1.6 设计决策6：究竟在哪里用Command模式
9.1.7 设计决策7：使用哪些辅助类
9.1.8 实现
9.1.9 小结
9.2 案例2：性能优化
附录
附录1 贡献值公式与《资本论》
附录2 遗留课题
附录3 语不惊人死不休――反主流观点汇总
附录4 综合能力归类法
参考文献

在武侠小说中，常会把绝世武功分为两个部分：招式和心法。招式得其形，而心法传其神。从这个角度看，这本书是既讲招式也讲心法的书。

招式繁杂，暂且不提；心法却可以概括。

如果非要用3句话来概括本书中所提心法的全部，那么它们是（顺序不可颠倒，有因果关系）：
在尺度中潜在的已经包含本质；尺度的发展过程只在于将它所包含的潜在的东西实现出来。――黑格尔，《小逻辑》
人心唯危，道心唯微，唯精唯一，允执厥中。――《尚书》
横尽虚空，山河大地，一无可恃，而可恃唯我。竖尽久劫，前古后今，一无可据，而可据唯目前。――杨昌济

但这三句话都过于精妙，很难把它们和管理、流程、估算、开发模型、需求开发、设计编码联系起来。本书做的正是这样一种尝试：在把软件作为一个整体进行考察的同时，把精妙抽象的东西和具体的东西结合起来。

把软件作为一个整体考察是因为管理、流程、设计编码等都是影响最终成效的砝码，单纯某一个维度上（比如流程）效能最佳不等于整体效能最佳。

而把精妙抽象和具体相结合则是因为虽然各种理论众说纷纭，但总有些规则凌驾于现象之上，不把握这些规则必然会陷入混乱，进而明于微而昧于巨。反之，精妙的东西又只有通过具体的手段才能实现，无法单独存在。恰如下棋时，虽然每一步都机关算尽，但总是脱不开既定规则，只有有限的结局（或输、或赢、或和），而既定规则的力量又只能实现于每一步具体的操作之中。

作为结果，我们可以讲：

这本书只相信逻辑和事实。虽参照诸多素材（敏捷、CMMI、OO、设计模式等），但主要依靠独立思考才最终塑成体态。纵然错漏难免，但书中所言皆是自主反思所得，虽常有反主流之观点，用心想来却不一定是无稽之谈。

本书直指本质。虽然有的地方略显晦涩难懂，但确实是因为无法简化，并非毫无价值，更非故弄玄虚。同时，为避免偏颇，本书主要使用演绎法，基于以下4个预设前提推导各种结论，并用事实进行佐证。

l 软件是一种固化的思维。
l 意识指导行动。
l 项目所能耗费的资源是有限的。
l 重复做同样的工作会降低效率。