每两周的周四在过去的几年间都有点挣扎，因为这是我们争论下个版本做什么的时候。开发希望简明，清晰，有价值的story，BA希望最大程度满足客户的需要，所以往往会产生激烈的交锋，我们通常把这个过程称为S。不过近几轮下来有点越来越和谐了，感觉大家都在相向而行。赞！
继续修炼，今天的话题契约式设计的含义非常的广泛，就书中的定义来讲也十分清晰。一段程序或者一个方法，必须要始终保持一个清晰不变的契约。什么是契约？文中给了三个部分，
一个是前置条件，明确调用这个方法有啥要求？
第二个是后置条件，说明这个方法调用完成后是什么结果？
第三个叫不变式，说明调用前后不变的是什么？
这个不变式我并没有太理解，我认为后置条件既然说明了方法调用后的结果，他当然应该清晰描述调用后哪些东西产生了变化，剩下的所有东西自然都应该不变，为啥还要强调一个不变量？不懂，明天问问我师父。
先把第三个事情搁在一边，契约还有两个有意思的问题，第一个是前置条件和后置条件哪个更重要呢？
标准答案是都重要，不过显然后置条件是所有方法都会关心的点，即使不是契约式设计，我相信方法的效果通常也会说得非常清楚。难点还是在前置条件，这是经常把我们的程序搞死的地方。
拿书中这个最简单的例子来看，说一个做开方的方法，前置条件是什么？首先需要是一个数字；够了吗？不够，还需要是一个非负数；够了吗？大部分情况不够，是不是要定义一下最大能处理的数字；够了吗？可能还不一定够，最好把他定义为一个double型的非负数，基本上OK了。
一个方法的前置条件是不是够清晰完善往往并不那么一目了然。一定仔细要思考一下。
第二个问题更有意思，说前置条件该由谁来检查？
书中有一个明确的答案是由调用方来检查，想一想感觉不是那么服气，如果由调用方来检查，方法本身任由不符合前置条件的调用方大摇大摆的进来，容易产生不可预期的结果。难道不应该在方法中拦截一下吗？所以比较安全的做法是双方检查，但是调用方有一个更大的责任，叫做保证。调用方应该确保调用时满足前置条件，否则没法得到预期结果的责任在调用方。
举个例子，我们时不时的会发现有一个字段过长的exception，存入数据库的数据超出了预期长度。在这个例子中有一个非常明确的前置条件就是数据库的字符长度。那么修复的方式是在调用前做保证，比如限制页面的字段输入长度，或者处理接口字段的长度等等，数据库呢他明显也做了检查，所以抛出了异常，但是他不对这个异常结果负责。
正好我们最近想尝试的一个接口需求设计review流程，其本质也是想把接口之间的契约制定的更加清晰。使我们这个感觉上最有变化风险的部分能更稳定，可靠。
