编辑推荐
本书是培养帅才的书。如果您只想成为一名悍将(比如,C++高手、Android高手),那本书不太适合您;但如果您想鸟瞰全局,运筹帷幄,带领团队攻城略地,那本书则是很有参考价值的。
本书在一定程度上可以终止某些争议。软件开发这个行业之中如果过度相信经验主义,则事实会证明效果并不好。几十年发展下来,各种理论依然纷争不断,比如,是做架构设计,还是测试驱动;是敏捷,还是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.2CMMI与完美流程之异同 
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.23第一种互补关系 
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重复做同样的工作会降低效率。
 文摘
版权页: 
 
 
插图: 
 
                    | ISBN | 9787111426264 | 
|---|---|
| 出版社 | 机械工业出版社 | 
| 尺寸 | 16 |