《精益开发与看板方法》—1-3-6 嵌入完整性（Build integrity in）

1-3-6  嵌入完整性（Build integrity in）

没错！这正是我需要的东西。

——客户

这是一个多变的时代，许多东西的定义也跟着一直在变。例如 App 的好坏改变了质量的定义，当你安装了一个让你恨不得立刻推荐给所有朋友的 App 时，不管它有多少缺点，你在推荐的当时一个都不会提到，因为它已经满足你真正的需求了，所以你只会注意到它做了些什么，而不会在乎它的缺陷，也就是所谓的“情人眼里出西施”，此时的质量就是西施。

如何造就这样的产品呢？

波彭迪克夫妇将上面这种感知区分为感知完整性（Perceived Integrity）和概念完整性（Conceptual Integrity）。

你一定也有过这种感觉，例如常常用谷歌来搜信息，谷歌的搜索引擎就是最典型的感知完整性的例子。当你要寻找数据时，就一定先打开谷歌，原因可能是它很快，让你觉得找东西一点也不烦，还有就是打错字了它也照样找给你，就是这些特征让大家持续使用它。换句话说，就是谷歌打动了人心，这种特征也称为外部完整性。

另一个例子来自微软办公系列的 OneNote 产品，它兼具感知完整性和概念完整性（又可称为内部完整性）。不论你在哪一个办公应用产品中做 PPT，或是在 Word和Excel 工作，只要想到要把数据记录下来，你就会点击任务栏上的OneNote图示，启动它来做笔记，原因是它什么都可以记，没有特定格式限制。不管放进去的东西是什么格式，放进去就对了，太符合人类想储存东西时的想法，你不会想先做分类再来记录的。因为方便使用（外部完整性），而它又能融合办公应用多种工具存取能力的一致性（内部完整性），所以OneNote就成了办公应用中最受欢迎的工具程序。

根据波彭迪克夫妇的论点，认为要构建具有高度感知完整性和概念完整性的系统，应该在客户与开发团队之间以及开发团队的上下游过程之间形成出色的信息流（information flow），而此信息流必须考虑到系统当前和潜在的用途。具体怎么做呢？

l   增加全体开发人员在应用领域方面的知识。

l   接受变更，并将变更看成是一件正常的过程和容纳新设计及决策的能力。

l   营造提高沟通能力的环境，以便对人员、工具和信息进行整合。

成就感知（外部）完整性

每天都能持续把客户的价值观变换成细节设计给开发团队，不断积累开发部门在感知完整性方面的决策能力。但是容忍过多的变化容易让开发团队不断在做返工的动作，成本也会不断增加，如何是好？这一点可以参考 Scrum 的迭代开发模式，也就是冲刺（Sprint）的做法。

在一个短的开发周期内尽量让开发人员不受干扰，全力开发产品直到 Sprint 结束时再对客户进行展示，并运用这个时间点来接受客户的反馈，将其纳入未来的开发工作。

成就概念（内部）完整性

概念完整性表示系统的核心概念是否能稳定内聚而发挥整体效用。这是架构性的问题，它牵扯到各个组件之间是否匹配并且可以发挥作用，也就是说，架构是否能够有足够的灵活性、可维护性、有效性和响应的平衡能力，说穿了就是能有效响应客户需求的架构设计。这是赋予概念完整性的能力，它有着一种天生的复杂性，为了让团队能够克服其中的复杂性，必须建立良好及有效的沟通机制来适度降低复杂性，这可以依靠一种看似重复工作但又像是设计的行为来实现，我们称之为“重构”。

重构（Refactoring）

改进不只是为了满足客户需求，改进之所以必要，是因为复杂系统的某些效果在设计时未能受到充分理解。重构是一种按部就班的设计方式，就是先设计让它能起作用，了解它的缺点，然后再对设计加以改进，这便是重构式的设计。

重构式设计属于浮现式设计。一般的工程师只是把重构当成重新整理程序，在重整的过程中尽量让输出/输入的结果不变，只改善程序代码的正确性与简洁度。这是基于测试驱动开发的理论所发展出来的重构方式，其目的与基于浮现式设计所做的重构是不同的，后者是用来改善设计的。

如果是基于测试驱动开发重构，第一个重构动作应该是重新命名变量或函数。如果是基于设计的重构，第一个重构的动作应该是拿解决的问题套用现有的设计模式，看看是否能找到合用的模式，然后进行延伸式的套用让模式融入到现有环境中。

有以下两种不同目的的重构。

l   为了解决程序稳定性及增加可维护性的重构。

l   基于浮现式设计所做的重构。

一般而言，在采用敏捷迭代开发方式时，都会害怕这种增量式开发方法会把架构设计弄得支离破碎，许多设计一直被需求变更弄得失去效用或成为累赘。请注意一点，出色的设计本来就应该随着时间的改变而能持续演进，因此重构式设计正好能够符合这个现象。

重构不是一种浪费，当我们在向客户提供商业价值时，重构反倒是避免浪费的方法之一。