最近三個月的主要工作都是在修復(fù)bug，修bug本身就是一個痛苦的過程，特別是修別人的bug，當別人還隨心所欲寫的一坨亂麻的時候，該哭的我們改怎么辦。

簡單總結(jié)了以下幾點：

代碼盡量簡單，規(guī)范

代碼只是我們實現(xiàn)我們想法的一種路徑而已。一條直路被你弄成S形。誰會按照S形走呢。如果都按你的路走,小區(qū)里就不會出現(xiàn)各種無草小路了。

規(guī)范這個怎么說呢。官方的規(guī)范也好，自己定的也好，統(tǒng)一就行。只要不被其他程序員鄙視就行。

盡量邏輯單一

• 當一個2000+行的類。輸出5種不同風格的內(nèi)容。代碼中充滿了 if/else 。如果我們要改其中某一個風格的內(nèi)容。那么我們還得先理清所有的類型。

適當?shù)臏p少通用

• 通用這東西是美好的。但是當一個跨度3年的項目。中間經(jīng)歷了無數(shù)版本的迭代。那么通用中的代碼還能留下多少。又會生成多少新的通用。

及時刪除無用代碼

無用的代碼只會混淆我們的邏輯，對我們的了解一點幫助都沒有。所以每次修改代碼。我們都應(yīng)該只留下最精簡的代碼。

適當?shù)淖⑨?/h5>

注釋這東西要寫就寫正確，錯誤的注釋比無注釋還坑爹。

不為未來編程

我們的代碼中不要存在下個版本將要出現(xiàn)的需求的設(shè)計和代碼。未來都是不可控的。當我們到下個版本開發(fā)的時候。如果你寫的代碼不適用于新的需求。那么前面花費的時間都已浪費。

含淚總結(jié)

說了這么多，其實都繞不開可讀性。對于我們只有讀懂才能往下走。歡迎各位看官指錯和出招