1. 概念完整性

1.1. 当概念组合成一个软件时，它们能够同步以便和谐行为

• 1.1.1. 同步或许会消除一个概念的某些行为，但决不会增加与该概念的标准不共同的新行为

• 1.1.2. 在运用概念规划软件时，即便你没有准确界说同步，至少要压服自己，概念之间的每次交互至少在准则上都能够被视为同步

1.2. 假如概念组合的方法不正确，从特定概念的操作和结构来看，概念的行为或许会损坏它的标准

1.3. 概念违背完整性的行为会运用户感到困惑，由于他们针对概念行为的心智模型受到了损坏

1.4. 当一个由概念组成的体系运转时，每个概念也都作为一个“小机器”运转着，操控着操作发生的时刻及其对概念状况的影响

• 1.4.1. 同步使一个概念的操作与另一个概念的某些操作同时发生，这能进一步束缚操作

1.5. 一个概念不能直接改动另一个概念的状况，也不能以某种方法改动概念的某个操作行为

1.6. 假如概念的完成结构答应它们以其他方法交互，或许代码中呈现过错，那么一个概念或许会以一种违背它本身标准的方法运转

• 1.6.1. 一些调整或许会在保存概念标准的根底上增加一些新的功用，也有一些调整或许会直接损坏概念标准

1.7. 当一个概念与其他概念组合时，坚持概念的完整性至关重要

1.8. 假如你在运用软件或剖析可用性问题时遇到问题，并发现某个概念的行为方法比较反常，请想想这是否能归咎于另一个概念的搅扰

1.9. 为了保证概念完整性，请保证一个看似通用的概念确实是通用的

2. 预定

2.1. 假定有一个餐厅的老板因餐厅的归纳评级较低而感到非常懊丧，他决议侵略该软件来赏罚歹意差评的顾客

2.2. 他修正了软件设置以便歹意差评的顾客在后续预定时，即便没有撤销预定，当他们抵达餐厅时也没有预定记载，因而没有餐桌供他们运用

• 2.2.1. 行为不符合任何合法的同步准则

• 2.2.1.1. 不只将两个概念结合在一起，还损坏了预定这个概念

• 2.2.1.2. 违背概念完整性的行为

2.3. 假定报复顾客的餐厅老板侵略了该软件，使得任何顾客只需发布差评就会失掉在任何餐厅的任何预定

• 2.3.1. 不幸的顾客虽然从未计划撤销预定，但仍或许收到撤销告诉，由于预定概念与告诉概念同步

• 2.3.2. 在给出告诉的状况下撤销预定不侵略预定概念的完整性，由于从预定概念的标准来看，它是彻底能够了解的

2.4. 预定概念的标准没有提及谁能够撤销预定

3. 字体格局

3.1. 文本格局有三个简略的特点：粗体(Bold)、斜体(Italic)和下划线(Underline)

3.2. 真实的印刷体斜体历来不是罗马式斜体，而是更流通和有书法作用的经典版别

3.3. 有了这些丰厚的字体，一切的费事都云消雾散了，但格局切换概念也不再有用

• 3.3.1. 字体概念的扩展损坏了格局切换概念

4. Google Drive

4.1. 同步的意图是坚持两个文件夹之间的共同性，其操作准则是一个文件夹中的任何改动也会作用于另一个文件夹

4.2. 与备份概念不同，同步概念也会传递删去操作，这会让文件有条不紊

4.3. 同步概念的一个根本特点是两个调集中的文件副本彻底共同

5. 战略家、剖析师和技术顾问

5.1. 辨认概念及其价值是最重要的，而规划单个概念的细节则是非必须的

5.2. 考虑的问题

• 5.2.1. 有哪些要害概念

• 5.2.1.1. 要害概念是什么

• 5.2.1.2. 经过构建概念清单，你将取得概念功用的“鸟瞰图”​，即考虑战略举动的视角

• 5.2.1.3. 构建这些概念的依靠联系图，看看它们怎么互相相关，以及哪些概念处于中心方位

• 5.2.2. 概念是否发生了改变

• 5.2.2.1. 当你检查现有体系中的概念时，确认每个概念是何时引进的，并研讨它们是否随时刻的推移发生了改变或继续坚持稳定

• 5.2.3. 最有价值的概念是什么

• 5.2.3.1. 是否有一个杀手级的概念

• 5.2.4. 是否有让人困惑的概念

• 5.2.5. 界说软件系列的同享概念是什么

• 5.2.5.1. 同享同一概念的不同软件互相共同，仍是存在随机的细小差异？

• 5.2.5.2. 假如将多个软件中呈现的概念共同起来，它们将来或许会有同享概念

• 5.2.6. 每一个概念的意图别离是什么

• 5.2.7. 是否有缺失的概念

• 5.2.8. 竞赛对手的概念是什么

• 5.2.8.1. 看看同一范畴的竞赛软件，盘点一下它们的要害概念

6. 交互规划师和产品司理

6.1. 还需要重视单个概念的规划和完成问题，以及概念的可用性问题

6.2. 考虑的问题

• 6.2.1. ①传达给用户的概念是否共同

• 6.2.1.1. 你的软件是否经过它的用户界面、用户手册和协助攻略等支撑资料，将概念成功地传达给了用户

• 6.2.2. ②怎么解说概念

• 6.2.2.1. 令人信服地展现了每个概念完成其意图的规划方法？

• 6.2.3. ③是否有可用性问题

• 6.2.4. ④软件都有哪些概念

• 6.2.5. ⑤是否有冗余概念

• 6.2.6. ⑥是否有概念过载

• 6.2.7. ⑦概念能够被分化吗

• 6.2.8. ⑧是否有用运用了了解的概念

• 6.2.9. ⑨概念是怎么同步的

• 6.2.9.1. 是否存在同步缺乏的状况

• 6.2.9.2. 是否存在同步过度的状况

• 6.2.10. ⑩是否在运用协同效应

• 6.2.11. ⑾概念是否能有用地映射到用户界面

• 6.2.12. ⑿是否剖析过概念的依靠联系

• 6.2.13. ⒀概念是否能够完整地组合在一起

• 6.2.13.1. 每个概念独自来看都是合理的，但当与软件中的其他概念组合在一起时，单个概念的合理性或许会被削弱

• 6.2.14. ⒁概念的常识是否有安全的文档记载

• 6.2.14.1. 一个概念规划或许经过多年的演化，积累了几代规划师的很多修正和完善

• 6.2.14.2. 假如这些常识只能体现在代码中，那么一旦一个新程序员没有意识到其间的奇妙之处而修正了这些代码，这些常识就会丢掉

• 6.2.14.3. 记载一个软件的规划常识是很重要的，从中能够盯梢一个概念的开展

7. 支撑资料编写者、培训师和营销人员

7.1. 用户能够经过这些资料了解软件并在遇到困难时寻觅解决之道

7.2. 考虑的问题

• 7.2.1. 支撑资料是否环绕概念安排

• 7.2.2. 概念是否具有清晰明确的意图

• 7.2.3. 概念的操作准则是否能解说清楚

• 7.2.4. 概念的解说是否合理

8. 程序员和架构师

8.1. 依靠联系图能够用于区分开发阶段，也可用于规划版别晋级道路

8.2. 考虑的问题

• 8.2.1. 哪些概念调集可用于构建最小可行产品

• 8.2.2. 哪些概念完成起来很有挑战性

• 8.2.3. 能防止重蹈覆辙吗

• 8.2.4. 是否在恰当的当地运用了标准库概念

• 8.2.5. 概念是否尽或许通用

• 8.2.5.1. 是否运用了不必要的特别数据类型

• 8.2.6. 能否将概念模块化

• 8.2.6.1. 概念之间是否存在能够消除的代码依靠联系，使得概念更简单被修正和重用

• 8.2.7. 概念之间是否存在杂乱的同步

• 8.2.8. 有些概念操作是否触及杂乱的条件

9. 研讨人员和软件哲学家

9.1. 考虑的问题

• 9.1.1. 概念目录应该怎么构建

• 9.1.1.1. 概念目录或手册既有助于规划师记载他们的专业常识，也可使新手更简单取得这些专业常识

• 9.1.1.2. 概念目录对概念的重用也大有裨益，能够协助规划师防止已知的圈套

• 9.1.2. 是否存在复合概念

• 9.1.2.1. 一个概念被分化成更小的概念时，这个概念是否依然具有本身的权益和意图呢？

• 9.1.3. 是否存在不同品种的意图

• 9.1.3.1. 一个概念的意图决议了是否应当规划该概念

• 9.1.3.2. 标签概念和文件夹概念的意图都是收拾文件，这个意图使得它们都能够被归入规划，但只要标签概念才有过滤文件的意图

• 9.1.4. 通用概念的实例化会发生什么问题

• 9.1.5. 操作同步是否满足

• 9.1.6. 怎么论述映射准则

• 9.1.7. 关于用户行为的假定在概念规划中扮演什么人物

• 9.1.7.1. 有些概念只要在用户做出某种特定行为时才干完成其意图

>  9.1.7.1.1. 只要当用户设置高强度暗码、记住自己的暗码并且不同享暗码时，暗码概念才干供给有用的身份验证

• 9.1.8. 概念能够完成彻底模块化吗

• 9.1.8.1. 微服务架构或许是完成概念的一个有用根底，其间每个微服务架构代表一个独自的概念，或许被称为“纳米服务”更适宜

• 9.1.9. 能够在代码中检测到概念规划缺点吗

• 9.1.9.1. 不标准的概念不只让用户困惑，也让程序员困惑

• 9.1.9.2. 当概念不清楚时，代码就会更紊乱和有更多缺点

• 9.1.10. ⑩概念能否应用于API规划

• 9.1.10.1. 概念是面向用户的

• 9.1.10.2. 程序内部运用服务或API时发生的许多问题与用户面临的问题很类似