道与术

所谓道，就是事物的基础和本质，是一种思想和理论，是不易改变的部分。所谓术，就是具体实现的方法和手段，是一种实践的过程，是容易改变的部分。在科学发展的过程中，一般都是先从术开始，开始解决某一个具体的问题，从研究这个具体问题所用的方法，研究这个问题后背的本质，从而推导出一些基础理论和思想，再有这个基础理论，应用到实践，交替的发展。

之所以说这个话题，主要是在回顾这些年自己的技术生涯中存在的问题以及思考如何再进一步提高我们的技术水平。个人觉得学习的过程应该是和科学的发展规律是类似的，先从解决一系列具体的问题入手，在思考这些问题后背的本质是要解决哪些基础问题，在抽象出来这些问题背后的本质，进而思考这一类问题的本质解决思路应用到实践过程中，从一个先具体——>抽象——>泛华的过程。

一个技术人员想要成长，前期是肯定要不断学习应用技术，思考对于特定问题的解决方案，能够有效的解决技术中的难题，当自己的术积累到一定的阶段的时候，想要再有突破，就必须提高自己的道，透过自己在术上的积累，完成道的提升。从道和术的关系来看，术是一中思维的具体化，而道是思维的抽象化，从具体化上升到抽象化，需要主动思考，积极总结，把具体化的事务中不变性和易变性进行区分，找到不变的部分，这些才是本质。在很长一段时间内，我都过分追求所谓的术，喜欢不断的看新的技术，学习新的业务，通过各种项目来锻炼自己的能力，但是缺乏对其背后原理的分析，在短时间内，你会发现感觉你能力提升很快，但如果长期如此，就会遇到瓶颈，因为你积累的永远是术，而非道也。

 

上面说的比较抽象，可以从一个具体的例子来说明如何从一个具体的问题背后提出这个问题的本质是什么，以及有解决这个本质的问题有哪些实际的方案，这个例子也是当初我在工作中遇到，当初由于能力原因，没有设计出来一个很好的扩展性很强的架构方案。

具体场景：某公司提供了一个产品，这个产品主要是解决企业用户通过我们的服务批量付款到指定的银行卡里面，我们约定了一个打款的文件格式，客户通过http post 的方式上传文件到公司指定的URL。而打款文件里面主要是有客户姓名，卡号，金额三列，其他的不是重点，这里不不描述了。

 

从这个应用场景来看，用程序来实现这个功能非常简单，通过一个web服务器端程序，下图描述了这种简单方案的实现方式 

 

问题一：协议版本与关注点分离

接下来，我们就面临问题了，对于大多数企业客户，都比较好说话，都挺配合我们的，但是对于一些国企，比较牛逼的客户，觉得你们的功能不够好啊，我想在文件里面追加一列手机号，希望在打款完成的同时，短信通知用户。这个说实在的比较合理，谁叫别人是大爷了，只有改了。最简单的方案就是在解析文件的时候，增加一列好了，数据也增加一个字段。后来，大家就知道了，还有一些客户也有其他的特殊需求，比如发邮件通知，收费需求等等，我们的方案就是文件不断的加列，数据里面不断的加字段。

现在的问题有两个：1 如何应对约定文件格式经常变化的问题 ， 2 如何解决客户的特殊需求

对于第一个问题，从表象来看，是文件格式定义的不具有扩展性，在现实生活中，我们也会遇到这样的问题，比如我们去银行办理业务需要签约，签约内容随着时间的不同，也会发生变化，而银行每次签约就会把签约的协议版本记录下来，每一份不同的协议都有一个版本。对于这里的打款文件，其实就是一份协议，我们简称数据协议，那么问题就转化为如何面对协议内容发生变化。在计算机世界，协议可能是应用最广泛的词之一了，当然可以从这里找到答案，从我们最熟悉的http协议看来，就是约定协议号。在商户上传文件的时候，说明这个协议的版本号，我们根据版本号的不同，对文件解析处理也就不一样。

从这个问题来看，如果把文本内容进行抽象，就是一种数据协议。任何通信的双方交互数据交互都需要约定数据协议和其版本，这样在协议发生改变的时候，可以更有效的对系统进行扩展。在计算机世界，协议可是太多了，比如ftp，http，smtp等等，每个协议肯定都有其对应的版本号。

 

对于第二个问题，主要是就是在变与不变进行隔离，对于功能点，核心的需求，也就是不变的需求，就是打款，姓名，卡号，金额是必要属性，而邮箱，手机号是增值服务，这个是扩展性属性，在数据持久化的时候，不变的属性和易变的属性要分开保存。在设计模式中，模板模式就是一个比较好的例子，不变逻辑的抽象出来，易变的逻辑让子类实现。

 

问题二：渠道以及通信方式

随着产品的发展，我们的接入的商户越来越多，有一些商户IT系统比较弱，或者说根本都没有，拿怎么办，我们只能在自己的网站开发一个功能，让商户登陆到我们的系统中，自己上传文件。后来，恶梦越来也多，有一些商户觉得http post 不安全，打算用socket方式传入文件流。我们只能不断的修改现有的系统，满足其要求。

在这个问题中，我们面临的就是一个渠道，在刚开始涉及系统的时候，没有考虑到渠道这个属性。其实通过http上传文件，就是我们产品销售的一个渠道。在现实世界中，如果一个厂商要卖产品的话，肯定是通过一定的渠道把产品卖出去，比如通过代理商卖，开网店卖，开直营店，还有骗子最喜欢的电视购物等等。在上面需求里面，缺乏渠道的建设，没有把渠道这一层抽象出来。

对于渠道这个概念，可以再次引申出 渠道类型以及渠道的通信方式，对于上面问题，可以凯利以下几个渠道 系统直连渠道，网站渠道，邮件渠道。

系统直连渠道：具体的通信方式可以包含 http方式，socket方式，ftp方式，webserivce

对于网站渠道：通信方式就是web

对于邮件渠道：通信方式就email

对于不同通信方式，涉及到的数据格式不一样，还需要进行格式转化，对于socket和webservcie方式，需要把接收到的数据格式转化为约定的文本文件格式。这里就需要数据适配层。

在系统应用架构上，需要抽象出渠道层，在渠道层包含各个通信方式的处理逻辑，还需要一个数据适配层，把不同类型的数据转化为标准的文件格式。对架构可以进行一下转化。

 

 

以上两个问题，在我们的系统设计中经常回遇到，其实里面所设计到的问题就是，对于两个通信的双方，以何种渠道和通信方式，通过约定的协议进行通信的过程，这个思想，可以在很多场景下都使用。比如 CPU 和 内存之间的通信，网络客户端和网站服务器的通信等等，其中涉及到抽象概念都是比较类似的。

 

在技术的学习中，我们就是通过这种思考，要不断找寻技术中共通的本质。很多时候，提出问题比解决问题更重要，在看一门新技术的时候，我们要多对其中的原理的进行研究，而不是仅仅学习其应用，能够知道这个技术存在的问题以及其优势。在业务的学习上也是如此，至少我现在不是很喜欢去追求新的业务，也不喜欢把研究业务细节是如何实现的，而是更喜欢思考这些业务之间有哪些关联关系，业务中变化的部分与业务中不变的部分，思考那些有共同点。

 

还是中国古人一句话说的对，学而不思则罔，思而不学则殆。学而不思无道，思而不学无术。只有道术结合，才是能为强者。