前言：大教堂的整体设计在基本元素构成上都是一致的。有的教堂偏重于设计师的个人创意，有的教堂舍取设计师的创意而保证设计的纯粹性，在书中提出的观点中，对于计算机系统来说，保持概念的一致性是至关重要的，省略不规则的特性和改进，而反映一系列连贯的设计思路。
获得概念的完整性
一个产品如果其花费在学习使用的时间价值超出了其带给人们的使用价值时，就会难以普及和推广，我觉得产品的易用性是特别重要的。就比如说CSDN推出的Markdown和xheditor相比较，我觉得Markdown并没有征服我，主要是其用起来并不容易。
把易用性作为软件开发的目标来讲，功能和其复杂程度的比值将是最终的标准。功能本身如何强大，或者功能使用起来如何简便都不能作为标准。
当确定易用性作为开发目标来讲，产品经理、项目经理就要在简洁性和功能上做出衡量，就像我们大多数人来说，我们来制作一个图片效果时，用美图秀秀就可以了，非要去用Photoshop那会是痛苦的。那也就是说，Photoshop的设计师和美图秀秀的设计师就要去把控简洁性和功能。
贵族专制和民主政治
要保证概念的完整性，就必须要求设计由一个人完成，或者非常少数的人默契的完成。
很多时候，我们会说从用户、开发人员那里获得创意，来制作更好的产品。但是书中的观点想要告诉我们，在产品设计上去采用民主，往往会失去概念的完整性。从乔布斯传中，我也得出，好的设计显然不可能来自用户，也不能来自于开发人员，因为用户往往只需要一匹快马，而不会需要一辆汽车；而开发人员往往会因为技术实现的难易去掩盖伟大的创意。所以，在产品的设计上，保持专制是不需要有歉意的。
开发人员在开发过程中的创意并不比设计师设计产品的过程中差，很多时候，在实现设计的过程中，会伴随更好的创意。就比如说赫兹菲尔德（我记不起来了）实现了层叠窗口，这就是一个伟大的创意。
另外，资源在有限的情况下，人们往往会发挥更强大的潜力，所以乔布斯的那些现实扭曲力场才会在苹果激发员工的激情，从而实现了苹果的伟大。
在等待时，实现员工该做什么
在早期的瀑布开发流程中，产品的开发人员的确要等到产品的设计师们把需求做成文档，并且经过大量的BI、BD、FD才会到MK阶段，虽然我现在处在敏捷开发迭代中，但是同样会面对这个问题，在产品分析设计阶段，代码开发人员该做什么？显然书中告诫我们，不能将实现者加入到设计者队伍中，这将会带来致命的危险。
开发人员往往会有以下疑问：
设计中功能繁多，不考虑成本。
结构师剥夺了开发人员的创造力。
设计师在工作阶段，开发人员只能等待。
对于2中出现问题，第一个的解决方案到下一章中再说；第二个在目录2中已有介绍，不再赘述；对于第三个问题，如果存在像建造建筑物的时间差点时，那么就等到开始建造的时候，再请工人。另外的解决方案是，在实际的软件作业过程中，很很多工作都要平行的开展。就如同我的小组有三个人，我负责整体设计，另外一名负责的是winform开发，还有一个负责Java方面开发，那么在我讨论设计方案的时候，我会让他们各自调查实现方案，给我确认能够进展的方向。还有就是我们的项目很多分支，我可以交给每个人去解决bug，去预热接下来要开发的内容等等。总之开发人员虽然不便参与设计，当然我也会征求他们的意见，但是在软件作业过程中，等待几乎是不可能存在的，只要合理安排任务，就让人员充分利用，这要建立在有一个好的作业环境。
