編寫代碼可以遵循以下幾點(diǎn)原則：

1. 先做核心模塊的壓測(cè)：很多程序員,，習(xí)慣把東西做完,，然后等著快上線的時(shí)候才做性能測(cè)試,，那么如果前面設(shè)計(jì)出了問題,，這個(gè)就很頭大了,。
   當(dāng)然,，后期快上線的時(shí)候也要做性能測(cè)試,，但前期的我認(rèn)為還是很重要的,。
   當(dāng)然,，做好這一點(diǎn),，需要懂一些業(yè)務(wù)，你要知道業(yè)務(wù)壓力在哪里,，業(yè)務(wù)請(qǐng)求的重心在哪里,，很多時(shí)候，產(chǎn)品經(jīng)理不講,，你也要問清楚,。
   

2. 確保過程可控：代碼執(zhí)行時(shí)一定要保持中間的輸出，比如說,，每處理 10 萬條日志,，寫一條狀態(tài)日志，記錄處理的日志條目數(shù)和當(dāng)前的執(zhí)行時(shí)間,。
   

3. 多打日志：很多時(shí)候,，代碼寫的自己也不是很滿意,，比如某個(gè)處理效率不夠優(yōu)化，某個(gè)處理的方法不夠簡(jiǎn)潔,，或者擴(kuò)展性比較差,，代碼寫的很弱智，但可能短時(shí)間沒有辦法想清楚最合理的解決方案,，考慮到上線初期這里并不是重心所在,，所以也不會(huì)特意去優(yōu)化它，但這種情況下我往往會(huì)留釋,，并說明下一步優(yōu)化的可能思路是什么,，或者想到的可行方案是什么。
   

4. 簡(jiǎn)單易懂的邏輯：千萬不要把自己繞進(jìn)去了,，時(shí)間一長(zhǎng),，誰都看不明白你的邏輯。
   如果邏輯真的很難在一個(gè)函數(shù)內(nèi)完成,，嘗試切分,。
   

5. 不要沉迷于框架：框架的問題是什么？是過于繁冗的嵌套,。
   為什么我一直很煩框架,？因?yàn)榻?jīng)常遇到需要一秒鐘幾千次請(qǐng)求的處理場(chǎng)景，那么調(diào)優(yōu)的時(shí)候,，要從數(shù)不清的框架中尋找數(shù)據(jù)處理的邏輯,，尋找性能卡點(diǎn)，可能改動(dòng)代碼只有兩行,，但是找問題需要兩天,。
   程序員記住，你的技術(shù)能力不能被框架約束住,。
   

6. 使用熟悉,、成熟的技術(shù)：很多人根本沒搞明白自己的障礙和問題在哪里，根本不知道相關(guān)技術(shù)產(chǎn)品的優(yōu)勢(shì)和劣勢(shì)在哪里,，看一堆第三方的數(shù)據(jù)測(cè)評(píng),，腦子一熱，去學(xué)新技術(shù),，然后,，掉進(jìn)坑里出不來，如果是創(chuàng)業(yè)公司,，可能項(xiàng)目就死在里面了,。
   使用新技術(shù)前，建議了解該技術(shù)的特征，適用范圍,，以及不適用的范圍,。