面向实现的含混性

给本书评5星，并不是因为我觉得它写得很好，仅仅只是因为没有人比它写得好了。

本书和《你的灯亮着吗》可以看做是姐妹篇，虽然内容上看起来差别很大，但是它们实际上是一个有机的整体。温伯格在本书中着力介绍了降低需求含混性的各种方法，但实际上这些方法仅仅只能用来降低实现的含混性，至于另一方面的含混性的降低，就需要看《你的灯亮着吗》这本书了。
含混性，描述的是不清晰的程度。而对于软件开发来说，事实上含混性存在两个方面，其一就是本书讲的实现方式上的含混性；另一个就是对目标的含混性，即同样的需求可能对于完全不同的目标，而那些潜在的目标直接影响到软件（前卫一点说是服务）未来的演化方向。如果我们希望构造一个软件（或者服务），即能很好的满足用户当前的需求，又能使得我们未来可以比较方便的拓展这个软件（服务）的功能，比较方便的实现软件（服务）的演化，那么在这两方面都降低含混性，就可以很好的帮助我们实现目标。
科学的方法大多需要量化的度量技术，温伯格在本书中提供了一种方法，这也是我选择看这本书的原因。虽然他一开始就说他有这个公式，但是直到本书的最后，他才把这个公式给拿来出来：含混性==实现需求的最大花费/实现需求的最小花费。这个公式非常的好，特别是在报价时期，可以快速的确定是否还需要更详细的需求。如果需求过于抽象，那么这个公式给出的含混性就可能非常的大，而这种随意性很大的估值是非常忌讳的，很可能会造成亏本。

严格的进行分析，这个有利于估价的公式并不一定非常合适，决定含混性的，始终还是应该由实现相应需求的不同方案的数目来确定。含混性毕竟还是对这种实现的不确定性的度量。按照成本来度量，可能会存在两方面的问题，其一，许多不同的方案花费相差不大，在具体实现的时候可能会造成一些执行上的偏差，但是这种偏差在最开始度量的时候体现不明显；其二，虽然成本一般都是连续的对应着相应的解决方案，但是不排除少数解决方案之间存在大的成本跨度。这些大多主要影响到实现，不过确实也需要提前注意。

由于本书的年代比较久远，所以最近的一些新的开发思想和本书所提到的思想之间存在一些偏差的地方。本书着重强调的是通过不断的细化需求来最终减少实现的含混性，但是事实上这并非唯一的办法。
首先需要明白，需求是什么：
1.需求是一个屏蔽了底层实现的操作,它实现了状态的转换.(很抽象吧,那是当然的,因为我们平时说的根本就不是需求,而是另一个东西)
2.用户(提出)的需求是用户个人认为的对自身目标的最佳解决方案中,自己不能或者不愿意完成的部分,目标和解决方案具有相对性.
既然需求被这样定义，那么减少含混性的办法就有两条路，其一，正如书中写的一样，当我们发现存在比较大的歧义的时候，自己通过交流的方式来降低这种歧义；另一种，我们还可以拔高我们的底层实现。很多时候，歧异来自于我们自身一定强大的能力，因为我们有足够的能力做到多样性，而这些多样性都体现出各自的特点，所以我们才会有了如此众多不同的选择。如果这些实现办法最终所表现出来的效果差距不大的时候，是的，我们就可以把他们整合到一个平台上，利用这个平台屏蔽这些具体实现。那么向上来说，歧义被降低了；而向下来说，各种实现之间的差异大大的减小了，具体采取那种方式来实现平台的要求，也差不多无所谓了。对，这就是我们现在很多时候采用的方法。SOA，将底层实现的级别提升到了服务级别；又或者在模型转换中，在4个层次上向下屏蔽了各种有差别的实现。甚至在更早之前，汇编语言，C语言，面向对象语言，动态语言，都曾经提高过这种实现的级别。

未来我们将有机会高枕无忧吗？我们最终将彻底战胜面向实现的含混性吗？也许永远也不可能，因为我们的捆饶正来自于我们的能力，能力越大，梦想就越大，困难也就越大，同样的，我们提出需求的级别也在不断提高，需求与实现之间的差距并没有最终被弥合的可能性。因为向上含混性，是无解的。