編碼之道（四）：編碼有術，術中有道
本週，終於進入編碼之道的最核心的理念與價值觀，那就是：
編碼有術，術中有道
如果你想成為一個優秀的程式設計師，我寫的這篇文章是你值得參考與借鑑的。
這是編碼之道的系列文章，這是第四篇，其它文章為：
- 編碼之道（一）：程式設計師的"聖經"
- 編碼之道（二）：軟體的價值
- 編碼之道（三）：編碼的困境，失衡的價值
從道德經說起
我最喜歡的兩本書，一本就是道德經，一本就是論語。
道德經的有一句話是：
道生一，一生二，二生三，三生萬物
這句話想必基本是個中國人就熟知，它的意思大家也基本都瞭解，萬物都是由道衍生而來的。
這句話簡直可以做為這個世界的至聖之真理，幾乎可以在任何一個領域應用而絕不唐突。當然，在我的程式設計行業，這個也是理所當然適應的。
對這句話我的理解是：
我們是與萬物直接關聯的，生活工作中，使用接觸的一切一切都屬於萬物這個範圍。萬物是複雜且種類繁多的，那是不是我們就不知所措了？
不是，因為按照道德經所說，萬物雖然多且複雜，但歸根究底，它是由道衍生而來的，道是純粹的，簡單的，單一的東西。
如果我們學會了道，那萬物自然不在話下。
那程式設計是不是也是這麼一回事？
程式設計的道與術
大家有沒有想過，同樣在我們程式設計過程中，也類似的存在各種技術，種類繁多，且更新頻繁。
對技術人員的一個最大挑戰就是：
新技術，新語言，新框架層出不窮，稍不留意，就可能落後了。
所以很多技術人員隨著年齡的增長，越發覺得自己學不動了，跟不上這種變動與頻率。這也是我們行業只喜歡使用年輕人的原因，年輕人接觸新技術，新語言更快，更沒有負擔。
舉例來說：
我在剛畢業時，後端流行的SSH的框架，那時候會SSH就相當於會程式設計。SSH是Spring,Strtuts以及Hibernate三個技術。
後面等我一段時間沒接觸後端之後，再回來發現它被Spring給統一了，被Spring Boot給佔領了。
但只要稍加分析就會發現，不管是過往的SSH還是Spring Boot，都其實還是MVC模型的實現而已。
類似的經驗太多了，這些年從我在各端的程式設計的經歷來說，這種技術變更頻繁，但背後的理念思想卻仍舊未改變的現象太多了。
我慢慢意識到了，在程式設計這個領域，原來與道德經說的是一樣的，是存在道與術的。
如果我們做為一個程式設計師，只沉浸在具體的術中，那我們永遠跟不上變化，因為術的變化太快了。
但如果我們理解了道，那就能輕鬆的跟上技術的變化。這些年，我不斷的使用新技術去做新的領域的東西，從未感覺到任何艱難之處，也是這個原因。
程式設計的術
好，我們得好好分析下，什麼是程式設計的術？
舉例說來，一個公司準備一個新的專案或產品，在技術第一步要做的肯定是技術選型。
假設選型結論如下：
後端
使用Spring Boot的單體服務形式，資料庫使用Mysql,框架使用Spring data jpa。這應該是一個常見的搭配。
前端
使用React技術，考慮到TypeScript更適合團隊合作，選用TypeScript而非JavaScript做為編碼語言。
移動端
考慮到此專案對效能要求並不太高，為減少成本，使用React Native跨平臺開發技術。
這個應該是每個程式設計師都非常熟悉的一個過程，事實上所謂架構師的工作，可能很大一部分就是在選型，搭配不同的技術而已。
上面這個結論中，出現了各種語言，框架，技術等，它們全都屬於術的範圍。
什麼是術？以下這些全是術：
- 具體的程式語言
- 各種語言的生態，包括類庫以及框架等
- 一些輔助程式設計的工具，如程式碼生成等
而事實上，大多數程式設計師的工作，就是在使用編碼的術而已，不同的無非是在用哪個語言，哪個框架不同而已。而所謂對程式設計師是好是壞的評估，基本也建立在一個程式設計師是否對特定語言或特定框架熟知或使用年限。
而大多數所謂的面試，也就是通過不斷的詢問特定語言或技術框架的一些知識點來考察程式設計師，這實在是一個極大的錯誤。
程式設計的道
一個簡單的問題是：
一個程式設計師，是不是使用Spring Boot最久，對其各種特性掌握與使用的越多，他就能越寫好程式碼？
當然不是，我們都知道不是，對吧。
我們有時候會發現一個程式設計師有潛力，但他接觸的語言或技術並不多，但我們能判斷他是個優秀的程式設計師，並且能很快的掌握新的技術或語言。
那這背後，究竟是什麼原因？
原因就是:
理解與掌握編碼的道遠重要於編碼的術
術這種東西，其實可能並未有我們想像的那麼重要，一個程式設計師，如果能用React寫出高質量的程式碼，理所當然的他一定能用Vue也寫出高質量的程式碼，就算他從未使用過Vue。而與之相對應的是，一個程式設計師如果用Vue寫不好程式碼，不管他多熟悉React，他也一定用React寫不出好的程式碼。
就如同我上面所說的，不管是SSH，還是Spring Boot，都其實可能是對MVC思想的一種實現而已，那顯而易見的，MVC思想這種看不見，摸不著，也不是具體的語言或框架的東西，是不是更重要？
那與之類似的東西，我把它們稱為道。
以下這些，都屬於編碼之道：
- 編碼的思想，如MVC思想，分層思想，領域驅動思想等
- 編碼的方法論，如敏捷軟體開發的方法論
- 面向物件的三大特性與五大基本原則
- 一些常見的架構風格與架構模式：如分層，六邊型，CORS，事件源驅動等
- 設計模式
- 程式碼簡潔之道
- 重構
- 測試驅動（TDD）等
上面這些東西，沒有任何一個是具體的語言或具體的技術。
但是，只要你稍微細想下，基本上沒有一種具體的術不是來源於道。
比如，我以面向物件的語言為說明
面向物件的語言有三大基本特性與五大基本原則，我懷疑很多程式設計師不一定知道。
三大特性
- 封裝
- 繼承
- 多型
五大原則
- 單一職責原則
- 開閉原則
- 里氏替換原則
- 介面隔離原則
- 依賴倒轉原則
基本上，我們行業，應用級來說，全被面向物件的程式語言佔領，後端的Java，移動端的Swift，OC或Kotlin，前端的TypeScript，全是面向物件的語言。
我這些年，上面這些語言全用過，它們無一例外的符合面向物件的三大特性與五大原則。
所以，當我能用Java編寫程式碼，並儘量以五大原則為標準來編碼程式碼時，同樣的，我在用TypeScript，我也會遵守這些。而這些是決定了程式碼好壞的關鍵。
至於是這些程式碼到底是用Java來寫的，還是用TypeScript來寫的，又有何差別，不同面嚮物件語言的差別無非就是在，定義一個函式，是fun還是function等語法規則上的不同。
變化的術，及永恆的道
我希望我寫的這些能對你有幫助或借鑑，讓你開始思考如何才能成為一個優秀的程式設計師。
掌握具體的語言或框架當然是很重要的，但它絕不是決定性的，決定你能否成為一個優秀的程式設計師的關鍵仍然在於：你對編碼的道有沒有概念，理解與掌握。
下一篇，繼續講編碼之道：編碼之道（五）：變化的術，及永恆的道。再進一步闡述對編碼之道與編碼之術的理解與思考。
關注【微言碼道】公眾號或訪問【微言碼道】官網https://taoofcode.cc: 用我們微小的力量傳播編碼之道
訪問【myddd-全棧式領域驅動】官網:https://myddd.org