读软件设计的要素06概念完整性.png

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时产生的许多问题与用户面对的问题很相似