工作多年，我见识过各种各样的表达方式，有相当务实的技术派wiki，也有富有展现力的ppt，还有现在团队每半年搞一次的ppt形式的业务价值证明汇报。不管是哪种形式的表达，只有让表达者可以舒服地、清楚地讲出自己的想法，让听众可以高效获得有价值的信息，才是好的表达方式。因此，不必拘泥于某种表达方式，更不必限定于某种思考方式。

我发现大多数程序员在表达技术方案时，往往喜欢从技术实现开始讲。为什么从技术实现开始讲呢？我理解是因为技术实现是技术产出的体现，也是技术难度的体现，它是程序员获得报酬的核心依据。然而，当我们已经在描述技术实现时，我们其实就已经限定了该项技术方案的使用方式。大多数人对使用方式这个事情，要么觉得它顺理成章（大家都这么用，所以我的技术方案也是这么用），要么没投入足够思考，很少去思考还有没有更好的用法。我们看这个世界，那么多的技术研究、技术发明，归根到底还是为了让大家更好地使用功能，满足需求。因此，使用方式，应该放在技术实现的前面。

1. 表达框架

  1. 背景、目的（解决什么？提升什么？）
  2. 多种使用方式设计方案（使用者怎样使用来达到目的），从中比较并选出使用方式最佳的方案
  3. 设计方案的实现方式分享

说明：如果对于第2点选出的最佳使用方式，没法或很难实现怎么办？此时可以说明是因为实现难度大，因而选择次之的使用方式方案。

2. 案例

接下来我通过一些很具体的小例子，来示例这种表达方式。

2.1 分布式环境下的锁

  1. 背景和目的：在分布式环境下，一个java应用会部署多个实例，而有些方法我们希望它是串行执行的，就像java单机应用中的synchronized一样，串行执行。

  2. 多种使用方式方案：

    1. 代码调用的方式：代码里调用组件的lock(int timeout)，finally {unlock()} 的方式加锁和解锁。组件需要用到redis。
    2. 使用注解的方式，在需要串行执行的方法上注解@Synchronized，即可。和@Transactional一样，注解的方式需要确保AOP是生效的。

    方案比较：方式1比较手动，容易编码出错，相比之下，方案2对使用者更友好，不必关注unlock操作。

  3. 方案2的实现方式分享。

2.2 导入excel录入数据的报错提示

  1. 背景和目的：有些业务系统习惯用excel录入和修改数据，但是由于excel导入的表单校验，远没有页面表单校验友好，用户上传的excel常常检查出很多问题，用户会根据报错信息多轮修改，最终才能提交上来，录入体验不佳。

  2. 多种使用方式方案：

    1. 每次上传提示第一个报错的单元格的行号、列号，报错原因，在页面上弹框提示
    2. 每次上传提示全部报错的单元格和报错原因，在页面上以弹框表格方式展示
    3. 每次上传，如果检查出问题，那么提供一份excel给用户下载，下载的excel打开后可以在每个出问题的单元格上用excel的标注指出是什么问题。

    方案比较：方案1上传1次只检查1个错误，如果错误数很多，用户需要N多次操作才能改完错误，体验最差。方案2和3都能提示出全部错误，解决方案1麻烦之处，相比之下，方案3可以直接帮用户指出哪个单元格有问题，节省方案2用户需要自己找寻单元格的问题，也不需要边改excel边看页面来回切换。

  3. 方案3的实现方式分享。

2.3 科学上网

  1. 背景和目的：由于运营商或其他因素的影响，导致我们无法访问到需要访问的网站，或者访问到不该访问的网站。我们希望解除掉这些限制，科学上网。

  2. 多种使用方式方案：

    1. 在电脑、手机上安装个客户端，启动之后简单配置一下，即可。
    2. 电脑、手机连接上某个wifi，即可，科学上网的事项由wifi完成。

    方案比较：方案1优点是电脑手机到任何网络下，都能使用，缺点是需要安装客户端，如果是电视或某些特定手机，安装客户端难度大且麻烦。方案2的优点时使用简单，接入wifi即可，缺点是如果移动网络或不在该wifi下，则无法科学上网。因此，两个方案需要结合自己的使用场景来定，如果是家用，家里人很多手机和设备，或者是公司用，公司里很多员工，那么方案2是更优的。

  3. 实现方式分享。