设计匠艺 | 小即是美之一

博尔赫斯说:“写散文体的短文——寓言、神话、短故事——给了我某种神秘的满足。想起这些篇章,就仿佛想到硬币:实在、结实、闪光的小物体,更多的东西的样品。”显然,小物体之美,让博尔赫斯着迷。

同样,在软件设计领域里,小的设计同样让我着迷。这里所谓的“小”,并非绝对的小,而是强调一种恰如其分的设计哲学。在开发过程中,每一次迭代的目标不宜设立过大,需小步前行,避免过度设计。在设计开发时,整个系统最好由松散耦合的细小模块组成。这些细小模块由于功能相对独立而单一,因而更易于理解。

在设计系统架构时,我们要注意克制做大做全的贪婪野心,尽力保证系统的小规模。Unix的缔造者之一Dennis Ritchie就曾遭受过将系统做大做全的滑铁卢。他在贝尔实验室的第一个任务,是参与大项目Multics,即开发一个前所未有的、可以多人使用的、同时运行多个程序的操作系统。该项目由贝尔实验室、麻省理工学院和通用电气公司三方联合研制,但是由于设计过于复杂,迟迟拿不出成果,1969年贝尔实验室宣布退出。

痛定思痛,Dennis Ritchie和同事Ken Thompson之后在设计Unix时,就吸取了Multics设计复杂而导致失败的教训,提出了"保持简单和直接"(Keep it simple stupid)的原则,即所谓KISS原则。

遵循KISS原则,整个Unix系统由许多小程序组成,每个小程序只能完成一个功能,任何复杂的操作都必须分解成一些基本步骤,由这些小程序逐一完成,再组合起来得到最终结果。表面上看,运行一连串小程序很低效。但是事实证明,由于小程序之间可以像积木一样自由组合,所以非常灵活,能够轻易完成大量意想不到的任务。而且,计算机硬件的升级速度非常快,所以性能也不是一个问题。另一方面,当把大程序分解成单一目的的小程序,开发变得容易,Unix在短短几个月内就问世。

我们千万不要轻视小的力量。

专注的小可以保证独立进化,从“自治”思想看,它需要实现一定程度的自给自足,并保证对外交互的接口足够稳定。这符合老子的“大国小民”的思想。在框架设计上,为保证框架的小,常常会运用内核模式,识别出整个框架的核心功能,作为整个框架的基础。其余功能皆可视为框架的外围功能,根据关注的域对其进行切分。这些外围功能互相之间应尽量减少耦合,使其能够独立进化。Spring框架的设计正是遵循了这样的设计理念。除了Spring IoC是整个框架必备的组件之外,Spring MVC、Spring Batch Job、Spring Data等之间没有依赖关系,可以根据项目自身情况酌情裁剪。

那么,如何才能保证设计的系统足够小?首先,在设计思想上要确立“小即是美”的美学观,要清晰地辨别且能够欣赏小的灵活之美,完整之美与轻盈之美。只有在思想上认同它,你才能顺势而为;只有从心理上感受到这种美丽,你才能响应它的召唤。

灵活之美,在于它能快速地响应变化,这种变化可能是局部的,也可以是整个设计方向的改变。例如,在多数企业系统和互联网系统中,都需要分离Online和Offline任务,以指定不同的架构决策。又例如,我们可以设计独立的、具有最小功能子集的Batch Job来承担后台任务。这些Batch Job可以作为一个单独的应用程序执行在单独的进程中。一旦需求要求我们对设计做出改变,我们也能将修改控制在足够小的范围中,从而保证对整个系统不会带来巨大的影响。

若遵循EDA(Event Driven Architecture)模式,我们可以根据业务领域的不同,设计出功能最小完整的自治组件。组件之间的通信通过事件来传播,利用发布者/订阅者的方式解除组件之间的耦合;又或者利用消息传递来处理业务逻辑,例如在AKKA中,我们可以设计出灵活而小的Actor对象。而微服务(Micro Service)架构则从服务级别展现了设计的灵活之美。

轻盈之美,体现在它的功能并不臃肿,对外部的依赖较少,既容易在系统中快速引入,又不会使原有系统变得笨重,还能很方便地部署或者启动。专注的功能常能体现这种轻盈,例如Gradle专注于构建,Guice专注于依赖注入。

展现了轻盈之美的组件往往具有良好的可测试性。我们可以利用六边形架构将系统分隔为内、外两个边界,凡是系统对外的通信,皆通过端口(Port)和适配器(Adapter)完成,这样就能较好地解除对外部环境的依赖,提高系统的可测试性。而清晰的边界划分也是设计小组件的一种有效手段。

若对于框架或平台而言,则需要尽力降低框架或平台的侵入性。当年Rod Jonson之所以提出J2EE Without EJB,正是因为EJB的侵入性带来了诸多病症。

完整之美,在于它是自足的。完整并不意味着大而全,而在于它足够精简,没有冗余。当然,它同时应该是没有残缺的。残缺,意味着它无法在没有外部支持的情况下,完成自己应该完成的工作。这种美感符合“麻雀虽小,五脏俱全”的标准。Standalone的微服务,正好体现了这种自容器的完整之美。

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2014-10-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏一个会写诗的程序员的博客

服务网格 Pattern: Service Mesh

自从几十年前首次引入以来,我们了解到分布式系统能够实现我们之前甚至无法思考的用例,但它们也会引入各种新问题。

482
来自专栏养码场

这13项技能让你从传统“撕”到互联网,论Java转型之不易(内含福利)

本人从传统外企转型到互联网已有3个年头,近两年来面试了很多来自传统行业的同行们。发现他们都有意走进处于风口的互联网,但是由于传统行业使用的技术栈与互联网的有所不...

653
来自专栏程序人生

大数据杂谈

最近忙于搬家,买车,保险等杂事,讲座听得少,只是听了两个中文的:喜马拉雅的创始人于建军在InnoSpring分享喜马拉雅的心得,以及coursera的董飞(知乎...

3668
来自专栏跟着阿笨一起玩NET

系统架构师-基础到企业应用架构-客户端/服务器

本文转载:http://www.cnblogs.com/hegezhou_hot/archive/2011/11/07/2238983.html#

471
来自专栏美团技术团队

【沙龙干货】主题二:一个用户行为分析产品的设计与实现

分享内容 ---- 今天想跟大家分享一下我们目前推出的一个海量用户行为分析产品---“神策分析”的设计与实现。由于脱离需求和产品谈技术是不合时宜的,所以我首先会...

3428
来自专栏即时通讯技术

微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

对于IM系统来说,如何做到IM聊天消息离线差异拉取(差异拉取是为了节省流量)、消息多端同步、消息顺序保证等,是典型的IM技术难点。

752
来自专栏阿杜的世界

持续学习杂谈:总结与反思一、总结与反思二、微服务技术栈

去年在一篇文章中看到:工作后的学习,可以从两个方面着力——大的理论和底层的基础,对于中间的知识点可以放宽一点。可能是我对此理解得不对,按照这个思路,我调整了自己...

692
来自专栏数据库新发现

Oracle11g的新特性-11g New Features

随着这几天Oracle OpenWorld大会的召开,Oracle11g的新特性越来越多的被展现出来。

754
来自专栏HappenLee的技术杂谈

可靠的、可扩展的、可维护的数据系统 ------《Designing Data-Intensive Applications》读书笔记1

作为一个开发者来说,目前绝大多数应用程序都是数据密集型的,而不是计算密集型的。CPU的计算能力不再成为这些应用程序的限制因素,而更加亟待解决的问题是海量的数据、...

882
来自专栏腾讯大讲堂的专栏

17年,中国互联网技术走出国门【腾讯篇】

要说哪些公司代表了中国互联网技术的前沿,估计大多数人都会脱口而出:BAT(百度、阿里、腾讯)。中国互联网发展20多年,经历了QQ、游戏、微信红包、双11等等亿万...

1806

扫码关注云+社区