五年專業編程的14個經驗
來源：互聯網
上載者：User
這裡並沒有特定的順序:1. 當遇到效能問題時,如果可以在應用程式層上評估或處理,那麼就把它從資料庫層中拿出來."按XX排序"和"按XX組合"就是典型的例子. 應用程式層總是比資料庫層容易測量.這對伺服器上的MySQL和手持功能上的SQLite都是一樣的.HackerNews上有一些很好的評論,所以這裡我澄清一下:我們僅為了某些特定的查詢做這些,不是為了提升某個客戶的反應速度,而是為了減輕複荷, 如果這個查詢嚴重破壞資料庫並且對所有使用者都是有重大意義的瓶頸.
2. 儘可能避免並發. 如果實在不行,要記住能力越強責任越大.盡量避免直接使用線程. 如果有可能的話要使用更高一層級的抽象. 例如在iOS中,GCD, dispatch和operation queue就是很好的幫手.人類的大腦不能用來思考無盡的臨時狀態,一想到我親手學習到這條經驗的經曆時就感覺到噁心.
3. 儘可能少用狀態,並且要保持它們在局部.實用主義者是映射到某種東西之上的.
4. 短小,可組合的方法是你的朋友.
5. 注釋是危險的因為它們很容易過時和誤導,但是沒有注釋也是同樣危險的.不要對瑣碎的進行注釋,但是如果在某個特定的部分需要,就要有策略性的寫上幾段.一到明天早上你的記憶就會讓你失望的,儘管已經喝了咖啡.
6. 如果你感覺一個用例會"可能Okay", 那個就是那種會在產品裡面一個月就引起一次災難性的失敗.相信你過分懷疑的勇氣,測試然後驗證.
7. 當有疑問時,與你的團隊溝通掉所有的顧慮.
8. 做正確的事,你通常都知道是什麼事.
9. 你的使用者並不傻,他們只是對你的"簡便方法"沒有耐心而已.
10. 如果一個工程師沒有被指派過他們建立的長期系統的維護工作, 對他們要持懷疑態度. 軟體當中的80%的血汗和淚都是出現在軟體發布之後, 那就是當你變成一個疲憊不堪的但是更聰明的"專業人員"的時候.
11. 清單是你的朋友.
12. 主動的有明確目的地享受你的工作, 有時這需要一些努力.
13. 對於無聲的失敗,我仍還會做惡夢. 監視器, 日誌, 警告. 但是對於假成功和它帶來的難免的脫敏要保持謹慎. 保持你系統的識別力是清晰的和警覺的.
14. 在一天結束時,付錢給我們是要去解決複雜問題.所以要按事情的重要程度去工作.
原文: 14 lessons after five years of professional programming
