我的多年編程經驗總結

以下是我的多年編程經驗總結，下列排序無特定順序：

1.當性能出現問題的時候，最好能在應用層處理和解決，盡量不要把它放到數據庫層里去

排序和分組就是典型例子。在應用層做性能提升總是比在數據庫層做要來得容易的多。對于這點，不管是服務器端的MySQL數據庫還是移動設備端的sqlite數據庫都是如此。我可以來解釋一下：我們對一些特定的查詢應用以上的方法雖然不能減少客戶端的響應時間，但是可以減緩數據庫服務器的壓力，避免數據庫成為所有客戶端的瓶頸。

2.盡可能地避免并發計算。

如果實在沒法避免，那么記住，功能越強，程序就會越復雜。盡量避免直面線程。并且盡可能的在更高層次的抽象層上處理問題。舉個iOS系統的例子：GCD、分派和隊列操作絕對是我們可愛的好助手。相信我，人腦是不具備推理暫存的無限情形這一功能的——這是我親身經歷的慘痛教訓給予我的第一手資料。

3.狀態越少越好，最好保持局部化。實用至上。

4.短小又可自由組合的方法是我們的得力助手。

5.注釋有時候是有害的。

因為隨著時間的流逝，它會變得過時然后誤人子弟，但是如果不注釋同樣是不可取的。不要啥雞毛蒜皮的小事都拿來注釋，好鋼要用在刀刃上，如果有必要，我們甚至需要大段大段地寫下戰略性的長篇注釋以備不時之需。因為，有時候記憶是個超能忽悠人的東西，搞不好你一覺醒來，甚至僅僅只是去喝了一杯咖啡回來，就忘記了。

6.不要妄自猜測

如果你覺得某個用例場景”應該不會有問題的吧“，那么可能過不了多久它就會大發淫威，成為發布產品中讓你遭受慘痛教訓的原因。相信自己的直覺，不要圖省事就放任有疑問的地方不管，得主動測試、積極驗證。

7.如果有疑問的話，將所有顧忌與團隊交流溝通。

8.做正確的事——地球人都知道。

9.用戶不是傻瓜，他們只是沒有耐心去了解你所謂的捷徑。

10.如果一個開發人員不被分派到維護系統（參與創建的）的團隊中去，不能查看他們的猜想，那么他們曾經在這個系統上面付出的心血和汗水將會付之東流、化為烏有，而這時卻發現了一些問題又需要參與進去——不要喊苦喊累，不要怨天尤人，你可知道這可是在成為一個更為睿智的專業程序員的節奏？

11.任務清單會是我們的好搭檔。

12.積極主動讓我們的工作更有趣，但是這需要努力。

13.突如其來的系統崩潰，仍然是我的噩夢。做好監控、日志和警報。清楚各種假警報，避免感覺鈍化。保持系統對故障的敏感度和及時警報。

14.最后，別忘了我們是”拿人錢財，與人消災“的，管理各種復雜的問題，做好相應的工作。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈