我的多年編程經(jīng)驗總結(jié)

以下是我的多年編程經(jīng)驗總結(jié)，下列排序無特定順序：

1.當(dāng)性能出現(xiàn)問題的時候，最好能在應(yīng)用層處理和解決，盡量不要把它放到數(shù)據(jù)庫層里去

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

2.盡可能地避免并發(fā)計算。

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

3.狀態(tài)越少越好，最好保持局部化。實用至上。

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

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

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

6.不要妄自猜測

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

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

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

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

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

11.任務(wù)清單會是我們的好搭檔。

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

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

14.最后，別忘了我們是”拿人錢財，與人消災(zāi)“的，管理各種復(fù)雜的問題，做好相應(yīng)的工作。

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈