關於合格工程師素養的一些思考
一個引子
碼農和程式員有什麼區別？
我認為，碼農可以做一些簡單的編碼工作：實現某個指令碼，拼裝某條 hql，“寫完”某個函式。往往有一定語言知識，有一定的編碼經驗；但是很少對需求細緻分析，缺乏“恰當”意識。他可能會用一條 sql 完成整個功能，也可能用一個 for 迴圈遍歷所有介面，甚至為了某個不重要的 update 加鎖、加事務…… “為了目的，不擇手段”，而且並不確切目的是什麼。
而程式設計師，他知道自己要做什麼。可以把一個函式寫的效能優良，可以把一個模組設計的很“恰當”。他熟悉 MVC, 熟悉設計模式，可以讓他的模組整潔、完美。甚至，可以創造性的解決一些產品問題，讓程式碼充滿靈性。但是，往往全域性觀不足。
那麼全域性意識指的是什麼呢，我們應該怎樣培養我們的全域性意識？
肯定不是 pm 讓我做什麼，我只要寫程式碼把它實現就好了。而是要首先明確為什麼要做這個，做這些的價值是什麼。
我們有義務幫助產品找到最恰當的解決方案，然後用合理的方式把方案嵌入到程式碼中。同時，要讓保證架構活力，要可以快速定位 bug、解決 bug。清楚上線流程，要保證上線後不會產生任何的消極影響。
一個合格的工程師，可以讓產品需求平穩地落地。那麼我們應該怎樣做到呢？我認為可以從以下幾點出發。
1. 明確需求細節，少做無用功、廉價功
我們應該首先應該明確產品需求是什麼，但更重要的是為什麼。產品為什麼要這麼做？預期的目標是什麼？哪些資料表明這些目標達成了？如何去收集這些指標？
然後，去判斷需要哪些人配合，高優先順序去協調資源。如果判斷人力成本過高，或者收益有限，可以說服產品延後部分需求的實現。集中精力做最重要的事情，少做無用功。同時，積累工作經驗、資料經驗，鍛鍊自己對“價效比”的敏感性，讓自己的判斷變得客觀、有效、權威。
2. 程式碼的執行視覺化
在開始設計功能前，應該先考慮怎麼去做監控。不能讓功能迷迷糊糊地在線上跑著，“它應該是對的吧”……越實時的反饋，越可以早得發現問題，越可以早得為專案止損。同時也是對工作的負責，更是對自己汗水的負責：誰也不想自己辛勤寫出來的程式碼，直到下線那天才發現一直沒有執行“對過”。
- 哪些指標，證明功能是 ok 的
- 哪些報警，證明這是個 bug，那裡肯定掛了
- 哪些指標，證明這個需求是有價值的 （比如：某個功能資料過低，此功能的後續迭代就應該適當降低優先順序）
3. 出現反饋如何應對，出現 bug 如何修復
產品的 feature 不可能讓所有人都喜歡，甚至有時為了產品調性會做些對使用者打壓的事情。這樣的功能如何讓使用者接受？如果不接受，產品應該如何去引導；技術應該如何輔助產品定位問題。
舉個例子，首頁 feed 會過濾掉使用者遮蔽的條目。如果使用者遮蔽了話題 A, 綁定了 A 話題的條目不會分發給使用者。這是一個很合理的產品 feature, 但是使用者會經常誤以為對 XX 內容限流。運營就會要求我們查 bug。像這種需求，我們要做的不只是開發功能，更應該考慮後期如何應對反饋，提高響應效率。
某個關鍵功能出了 bug。我們應該如何跟使用者解釋？應該如何修復資料？修復如何快速？那麼我們可能要考慮，我們要不要準備修復指令碼，我們是不是需要操作冪等，資料操作該不該記錄審計 log……
4. 確保程式碼沒有腐化架構
依照上面兩步，我們意識到了要對業務指標視覺化實時監控，要考慮問題的應急方案。然後，就可以著手設計我們的功能框架。所謂的實現需求，不是寫個 function 把邏輯寫完就行，更不是一個 sql 把資料丟給使用者。所謂的架構，就是為了完成一套完整的功能，合理組合的多個模組。要讓你的程式碼更好的被人看懂，要在恰當的地方完成業務監控，要用恰當的邏輯為應急提供方便。
如果發現現有的架構不能恰當的融入你的需求，千萬別打個補丁硬推上去。“邏輯”誰都能寫完，但是要讓別人覺得，這塊程式碼本來就應該在這裡。衡量程式碼質量的唯一有效標準：WTF/min —— 出自《Clean Code》。
我們應該努力拽著自己的專案，讓它離“屎”遠一點；而不是增加一坨。寫程式碼時，應該考慮的是怎麼用，別人怎麼讀，而不是我怎麼寫！只對作者友好的程式碼絕對是垃圾。面向工程，面向合作。要讓用的人舒服，讓用的人心理成本低。
5. 邀請大家進行 CodeReview
本著一個工程師的素養，我們應該努力拽著自己的專案，讓它保證架構的清潔；但是，這只是一廂情願的。在程式碼真正推上線前，我們需要讓更多的人 code review，以求達成共識。
我的經驗是，如果涉及架構調整，我會先提交一個初版，讓一些有經驗的工程師幫忙評審架構設計。這個階段我們千萬不要追求程式碼完成度、單測覆蓋率。因為很可能架構設計不合理，可能會引起大量的返工，部分工作可能會直接作廢。所以，我認為一個合理的 CodeReview 可以分為四步：
- 按需求調整程式碼架構，儘早提交框架 diff。評審者主要關注：改動是否汙染了架構，調整後的架構是否易於新人學習，新增模組是否容易 debug （比如，方便構造 bug 現場）
- 填充架構細節，“優雅”地實現各模組邏輯。評審者主要關注：功能拆分是否清晰，類是否抽象合理、是否符合語法習慣 (如 python, 是否可以適當使用列表表示式、lambda)
- 確認各模組邏輯無異常、無 bad case。評審者主要關注：功能是否完全覆蓋單元測試、是否已經完成了聯調、是否進行了完善的功能測試
- 確保程式碼細節。評審者主要關注：是否合理的捕捉了第三方工具的異常，是否有合理的功能降級、模組降級，迴圈是否合理 (嚴防死迴圈)，變數命名是否表義、變數作用域是否過大……
所以，我認為 code review 不是一次性的。如果你突然收到了一個 100+ 檔案變動的 merge request，那作者肯定只是想讓你給他 approve：停留在形式上的 code review，至多隻是因為作者想找個人“共同背鍋”。合理的 code review 應該把握大框，逐步細化，漸入佳境。
其實，一步步按著上面的思路來，每一步都有特定的焦點，並不會花費大家太多時間。
6. 確認好依賴，讓改動平滑上線
相信經過上面嚴格的 review, 我們可以拿到一份大傢俱有共識的優良程式碼。但是，程式碼優良不代表可以部署上線。除非你在寫print "hello world"
, 否則，你的功能與各種上下游服務勢必會有千絲萬縷的聯絡。我們必須在上線前，確認好所有的依賴不會阻塞我們。
首先我們要檢查自身是否有先驗邏輯未就緒。比如：知乎首頁需要新增加一種卡片樣式。要先確保版本相容邏輯已上線，否則舊的客戶端收到不識別的卡片可能會 crash。再確保資料庫資料初始化，資料庫裡沒東西上線沒有意義。
其次要檢查下游邏輯是否已經就緒。下游服務功能是否正常上線，是否能承擔我們的請求壓力；資料表 schema 是否變動、是否已上線，資料庫容量是否足夠，資料庫是否能承受壓力；相應快取是否應該預熱……
然後，需要通知我們的上游服務。我們的改動是否不相容，是否會引發上游調用出錯；我們的改動是否影響了效能，是否需要上游調整 timeout……
7. 最小化驗證儘量止損
前期做足了準備，大家足夠警惕地關注著自己的指標變動。然後，我們就可以上線了。
但是，正因為各種指標可能會出現難以預期的變化，我們需要逐步擴大功能的影響範圍。比如，先用辦公室環境，然後放量給 10%、20% …… 的使用者，同時觀察指標變化。
當然我們應該“事先”明確應該觀察哪些指標。比如，介面的 QPS、P95、5xx；依賴我的服務是否正常，我依賴的服務指標是否異常；儲存服務、業務指標是否正常… 發現異常及時回滾。
小結就是：
- 在上線前，先想好自己應該關注哪些指標
- 上線過程，注視指標，逐步放量
- 遇到任何異常、疑似異常，及時回滾
尾聲
程式碼編寫其實沒有難度。哪怕是個小白，在培訓班學呆半個月，就可以實現個小功能：列印個 hello world， 轉置個數組，甚至實現個快排……面試寶典、leetcode 可以幫你順利的通過面試。
但面試通過只是說明面試官覺得我們不錯，不是證明我們可以勝任之後的工作。常言道，“面試造火箭、工作擰螺絲”，面試題目與工作實戰還是有相當大的差別的。不過，只要用心體味，你會發現，實際上工作要比面試的“火箭”複雜度更高。工作造的“火箭”與面試的“火箭”不在一個維度，工作的“火箭”是在幫我們從碼農演變成工程師。
而工程師素養，才是衡量我們能不能在這個行業走深走遠的關鍵。