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

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

確保過(guò)程可控：代碼執行時(shí)一定要保持中間的輸出，比如說(shuō)，每處理 10 萬(wàn)條日志，寫(xiě)一條狀態(tài)日志，記錄處理的日志條目數和當前的執行時(shí)間。

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

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

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

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