所謂道，就是事物的基礎和本質，是一種思想和理論，是不易改變的部分。所謂術，就是具體實現的方法和手段，是一種實踐的過程，是容易改變的部分。在科學發展的過程中，一般都是先從術開始，開始解決某一個具體的問題，從研究這個具體問題所用的方法，研究這個問題后背的本質，從而推導出一些基礎理論和思想，再有這個基礎理論，應用到實踐，交替的發展。
之所以說這個話題，主要是在回顧這些年自己的技術生涯中存在的問題以及思考如何再進一步提高我們的技術水平。個人覺得學習的過程應該是和科學的發展規律是類似的，先從解決一系列具體的問題入手，在思考這些問題后背的本質是要解決哪些基礎問題，在抽象出來這些問題背后的本質，進而思考這一類問題的本質解決思路應用到實踐過程中，從一個先具體——>抽象——>泛華的過程。
一個技術人員想要成長，前期是肯定要不斷學習應用技術，思考對於特定問題的解決方案，能夠有效的解決技術中的難題，當自己的術積累到一定的階段的時候，想要再有突破，就必須提高自己的道，透過自己在術上的積累，完成道的提升。從道和術的關系來看，術是一中思維的具體化，而道是思維的抽象化，從具體化上升到抽象化，需要主動思考，積極總結，把具體化的事務中不變性和易變性進行區分，找到不變的部分，這些才是本質。在很長一段時間內，我都過分追求所謂的術，喜歡不斷的看新的技術，學習新的業務，通過各種項目來鍛煉自己的能力，但是缺乏對其背后原理的分析，在短時間內，你會發現感覺你能力提升很快，但如果長期如此，就會遇到瓶頸，因為你積累的永遠是術，而非道也。
上面說的比較抽象，可以從一個具體的例子來說明如何從一個具體的問題背后提出這個問題的本質是什么，以及有解決這個本質的問題有哪些實際的方案，這個例子也是當初我在工作中遇到，當初由於能力原因，沒有設計出來一個很好的擴展性很強的架構方案。
具體場景：某公司提供了一個產品，這個產品主要是解決企業用戶通過我們的服務批量付款到指定的銀行卡里面，我們約定了一個打款的文件格式，客戶通過http post 的方式上傳文件到公司指定的URL。而打款文件里面主要是有客戶姓名，卡號，金額三列，其他的不是重點，這里不不描述了。
從這個應用場景來看，用程序來實現這個功能非常簡單，通過一個web服務器端程序，下圖描述了這種簡單方案的實現方式
問題一：協議版本與關注點分離
接下來，我們就面臨問題了，對於大多數企業客戶，都比較好說話，都挺配合我們的，但是對於一些國企，比較牛逼的客戶，覺得你們的功能不夠好啊，我想在文件里面追加一列手機號，希望在打款完成的同時，短信通知用戶。這個說實在的比較合理，誰叫別人是大爺了，只有改了。最簡單的方案就是在解析文件的時候，增加一列好了，數據也增加一個字段。后來，大家就知道了，還有一些客戶也有其他的特殊需求，比如發郵件通知，收費需求等等，我們的方案就是文件不斷的加列，數據里面不斷的加字段。
現在的問題有兩個：1 如何應對約定文件格式經常變化的問題 ， 2 如何解決客戶的特殊需求
對於第一個問題，從表象來看，是文件格式定義的不具有擴展性，在現實生活中，我們也會遇到這樣的問題，比如我們去銀行辦理業務需要簽約，簽約內容隨着時間的不同，也會發生變化，而銀行每次簽約就會把簽約的協議版本記錄下來，每一份不同的協議都有一個版本。對於這里的打款文件，其實就是一份協議，我們簡稱數據協議，那么問題就轉化為如何面對協議內容發生變化。在計算機世界，協議可能是應用最廣泛的詞之一了，當然可以從這里找到答案，從我們最熟悉的http協議看來，就是約定協議號。在商戶上傳文件的時候，說明這個協議的版本號，我們根據版本號的不同，對文件解析處理也就不一樣。
從這個問題來看，如果把文本內容進行抽象，就是一種數據協議。任何通信的雙方交互數據交互都需要約定數據協議和其版本，這樣在協議發生改變的時候，可以更有效的對系統進行擴展。在計算機世界，協議可是太多了，比如ftp，http，smtp等等，每個協議肯定都有其對應的版本號。
對於第二個問題，主要是就是在變與不變進行隔離，對於功能點，核心的需求，也就是不變的需求，就是打款，姓名，卡號，金額是必要屬性，而郵箱，手機號是增值服務，這個是擴展性屬性，在數據持久化的時候，不變的屬性和易變的屬性要分開保存。在設計模式中，模板模式就是一個比較好的例子，不變邏輯的抽象出來，易變的邏輯讓子類實現。
問題二：渠道以及通信方式
隨着產品的發展，我們的接入的商戶越來越多，有一些商戶IT系統比較弱，或者說根本都沒有，拿怎么辦，我們只能在自己的網站開發一個功能，讓商戶登陸到我們的系統中，自己上傳文件。后來，惡夢越來也多，有一些商戶覺得http post 不安全，打算用socket方式傳入文件流。我們只能不斷的修改現有的系統，滿足其要求。
在這個問題中，我們面臨的就是一個渠道，在剛開始涉及系統的時候，沒有考慮到渠道這個屬性。其實通過http上傳文件，就是我們產品銷售的一個渠道。在現實世界中，如果一個廠商要賣產品的話，肯定是通過一定的渠道把產品賣出去，比如通過代理商賣，開網店賣，開直營店，還有騙子最喜歡的電視購物等等。在上面需求里面，缺乏渠道的建設，沒有把渠道這一層抽象出來。
對於渠道這個概念，可以再次引申出 渠道類型以及渠道的通信方式，對於上面問題，可以凱利以下幾個渠道 系統直連渠道，網站渠道，郵件渠道。
系統直連渠道：具體的通信方式可以包含 http方式，socket方式，ftp方式，webserivce
對於網站渠道：通信方式就是web
對於郵件渠道：通信方式就email
對於不同通信方式，涉及到的數據格式不一樣，還需要進行格式轉化，對於socket和webservcie方式，需要把接收到的數據格式轉化為約定的文本文件格式。這里就需要數據適配層。
在系統應用架構上，需要抽象出渠道層，在渠道層包含各個通信方式的處理邏輯，還需要一個數據適配層，把不同類型的數據轉化為標准的文件格式。對架構可以進行一下轉化。
以上兩個問題，在我們的系統設計中經常回遇到，其實里面所設計到的問題就是，對於兩個通信的雙方，以何種渠道和通信方式，通過約定的協議進行通信的過程，這個思想，可以在很多場景下都使用。比如 CPU 和 內存之間的通信，網絡客戶端和網站服務器的通信等等，其中涉及到抽象概念都是比較類似的。
在技術的學習中，我們就是通過這種思考，要不斷找尋技術中共通的本質。很多時候，提出問題比解決問題更重要，在看一門新技術的時候，我們要多對其中的原理的進行研究，而不是僅僅學習其應用，能夠知道這個技術存在的問題以及其優勢。在業務的學習上也是如此，至少我現在不是很喜歡去追求新的業務，也不喜歡把研究業務細節是如何實現的，而是更喜歡思考這些業務之間有哪些關聯關系，業務中變化的部分與業務中不變的部分，思考那些有共同點。
還是中國古人一句話說的對，學而不思則罔，思而不學則殆。學而不思無道，思而不學無術。只有道術結合，才是能為強者。