可读的艺术 少写代码

艺术就是艺术，在结构清晰之后的下一个话题是减少代码，减少代码对于可读来说绝对是正面的影响。不过问题是怎么才能少写代码呢？书中给出了两个方法，1. 砍需求，2.重用已有代码。都挺有感触，不过重用已有代码之前有很多的内容讨论过了。今天说说第一点砍需求。

砍需求分为两个阶段：质疑和拆分；质疑是一个我们在Scoping的时候主要使用的技能，这个需求真的解决客户的问题了吗，或者换个说法，不做这个Story用户会面临什么样的问题？是不是还有更优解? 每两周的周四我们基本上就在干这个事情。

那么到了开发手里，这个质疑整个Solution的情况就会较少发生，这时候往往会发生的事情就是拆分，因为很多大的Story，基于Solution会延伸出非常多的影响点。这些影响点如果要一一处理，这个需求在规定的时间内就完不成。在这个时候我们更需要的是抓住主要矛盾，利用前置条件减少影响点，将非主要矛盾部分的需求拆分出去。

举一个今天早上Design的例子，这个Story说的是在运单查询页面上支持费用的修改和保存，运单查询的每一行就对应一个运单，其中有一些费用的列，用户希望金额可以直接修改，需求挺清晰，也蛮合理（这个界面上已经有不少字段支持修改了）。

不过难度是有的，费用本身有一点复杂度和特别逻辑：比如说，1.同名的费用会被合并求和在一列中显示；2. 费用与应付之间可能存在分配的问题（面上看着是100，背后不一定）；3. 费用本身可能存在限制修改的情况（这个也很复杂，有费用的审批状态，接口状态等等）；4. 有一些运单可能没有特定费用，这一格子就是空的；以上种种都是这个Story Design过程中考虑到的问题。每个可能都不好处理。那么我们回过头来想想用户需求，在大部分情况是用户在费用提请之前能够方便的批量做出修改。那么在这个需求的前提下，上面几种特别的情况我们就完全可以做出简化处理：

1. 被合并的费用。这一格可以简单处理成不允许修改；

2. 费用与应付的关系。这一个也可以简单处理成非1：1的情况不允许修改；

3. 费用本身限制修改的多种情况。与费用单笔修改的限制逻辑保持一致（最好抽取成同一个方法）。

4. 之前没有费用的情况。空的格子不允许填写数字。

上面的四点处理，1，2，4实际上是增加了这个功能的前置条件，限制了这个功能的适用范围，作为一个便利性的批量功能，在初次上线的时候能满足用户8成以上的情况就非常不错了，确实有必要可以在后续做增强；

3，实际上是代码重用，这个在本轮可能由于遗留代码的结构和处理方式问题没法实现，不过任然可以作为一个后续的工作项来优化。

小结一下：开发在设计是对需求的细化和影响点的思考是非常有必要的，但是并非所有的影响点都需要实现，有的时候通过前置条件的约束来减少影响点，保证主流程的实现是一个推荐的做法。