设计讨论：好设计长什么样？

  怎样的设计算得上好设计？

  就如一百我的眼中有一百个哈姆雷特同样，这个问题多半也不会有标准答案。况且，脱离了具体和细节的业务需求，设计、架构之类的讨论也只剩套路了。

  不过，前两天想了想这个问题，仍是记录一下吧。

  最基础的一点，确定是功能正确。若是一个设计方案，各类高上大的框架飞来飞去，结果却不能保证功能是对的，那么这方案从根子上就是失败的。

  我前两天写了一个小需求的设计，思路是把行计算改为并行计算。并且我用了新的并发stream和ForkJoinPool，感受忽然高上大了起来。结果并发一开，连计算结果都错了。哎，臊了一脸。

  反过来的例子就不胜枚举了。

  在功能正确之上，是健壮性。包括幂等性、容错性、可用性等。简言之，出现非正常操做时，系统仍然可以处理。

  前阵子一个同事设计了一个申请功能。他设计的逻辑是：在申请前，须要校验状态位state!=A；而申请后，这个状态才会被设置为A。结果，当同一笔数据先后两次发起调用时，第一次调用成功，第二次却跑出了异常。这个设计在幂等性上就存在问题，也就是健壮性上存在问题。

  容错性稍难点。Java中最基础的作法是try-catch。可是try-catch也有难处。一是异常自身的层次很差；二是异常处理中须要考虑一些关联问题，例如事务的回滚与否、JMS消息是否重试，等等。

  可用性比较好理解，简单说就是多点多活。多点多活能够用多线程的思路来设计，可是这个多线程，容易并发、难于同步。

  再往上，我认为是扩展性。扩展性不单单是系统、技术上的问题。它须要设计师对业务有充分、深刻的理解。

  例如，技术上，若是咱们要把某些功能收在包内，把类、方法的可见性设定为friendly或者protected就行。可是业务上呢？哪些业务功能要收在这个模块内、哪些业务功能能够开放为系统服务？这是须要业务、技术两栖人才能想明白的。

  不过，扩展性与这个有什么关系呢？扩展性所考虑的，不少时候就是这类依赖性的开、闭问题。哪些东西能够开放、哪些要关闭；这个功能能够依赖哪些模块、不能依赖哪些模块，这就是依赖性的问题。

  把功能作正确、作得不出错，这还算是“需求翻译机”的范畴。把功能作得有良好的扩展性，这才进入了系统设计的大门。

  扩展性能够解决开发效率的问题。更进一步呢？我认为更进一步的设计须要考虑性能，这一系统运行效率的问题。系统毕竟是拿来用的。

  我这两天正在作一个性能优化的需求。这套功能在扩展性上来讲算是很是不错的了，前两天刚刚经历了一个大需求的考验，三口两口就吃下去了。可是它的设计几乎是反性能的——例如同一个耗时操做在循环体内执行屡次，例如循环操做没有并发，例如资源池不够大，等等。这样的设计，我最多给40分。

  不过，良好的扩展性优点在此次优化中也显现了出来。方案定好后，我很快就完成了此次优化——这实际上也是一种“扩展”，用性能更好的方案替代原有方案。

  不过这也是有点侥幸。更多的性能优化是须要突破原有框架、模型的。久远点的如socket，它打破了七层协议的界限，一个“人”处理了端口、ip、字节流等多个协议层的功能。但它也确实比http等乖宝宝的性能要好。又如我此次的优化中，也存在用缓存、ThreadLocal等方式来跨线程调用栈执行REST操做的地方。

  除了性能以外，还有一个目标须要考虑：易用性。这点主要是针对技术工具、组件或者框架来讲的。EJB之因此被淘汰掉，一个重要缘由就是太难上手、使用了。而Spring系列框架的生命力一直如此旺盛，与它的简单易用也有很大关系——更别说它如今还推出了spring boot。

  

  功能正确、健壮（幂等性、容错性、可用性等）、扩展、性能、易用，这些就是我理解的一个好的设计的评价标准。