道與術

所謂道，就是事物的基礎和本質，是一種思想和理論，是不易改變的部分。所謂術，就是具體實現的方法和手段，是一種實踐的過程，是容易改變的部分。在科學發展的過程當中，通常都是先從術開始，開始解決某一個具體的問題，從研究這個具體問題所用的方法，研究這個問題後背的本質，從而推導出一些基礎理論和思想，再有這個基礎理論，應用到實踐，交替的發展。

之因此說這個話題，主要是在回顧這些年本身的技術生涯中存在的問題以及思考如何再進一步提升咱們的技術水平。我的以爲學習的過程應該是和科學的發展規律是相似的，先從解決一系列具體的問題入手，在思考這些問題後背的本質是要解決哪些基礎問題，在抽象出來這些問題背後的本質，進而思考這一類問題的本質解決思路應用到實踐過程當中，從一個先具體——>抽象——>泛華的過程。

一個技術人員想要成長，前期是確定要不斷學習應用技術，思考對於特定問題的解決方案，可以有效的解決技術中的難題，當本身的術積累到必定的階段的時候，想要再有突破，就必須提升本身的道，透過本身在術上的積累，完成道的提高。從道和術的關係來看，術是一中思惟的具體化，而道是思惟的抽象化，從具體化上升到抽象化，須要主動思考，積極總結，把具體化的事務中不變性和易變性進行區分，找到不變的部分，這些纔是本質。在很長一段時間內，我都過度追求所謂的術，喜歡不斷的看新的技術，學習新的業務，經過各類項目來鍛鍊本身的能力，可是缺少對其背後原理的分析，在短期內，你會發現感受你能力提高很快，但若是長期如此，就會遇到瓶頸，由於你積累的永遠是術，而非道也。

 

上面說的比較抽象，能夠從一個具體的例子來講明如何從一個具體的問題背後提出這個問題的本質是什麼，以及有解決這個本質的問題有哪些實際的方案，這個例子也是當初我在工做中遇到，當初因爲能力緣由，沒有設計出來一個很好的擴展性很強的架構方案。

具體場景：某公司提供了一個產品，這個產品主要是解決企業用戶經過咱們的服務批量付款到指定的銀行卡里面，咱們約定了一個打款的文件格式，客戶經過http post 的方式上傳文件到公司指定的URL。而打款文件裏面主要是有客戶姓名，卡號，金額三列，其餘的不是重點，這裏不不描述了。

 

從這個應用場景來看，用程序來實現這個功能很是簡單，經過一個web服務器端程序，下圖描述了這種簡單方案的實現方式 

 

問題一：協議版本與關注點分離

接下來，咱們就面臨問題了，對於大多數企業客戶，都比較好說話，都挺配合咱們的，可是對於一些國企，比較牛逼的客戶，以爲大家的功能不夠好啊，我想在文件裏面追加一列手機號，但願在打款完成的同時，短信通知用戶。這個說實在的比較合理，誰叫別人是大爺了，只有改了。最簡單的方案就是在解析文件的時候，增長一列好了，數據也增長一個字段。後來，你們就知道了，還有一些客戶也有其餘的特殊需求，好比發郵件通知，收費需求等等，咱們的方案就是文件不斷的加列，數據裏面不斷的加字段。

如今的問題有兩個：1 如何應對約定文件格式常常變化的問題 ， 2 如何解決客戶的特殊需求

對於第一個問題，從表象來看，是文件格式定義的不具備擴展性，在現實生活中，咱們也會遇到這樣的問題，好比咱們去銀行辦理業務須要簽約，簽約內容隨着時間的不一樣，也會發生變化，而銀行每次簽約就會把簽約的協議版本記錄下來，每一份不一樣的協議都有一個版本。對於這裏的打款文件，其實就是一份協議，咱們簡稱數據協議，那麼問題就轉化爲如何面對協議內容發生變化。在計算機世界，協議多是應用最普遍的詞之一了，固然能夠從這裏找到答案，從咱們最熟悉的http協議看來，就是約定協議號。在商戶上傳文件的時候，說明這個協議的版本號，咱們根據版本號的不一樣，對文件解析處理也就不同。

從這個問題來看，若是把文本內容進行抽象，就是一種數據協議。任何通訊的雙方交互數據交互都須要約定數據協議和其版本，這樣在協議發生改變的時候，能夠更有效的對系統進行擴展。在計算機世界，協議但是太多了，好比ftp，http，smtp等等，每一個協議確定都有其對應的版本號。

 

對於第二個問題，主要是就是在變與不變進行隔離，對於功能點，核心的需求，也就是不變的需求，就是打款，姓名，卡號，金額是必要屬性，而郵箱，手機號是增值服務，這個是擴展性屬性，在數據持久化的時候，不變的屬性和易變的屬性要分開保存。在設計模式中，模板模式就是一個比較好的例子，不變邏輯的抽象出來，易變的邏輯讓子類實現。

 

問題二：渠道以及通訊方式

隨着產品的發展，咱們的接入的商戶愈來愈多，有一些商戶IT系統比較弱，或者說根本都沒有，拿怎麼辦，咱們只能在本身的網站開發一個功能，讓商戶登錄到咱們的系統中，本身上傳文件。後來，惡夢越來也多，有一些商戶以爲http post 不安全，打算用socket方式傳入文件流。咱們只能不斷的修改現有的系統，知足其要求。

在這個問題中，咱們面臨的就是一個渠道，在剛開始涉及系統的時候，沒有考慮到渠道這個屬性。其實經過http上傳文件，就是咱們產品銷售的一個渠道。在現實世界中，若是一個廠商要賣產品的話，確定是經過必定的渠道把產品賣出去，好比經過代理商賣，開網店賣，開直營店，還有騙子最喜歡的電視購物等等。在上面需求裏面，缺少渠道的建設，沒有把渠道這一層抽象出來。

對於渠道這個概念，能夠再次引伸出 渠道類型以及渠道的通訊方式，對於上面問題，能夠凱利如下幾個渠道 系統直連渠道，網站渠道，郵件渠道。

系統直連渠道：具體的通訊方式能夠包含 http方式，socket方式，ftp方式，webserivce

對於網站渠道：通訊方式就是web

對於郵件渠道：通訊方式就email

對於不一樣通訊方式，涉及到的數據格式不同，還須要進行格式轉化，對於socket和webservcie方式，須要把接收到的數據格式轉化爲約定的文本文件格式。這裏就須要數據適配層。

在系統應用架構上，須要抽象出渠道層，在渠道層包含各個通訊方式的處理邏輯，還須要一個數據適配層，把不一樣類型的數據轉化爲標準的文件格式。對架構能夠進行一下轉化。

 

 

以上兩個問題，在咱們的系統設計中常常回遇到，其實裏面所設計到的問題就是，對於兩個通訊的雙方，以何種渠道和通訊方式，經過約定的協議進行通訊的過程，這個思想，能夠在不少場景下都使用。好比 CPU 和 內存之間的通訊，網絡客戶端和網站服務器的通訊等等，其中涉及到抽象概念都是比較相似的。

 

在技術的學習中，咱們就是經過這種思考，要不斷找尋技術中共通的本質。不少時候，提出問題比解決問題更重要，在看一門新技術的時候，咱們要多對其中的原理的進行研究，而不是僅僅學習其應用，可以知道這個技術存在的問題以及其優點。在業務的學習上也是如此，至少我如今不是很喜歡去追求新的業務，也不喜歡把研究業務細節是如何實現的，而是更喜歡思考這些業務之間有哪些關聯關係，業務中變化的部分與業務中不變的部分，思考那些有共同點。

 

仍是中國古人一句話說的對，學而不思則罔，思而不學則殆。學而不思無道，思而不學無術。只有道術結合，纔是能爲強者。