-
防御式編程，不要相信任何人和服務。你要做好對自身的保護，號稱4個9的AWS不也宕機了嗎！
-
你所擔心的事一定會發生，而且可能馬上會發生。最近上了一些功能，你說好像這個地方可能會有問題，你最好趕緊看，也許馬上就會有問題。
-
線上出現問題要放大處理，尤其是和數據、錢相關的，肯定有不合理的地方，特別准。
-
命名要專業一些，多用一些業務用語，少起一些 map process run等方法，要具體一些，見詞知意。
-
接口定義要明確，做到只要看一下定義就知道寫得是什么，不需要看實現基本就可預知你寫得的是什么。如果還要看實現才能確定做了什么，那么你寫的這個接口就有些失敗。
-
重構很重要，但也要小步前進，如果抽出大段時間重構，十有八九會失敗，還要受到業務部門的挑戰。
-
重構還有一點作用，讓你更加了解系統的來龍去脈。我在想對於新入職的員工，是否可以給他一個小模塊，讓他搞一點重構，通過這樣的方式讓他來了解系統。這有一個前提，leader要對新員工的代碼review、負責。
-
我們工作環境是一個團隊，這就要求我們要適當的幫助他人。但也注意，不要讓別人背上的猴子跳到你背上，把別人的活都攬在自己身上，自己累的夠愴，別人也沒有成長。
-
測試人員信息獲取更多應該來自產品，而不應該是開發人員，那樣的話摻雜開發人員的代碼思維，很有可能是錯誤的理解。這個吃過虧，測試人員讓開發人員給講邏輯，結果上線后發現與產品的初衷是想背離的。
-
最近訂閱了很多技術公眾號，大家寫得都不錯，也有很多干貨。但有一個問題，就是知識不夠系統不連貫，如果想深入的了解一個東西最好還是從紙質書籍下手。另外北京地鐵是可以看書的，至少我上班的時間點還是能拿出書來看的，相對來說比刷朋友圈實惠一些。