懶人思惟

引子

其實能夠起一個好名字，好比叫勤儉持家，惋惜勤儉不是個人愛好，持家並不是我所擅長，因此只能用我惟一的優勢來爲這篇冠名了。

8月伊始，咱們啓動了一個只有四我的的開發小組。這個小組主要負責部門將來的 micro service 的探索和研發。其中一個組員是一個碩士實習生。爲了減小學習成本，選擇了nodejs做爲開發語言（你們都比較熟悉 js）。在開發的過程當中，咱們會對任何技術問題進行普遍和深刻的討論。有些問題引發了個人思考。譬如這篇文章即將敘述的，關於設計，流程，優化的一系列問題，我稍微概括了一下，發現不少問題均可以用懶人思惟--能不作就不作來回答。對於這些具備必定的共性，並且能稍微引發一點思考的東西，寫下來是頗有必要的。

能不作就不作

對於工做，敬業的咱們確定不能秉持 能不作就不作 的想法。 可是，編程卻不同。

當咱們開發一個功能的時候，咱們可能會接受用戶的輸入，輸入須要校驗，須要格式化，須要存儲在一個應用程序並不關心的地方。其中的邏輯和流程每每複雜而無序，一般都會須要一個詳盡的文檔來解釋其中的原因。而說明良好的註釋則會更好的幫助閱讀者理解程序的含義。這一般比一個獨立於程序的文檔更加來的有效。

下面就從註釋開始，慢慢的將這些思考展示出來。

註釋

須要很長的註釋嗎？

通常來講，大段的文字容易讓人失去耐心。並且，因爲註釋內容可能距離它想要說明的代碼距離很遠，不方便對照查看，這樣的註釋也就失去了做用。因此最好的辦法實際上是，在一大段代碼的最開始，簡單的說明大概的功能，或者流程。具體的說明，能夠轉移到具體的須要註釋的代碼處。

註釋是代碼的輔助說明

不要試圖給不瞭解相關技術的閱讀者提供相似教程的註釋，除非，你要註釋的代碼確實是示例代碼。
有些程序員喜歡加一些相似技術性說明的註釋，好比

//Close the db connection
connection.close();

誠然，不瞭解數據庫關閉機制的閱讀者會從這個註釋中受益，可是註釋不該該成爲繁瑣的教程。即便閱讀者真的須要這樣的提示，那也應該去對應地技術文檔中獲取須要的知識。

數據校驗

有些時候，咱們須要對即將存入數據庫的數據進行校驗，好比，咱們想要存入一行學生信息（好吧，很俗套）

{
 name:'小明',
 gender:'0',
 grade:'3'
}

其中，gender 和 grade 分別是 gender 表和 grade 表的主鍵，在 student 表中， 這兩個都是外鍵。
好了，問題來了，咱們是否應該在存入信息以前檢驗這兩項的合法性。

個人建議是，不用，即便咱們不檢查，數據庫也會保證錯誤的數據不會被存儲。若是咱們想要返回確切的錯誤信息給用戶（好比，性別不合法，或者年紀不合法），大能夠在保存失敗後再去驗證--不錯不查。

兩種方式的比較

預先檢驗合法性，須要查詢數據庫最多三次，查詢性別是否合法，年級是否合法，所有合法則存入數據。當出現錯誤時，則是查詢了兩次。
不錯不查，則最多檢驗三次，而一般只須要一次存儲就完成了。

並且，實際的應用場景下，不多會發生這樣的錯誤，由於這兩項數據每每是由下拉列表形式提供給用戶選擇的，用戶犯錯的機會基本是不存在的。也就說，出錯實際上是小几率事件。對於小几率事件進行普遍式的防護會消耗沒必要要的系統資源，並且，程序的複雜度也會上升。這樣的程序，可能會使這個樣子

validator.verifyGender(gender);

validator.verifyGrade(grade);

... 其餘的驗證

student.save();

驗證的邏輯和正常的流程（讀取，轉化，存儲）混雜在一塊兒，對於後期維護，升級是一個巨大的挑戰。

而不錯不查呢？

return  student.save();

只須要在正常流程以外或以後，監聽是否有錯誤出現，而後再逐步處理。也就是說，正常流程和錯誤處理徹底分離了。總體的流程變得清晰，易於理解。

錯誤處理

當錯誤出現的時候，咱們通常都會選擇返回詳略得當的信息給用戶。

• 很是詳細
  這樣的信息通常都會包括錯誤碼，信息，甚至錯誤出現的位置和程序調用棧。

• 很是含糊
  通常只會區分錯誤的類型，譬如，客戶輸入錯誤，服務器錯誤，等等。

詳略水平，取決於用戶的類型

若是直接用戶是終端用戶，那麼信息就不能太詳細，由於這樣的信息很容易被用來窺探後臺邏輯，並且，對通常的終端用戶來講，這樣的信息毫無用處。 某些項目經理認爲詳細的信息有助於分析錯誤，可是從終端的返回信息來分析錯誤每每是低效和不許確的，還不如直接去查看日誌文件有效。

不該該包括相似使用指導的信息

有時候，咱們天真的在信息中加入相似下面這樣的指導。

grade should be a number from 1 to 6

這樣的信息不該該出如今錯誤返回中，而是應該出如今使用文檔，或者前端頁面提示中。使用簡單的提示信息，既能很好的隱藏後臺細節，也能下降後臺管理錯誤信息的難度。

試想，若是對於錯誤輸入的返回都是相似

grade is invalid

那麼，徹底可使用錯誤信息生成函數/或者同一個錯誤類來爲每個輸入錯誤生成錯誤返回。這一部分邏輯也就能夠獨立出來了，一樣，管理和升級的成本就變得能夠接受了。

總結

以上都是一些零散可是有用的總結，不少問題到了最後都變成了設計思想上的碰撞。爭論還在繼續。而這片文章也會持續的記錄那些沉澱下來的彌足珍貴的東西。