這是個隱喻。
在敏捷軟體開發的原則中，其中一個原則就是使用隱喻。我在這裡也仿照了它的做法。
程式設計師是個群體，當我們說一個群體，一定意味著它有一些共通點，不然不能稱之為群體。而每一個群體必然有一個大家都認同的價值觀，否則不能形成群體。
什麼叫大家都認同的價值觀？
舉個例說，信仰基督教的人，它們歸為一個群體，那它們的共同的價值觀是什麼？或者換個說法，是什麼在指引他們行事？
當然是聖經，對吧。
每一個基督教徒都把聖經做為最神聖的事物，遵守聖經的教導是基督教徒的行事標準，對吧。
與此類似，理所當然的，我們程式設計師也會有自己的“聖經”。
那做為一個程式設計師，當你在寫程式碼時，你有沒有思考過，自己的“聖經”是什麼？
從本週起，我將闡述我對編碼之道的理解與思考，這是第一篇：程式設計師的“聖經”
技術只是工具
由於我過去的經歷，我編碼的經驗遍歷後端，移動端以及前端，所以我清楚幾乎每一個方向的程式設計師的日常工作是怎麼樣的。
當然，如果我們就每一個方向來談論它們所涉及到技術，它們肯定是各不相同，甚至是技術上沒有太多交集。
後端的人大多使用的Java，並且與Java生態打交道，他們的詞彙是：併發，叢集，快取，效能等
移動端的人則分為幾類，iOS，Android原生開發，React Native或Flutter等跨平臺開發等，它們用到的技術也各不相同，比如OC，Java或JavaScript等
而前端則主要是與JavaScript或TypeScript打交道，他們更關注的可能是相容性與體驗，樣式等
似乎沒有太交集？
完全不是，在我看來，這些工作其實毫無區別。無論是我在從事哪個技術方向的開發時，我遵守的原則幾乎一致。
想像一下，你怎麼看待技術？
你會發現，在你編碼的職業經歷中，你會遇上各種各樣的技術，新的語言，更好的框架，更函式式的語法，面向大資料的技術等，你可能會認為自己熟悉某些特定的語言，認定自己使用這些語言會更好。
我認為這是一個完全的錯誤。
我把所有的語言，框架或各種各樣的開源的玩意當成工具，它們都是我的工具。把自己想像成一個建築師，我擁有很多工具，這些工具都是我在建造建築時可以考慮使用到的東西。
我從不會限定自己只使用什麼，我這些年也是這樣做的，從一個後端架構師，使用的Java，再去用Java編寫一個Android程式，再去用OC去編寫一個iOS程式，再去用TypeScript去編寫一個跨平臺桌面程式，又去用Kotlin+Vert。x投入到響應式程式設計的世界中，這些語言也好，技術也好，框架也好，都是我的工具而已。
我有一大堆工具，我意識到了，當我要編寫下一個程式，解決下一個問題時，我其實有非常多的工具可以選擇了。
做為一個程式設計師，我從來不對特定的語言表達虔誠，但我想程式設計師也得有自己的虔誠，我想要尋找一個編碼的“聖經”，它足以讓我虔誠的遵守它，守護它，捍衛它。
這便是程式設計師的“聖經”
三個原則
我認為做為一個程式設計師，最神聖的就是三個原則，它幾乎能完整無誤地定義做為一個程式設計師應該如何去編碼。
它也不是空洞的理論，每一個原則都是可以透過技術實實在在地做到。而是否遵守這些原則，也是區分一個程式設計師是否優秀的標準。
這三個原則就是程式設計師的“聖經”，
它們分別是：
編寫滿足需求的程式碼
編寫可維護的程式碼
編寫易於閱讀的程式碼
編碼滿足需求的程式碼
這應該非常易於理解。
我們要編寫的程式碼不是憑空產生的，一定是為了解決某種特定的需求。
當然，需求的來源可以有許多種，比如來自於客戶，來自於產品經理，或來專案經理，也許來自於自己的一些想法。這些都無所謂。
但是，最起碼的原則就是：我們要寫出滿足需求的程式碼
編寫程式碼就是實現契約的過程，提出需求的一方是期望我們理解並實現他們的需求，他們並不明白與理解我們是如何用程式碼實現他們的需求的，但重要的是他們認為與我們定義了一個契約，這個契約就是：
請你們用程式碼來實現我們的需求吧，拜託了
連這一點都做不到的，我認為就不要稱自己是程式設計師了。
編寫可維護的程式碼
寫出能執行的程式碼這個太簡單了，但編寫出可維護的程式碼，則是個巨大的挑戰。
想必很多程式設計師都經歷過類似的痛苦，可能進入了一份程式碼中，這份程式碼在可維護性上已經差到令人髮指了，但還是得要繼續。於是常見的現狀是：修改一個BUG越來越困難，而且會引發更多的BUG，新增一個穩定的新功能越來越不可能。那些不懂程式碼的管理者也不知所措，於是往這個糟糕的專案中新增新的人員，或延長每日工作時間成為了必然的選擇，但絕大多數情況下，情況壓根不會好轉，可能會更糟糕。
很多程式設計師想必理解我在說什麼對吧，我也經歷過類似的專案，記得當時整個團隊花了幾乎幾個月的時間就是去修復BUG，每天有專門人統計每日的BUG修復情況，領導們也為大家打氣。
但最終專案不可逆轉的失敗了。
當然，我們不去談論具體原因，但無論是什麼引發這種情況，做為程式設計師，我們都不能否定一個事實就是：
那些由我們負責編寫的一行行程式碼，當它們合在一起的時候，分工協作與合作卻越來越困難，如同一群相互嫌棄的人硬被我們堆在一起一樣。
這是典型的不可維護的程式碼的表現。
做為一個程式設計師，你有責任讓自己的程式碼具有可維護性，在技術的所有特性中，我認為最重要的一個特性就是：
程式碼一定要具有可維護性
做為一個程式設計師，你要努力寫出可維護的程式碼。
編寫易於閱讀的程式碼
程式碼的可閱讀性我把它分為三個層次：
機器能讀懂的程式碼
自己能讀懂的程式碼
別人能讀懂的程式碼
無論你的程式碼寫的多差勁，只要它接受一個輸入，並能輸出一個符合期望的結果，那你這份程式碼就達到了機器能讀懂的境界了。
再往上一層的要求就是讓自己讀懂。可能很多人會認為自己寫的程式碼怎麼會自己讀不懂？
當然，我說的不是讓你去閱讀自己上週寫的程式碼，而是說讓你去閱讀你過去的，你已經有一段時間沒有參與的程式碼中，我相信一定有一些人可能對於自己過去寫的程式碼可能不是非常理解了，得費勁思考一下才能明白當初自己寫的這份程式碼是幹什麼的。
要求最高的就是讓別人讀懂，在我們程式設計師這個群體中，幾乎有一個共通性，就是不太願意接手別人的程式碼。我想這之中一個很重要的原因就是，別人寫的程式碼我們不太容易讀懂。
這也從反面反應出，寫出一份能讓別人讀懂的程式碼，其實是有著一定的難度的。
想要寫出易於閱讀的程式碼，就得寫出簡潔的程式碼，寫出優雅的程式碼，能做到這種程度的程式設計師實在不多。
它們是“聖經”
理所當然的，能遵守並做到上述三個原則的程式設計師，都可稱之為優秀的程式設計師，反之則不是。
所以，我把這幾個原則稱為“聖經”。
只要稍微思考下，無論你是後端，前端或是移動端還是其它什麼技術方向，這幾個原則幾乎無一例外地能覆蓋到你編碼這件事情上。
這便是我所思考的程式設計師的最高原則。
我將它們時刻牢記在心，虔誠的遵守它們，守護它們。
你做為一個程式設計師，有沒有思考過自己的原則？
有了原則，再談談使命
這就是我這一次要講的原則，做為一個程式設計師，你一定得有你覺得對你而言，你不得不去遵守的原則。
一旦你能為自己確立一個正確的原則，那它將迫使你成為一個越來越優秀的程式設計師，因為只有足夠優秀才能守護你的原則。
我很難想像一個不優秀的程式設計師能做到編寫滿足需求的程式碼，編寫可維護的程式碼以及編寫易於閱讀的程式碼。
你的原則時刻守護著你，有了原則之後，下一步是什麼？
你有沒有思考過這一個問題，做為一個程式設計師，編碼是用來做什麼的，它會產生什麼價值？
下一篇，繼續談編碼之道：編碼之道（二）：軟體的價值
