第1章 设计之命题
1.设计首先诞生于脑海里，再慢慢逐步成形（实现）
2.好的设计具有概念完整性：统一、经济、清晰、优雅、利落、漂亮。。。
第2章 工程师怎样进行设计思维——理性模型
1.有序模型的有序过程，也是工程师的构思过程
2.理性模型太过简化与理想化
第3章 理性模型有哪些缺陷
1.设计最难的部分在于决定要设计什么，或者帮助用户找出他们想要什么
2.理性模型是自然的思维模型（理性主义，即相信人是理性的）
3.对有缺陷的模型的盲从很危险
第4章 需求、罪念以及合同
1.委员会式的，野心勃勃的大而全的软件极易失败
2.控制需求以保证需求的纯粹
3.人性（?）导致人们无法互相信任，于是需要先写下来合同
瀑布模型更容易产生合同
4.设计与实现的合同分离开，事情会更清楚
第5章 有哪些更好的设计过程模型
1.我们需要一个主流的设计模型
2.问题与解得共同演化模型还不够完整
开放式开发对参与人员要求很高，且需要核心力量的存在来保持概念完整性
螺旋模型最有前途，仍有待继续研发
第6章 协作设计
1.现实需要团队设计
2.协作设计会带来额外代价
3.必须对协作设计加以控制来保证概念完整性（总体把握）
第7章 远程协作
1.远程协作不可避免
2.远程协作不是万能的，面对面很重要
3.从需求出发更好地利用远程协作
第8章 设计中的理性主义与经验主义
1.理性证明，理论上可行，实际上的组合复杂度可能无法承受
2.人，大概应该是理性中带有瑕疵（非理性）的吧
因此，缜密的思考可以解决大部分的问题，测试用来弥补非理性带来的瑕疵
第9章 用户模型——错误胜过含糊
1.团队作业与设计系统的复杂性需要明确的用户与用例模型
2.假设可以带来讨论甚至争论，带来更多的思考，从而带来前行
3.错误胜过含糊
第10章 英寸、盎司、位与美元——预算资源
1.每项设计都有自己的关键资源，未必是美元
2.设计师习惯用美元的替代品作为关键资源来考虑问题
3.关键资源是可变的
4.要明确关键资源，并跟踪、控制它（一个人）
第11章 约束是我们的朋友
1.带有明确约束的系统更容易设计。约束会激发灵感
2.仔细地区分各种约束，必要时跳出现有的约束空间
反抗虚假的约束（为了用户与系统的最终利益）
3.优秀的通用设计很难
第12章 技术设计中的美学与风格
1.技术设计中存在美学（优雅），即使是纯粹的智力感受
2.逻辑美意味着简约，但也要易于扩展与组合
结构清晰
一致性（正交性，妥适性（简约性，透明性），普遍性）
3.技术设计中的风格体现于细节（另一方面设计的骨架在整体结构）
4.风格是一套统一的微观决策
5.风格要文档化，不光为了统一设计团队的意识，还包括维护人员
6.思考细节并决策，建立，修正自己的风格
第13章 设计中的范本
1.很少需要全新的设计（从头制造*）
2.可以站在现有范本的基础上
3.我们需要互相借鉴
4.学习范本需要书与文档。但我们的文档过于偏重于how，忽略了why以及相关决策来由与背景（经验）
5.关于范本，需要收集
分析、比较、评估，来更好的方便吸收用于指导实践，解决新问题
计算机软件做得还不够，需要研究人员/机构继续总结
6.并不是所有的问题都可以用已有范例解决
但了解的越多，基础就越扎实，越有助于做出好的设计，越有助于产生新的创意（改进）
7.创新的好的，但不应该成为目的
不应该偏离设计的本来目的。不要让欲望（个人愿望）冲昏头脑。
8.独创性应该用于用户界面/体验，而不一定非要是设计、开发技术等
第14章 专业设计者缘何犯错
1.专业设计人员所犯的错误，不是低级的简单错误，而是自以为是引起的根本错误，
即：设计了错误的东西（会很快过时）
2.不要迷信新技术，要站在一个更高的角度上来认识/理解/应用它
3.难得的是认识到（自己的）错误
4.成功更要反思
第15章 设计的分离
1.作为软件工业进步的必然（?）结果，以及越来越复杂的设计要求，
设计（者）与实现（者）/用户的分离不可避免
2.为了避免沟通不良带来的问题
(1)加强用户场景体验（模拟环境）
(2)迭代式设计
(3)将实践过程提前，(阶段)并发展开
(4)加强实践（不光是书本）的教育
第16章 展现设计的演变途径和理由
1.设计文档除了记录下设计本身，还要有设计演变及设计理由
2.由于知识的网状结构，表现形式具有挑战性
3.设计可以（并应鼓励）发现新的需求，潜在的方案
4.决策树结构会发生变化，记录下变化不容易
5.决策间关联太强导致决策复杂度增大但保有灵活性
决策集中模块化简化设计决策但失去灵活性
6.可视化工具可以帮助我们。但过于死板（太细）或繁琐会失去可用性
第17章 计算机科学家的建筑设计理想系统——从思维到机器
第18章 计算机科学家的建筑设计理想系统——从机器到思维
*s关于建筑设计系统的构想过程：
1.目标
2.设想（progressive truthfulness，模型库）及优缺点
3.人机交互
指定动词、名词、文本、副词、视点/视图
(2)系统的表现形式
多个并发视窗（草图与绘图视图、2D视图、3D视图、外部视图、工作本视图、说明视图）、声音、触觉
4.泛化
5.可行性
第19章 卓越的设计来自卓越的设计师
- 设计过程的根本目的在于可控，保证成功。而不是为了卓越的设计。
- 通过设计过程过度限制优秀的设计人员会：
- 损失优秀的设计
- 增加（时间）成本
- 降低士气
- 医生有两种，一种是按照规章按部就班的普通医生，一种是用心和灵魂看病的伟大医生。--百家讲坛《名医是这样成名的》罗大中
1.卓越的设计来自卓越的设计师，而非来自卓越的设计过程
2.设计过程会抑制卓越的设计（为了给混沌的创新设计带来秩序）
(2)设计过程的目的是确保产品按照预想做出来，带有过多限制（可控）
(3)设计过程鼓励利用以前的经验，这些经验未必适用（背水一战，不许失败）
(4)设计过程倾向于否决，目标是防止错误与疏漏
因此每前进一步都需要很多人达成一致
(5)在一个标准设计过程中，很多专家所处的位置决定了他们的职责是挑错，而不是产生好的设计
（导致设计*妥协磨去棱角）
(6)设计过程中规则会越积越多（官僚主义，不灵活）
(7)设计过程大量占用设计人员的资源（时间）
3.设计过程可能更适用于跟随式产品
4.设计过程可以提高设计的平均水平（短板）
5.能力的分布是不均匀的，每个人都拥有自己特别的地方
6.卓越的设计需要大胆的，追求卓越设计的领导
7.好的（鼓励卓越设计的）设计过程，应该
(1)只关注大面，而非所有细节（避免过度保护）
(2)提供灵活的机制（规则可以被打破）
8.信任主设计师来保证概念完整性
(1)经理不要干涉设计
(2)确保主设计师的权威
(3)保护主设计师不被干扰
(4)主设计师的要求被重视并满足
第20章 卓越的设计师从哪里来
1.设计师的教育必须有充足的实践（及反馈）
2.招募设计师时，要清楚要求是什么，并多看实际工作
3.应该审慎地培养设计师
(1)建立真正的发展双轨制，明确设计人员应有的威望
(2)给他们正式的教育（培训），跟上发展，加深加宽认知
(3)规划多样的工作经历
(4)短期的休息可以恢复精神，开拓视野
4.管理设计师要注意发挥每个人的特性
5.保护设计师防止他们分心，不受管理者干扰，不去做管理
6.培养自己成为一名设计师，不断画草稿记录下自己的想法，请别人来评价自己的设计，学习前人的经验
第21章 案例研究：海滨小屋“View/360”
教训1：明确预算资源，越早越好
教训2：时刻注意约束条件的变动，跟踪好它们
教训3：多想想理由
教训4：多检查
教训5：仔细考虑将来的维护
第22章 案例研究：增加厢房
1.设计一个满足成本要求的系统，应先满足功能，再考虑成本（削减功能/追加预算），
2.教训：
(1)在设计上多花时间是值得的
(2)多与用户交流，多展示用户能理解的原型
(3)多测试用户用例
(4)多复查。确保自己能理解工作内容从而确保它们是正确的
第23章 案例研究：厨房重新建模
1.把设计决定的理由和过程都记录下来
2.在设计上多花时间是值得的
3.多交流有助于产生好想法
4.多执行用户用例，多利用原型，来更深入地了解/验证需求
第24章 案例研究：System/360体系结构
1.在团队中保持认识一致，很难
2.概念解耦（正交性）让设计更清晰
3.留出充裕的设计时间
4.保证实现符合设计（手册）
5.设计竞赛可以(1)解决问题(2)让所有人关注关键问题(3)提升士气
6.全新的设计早期要多投入到性能指标及重要属性的制定，以及关键资源的确定
7.全新的设计早期要多投入到说服其他人跟上新的观念
第25章 案例研究：IBM Operating System/360操作系统
不足：
1.OS/360太过丰富，加入了太多不重要的特性。实现了一种有史以来最好但过时的调试方法。系统生成太灵活以至太复杂，应该提供一些标准配置并在此基础上提供全方位支持
2.没有信息隐藏的思想
3.没有在早期设计阶段引入虚拟内存
4.调度进程JCL从开始就做错了东西
5.数据管理系统具有不必要的复杂性
6.没有坚持使用当时最好的高级语言PL/I，而使用了PLS——加了一层语法糖衣的汇编语言（思维定式）
经验：
1.给予系统架构师以充分设计授权
2.给予设计和原型足够的时间，投资会产生回报
第26章 案例研究：《Computer Architecture: Concepts and Evolution》图书设计
1.贪多不如简洁
2.行百里者半九十（认识到这一点并有针对性地计划）
第27章 案例研究：联合计算中心组织：三角区大学计算中心
1.早期明确用户需求有利于快速确定整体架构
2.提供终极方案保证关键用户需求得到实现
3.多沟通
4.多利用专家的知识