1. 當效能出現問題的時候，最好能在應用層處理和解決，儘量不要把它放到資料庫層裡去。
排序和分組就是典型例子。在應用層做效能提升總是比在資料庫層做要來得容易的多。對於這點，不管是伺服器端的 MySQL 資料庫還是移動裝置端的 sqlite 資料庫都是如此。我可以來解釋一下：我們對一些特定的查詢應用以上的方法雖然不能減少客戶端的響應時間，但是可以減緩資料庫伺服器的壓力，避免資料庫成為所有客戶端的瓶頸。
2. 儘可能地避免併發計算。
如果實在沒法避免，那麼記住，功能越強，程式就會越複雜。儘量避免直面執行緒。並且儘可能的在更高層次的抽象層上處理問題。舉個 iOS 系統的例子：GCD、分派和佇列操作絕對是我們可愛的好助手。相信我，人腦是不具備推理暫存的無限情形這一功能的——這是我親身經歷的慘痛教訓給予我的第一手資料。
3. 狀態越少越好，最好保持區域性化。實用至上。
4. 短小又可自由組合的方法是我們的得力助手。
5. 註釋有時候是有害的。
因為隨著時間的流逝，它會變得過時然後誤人子弟，但是如果不註釋同樣是不可取的。不要啥雞毛蒜皮的小事都拿來註釋，好鋼要用在刀刃上，如果有必要，我們甚至需要大段大段地寫下戰略性的長篇註釋以備不時之需。因為，有時候記憶是個超能忽悠人的東西，搞不好你一覺醒來，甚至僅僅只是去喝了一杯咖啡回來，就忘記了。
6. 不要妄自猜測
如果你覺得某個用例場景”應該不會有問題的吧“，那麼可能過不了多久它就會大發淫威，成為釋出產品中讓你遭受慘痛教訓的原因。相信自己的直覺，不要圖省事就放任有疑問的地方不管，得主動測試、積極驗證。
7. 如果有疑問的話，將所有顧忌與團隊交流溝通。
8. 做正確的事——地球人都知道。
9. 使用者不是傻瓜，他們只是沒有耐心去了解你所謂的捷徑。
10. 如果一個開發人員不被分派到維護系統（參與建立的）的團隊中去，不能檢視他們的猜想，那麼他們曾經在這個系統上面付出的心血和汗水將會付之東流、化為烏有，而這時卻發現了一些問題又需要參與進去——不要喊苦喊累，不要怨天尤人，你可知道這可是在成為一個更為睿智的專業程式設計師的節奏？
11. 任務清單會是我們的好搭檔。
12. 積極主動讓我們的工作更有趣，但是這需要努力。
13. 突如其來的系統崩潰，仍然是我的噩夢。做好監控、日誌和警報。清楚各種假警報，避免感覺鈍化。保持系統對故障的敏感度和及時警報。
14.最後，別忘了我們是”拿人錢財，與人消災“的，管理各種複雜的問題，做好相應的工作。
*注：Rich Hickey 的講座和 Robert Martin 的《Clean Code 》一文給了我很多啟發。
翻譯作者：IT 新聞 – 蔣麗麗
英文原文：14 lessons after five years of professional programming
相關閱讀
評論(2)