道与术

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

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

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

 

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

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

 

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

 

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

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

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

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

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

 

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

 

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

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

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

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

系统直连渠道：具体的通讯方式能够包含 http方式，socket方式，ftp方式，webserivce

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

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

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

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

 

 

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

 

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

 

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