设计讨论:好设计长什么样?

简介:

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


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

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


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

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

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


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

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

  容错性稍难点。Java中最基础的做法是try-catch。但是try-catch也有难处。一是异常自身的层次不好;二是异常处理中需要考虑一些关联问题,例如事务的回滚与否、JMS消息是否重试,等等。

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


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

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

  不过,扩展性与这个有什么关系呢?扩展性所考虑的,很多时候就是这类依赖性的开、闭问题。哪些东西可以开放、哪些要关闭;这个功能可以依赖哪些模块、不能依赖哪些模块,这就是依赖性的问题。

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


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

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

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

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


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


  

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



本文转自 斯然在天边 51CTO博客,原文链接:http://blog.51cto.com/winters1224/1888737,如需转载请自行联系原作者

相关文章
|
6月前
|
前端开发 算法 芯片
后道设计
后道设计
39 1
|
存储 算法 搜索推荐
一文探究系统分析与设计的逻辑性
「软件分析」与「软件设计」这样的词眼经常听到,然而要真正理解「软件分析」和「软件设计」的本质是比较难的,本文带你了解软件分析与设计的「逻辑性」到底是什么。
1021 24
|
6月前
|
运维 前端开发 JavaScript
平台设计-概念澄清说明
平台所说模块一般指一个独立部署的前端项目
|
存储 分布式计算 Hadoop
了解基础讨论数据
了解基础讨论数据
43 0
调查表设计
调查表设计
85 0
|
Java Scala
深入理解简单设计
深入理解简单设计
深入理解简单设计
|
算法 BI
贪心策略设计并解决会场安排问题
贪心策略设计并解决会场安排问题
326 3
贪心策略设计并解决会场安排问题
|
缓存 Java 数据库
详细设计-设计讨论|学习笔记
快速学习详细设计-设计讨论
114 0
|
存储 算法 容器
设计模式概念总结
      这为我的学习笔记,原文为https://www.cnblogs.com/zhili/p/DesignPatternSummery.html 1.单例模式(Singleton)    确保一个类只有一个实例,并提供一个全局访问点 2.简单工厂   优点: 简单工厂模式解决了客户端直接依赖于具体对象的问题,客户端可以消除直接创建对象的责任,而仅仅是消费产品。
919 0