我是個習慣于凡事有規(guī)矩的人，所以這也影響我的開發(fā)思路和代碼風格。

面對一個新項目，我不會選擇僅僅為了快速而放棄項目結(jié)構(gòu)、性能效率、格式規(guī)范和可重用性的。打個比方吧，未合理分包分層及文檔注釋的項目結(jié)構(gòu)、代碼里出現(xiàn)使用“+”連接多個不同字符串變量、使用magic number而不定義常量或枚舉的等等，這些問題可能別人不以為然，可在我看來是不能接受的。

說者無心，聽者有意。到底這么“細扣”真的是無所謂的嗎？我覺得不盡然，很簡單一個例子，好的編碼習慣可以極大地提高我們犯錯和排錯的機率。在編碼中，良好的軟件結(jié)構(gòu)和完善的日志記錄是有利于我們迅速理解開發(fā)思路，發(fā)現(xiàn)和修補bug，特別是當若干天后添加功能或者代碼重構(gòu)時，好的編碼習慣更是能起到事半功倍的效果，試想一下，如果重構(gòu)時滿篇都是諸如此類：

int magicNo = 3721; // what the fuck 3721 mean? so it's a magic number

我真的很難想象你當時的心情應(yīng)該用多少個感嘆號和問號才能化解，也不知道當你耗盡洪荒之力理解了這一段段“奇思妙想”的代碼后，還有多少余力進行添加功能和重構(gòu)。

適當?shù)暮雎圆糠止δ軐崿F(xiàn)，簡化項目結(jié)構(gòu)會是有效推進項目進度的方式之一，但不規(guī)范使用API、不遵循基本的編碼規(guī)范，這也是提高項目開發(fā)進度嗎？我覺得不盡然，就以剛才的魔數(shù)例子為例，它往往會帶來很多不易察覺的bug以及大量重復性的易出錯的替換操作，這會極大影響開發(fā)者的效率和注意力，降低對項目問題本身的邏輯思考能力，并不會顯著提高開發(fā)進度，相反，還會降低開發(fā)進度。所以，我的觀點是：在規(guī)范用詞和格式的前提下，為了推進項目進度，是應(yīng)該適當?shù)睾喕δ芎徒Y(jié)構(gòu)，但如果僅僅為了提高進度，不遵守編碼規(guī)范，這就是另外的問題了。

在我看來，每次項目開發(fā)的過程其實就是“解題 + 排錯”的過程。解題的思路可以千差萬別，可以有好有壞，有巧有拙，但遇到bug都是需要在最靠近bug發(fā)生的地方找到它，并確認它的來源。否則，等項目基本成型的時候，面對大體量的代碼，找出應(yīng)用中一個個高層的或藏匿的bug只能更加耽誤項目進度，白白耗費精力和時間，也起不到提高自身編碼能力和項目代碼質(zhì)量的作用。

俗話說，“基礎(chǔ)不牢，地動山搖”，就像我們在寫東西的時候，文章的思想很重要，它反映了作者的思想深度和認識水平，但同樣重要的是，文字的用詞規(guī)范和版式要求也是評價作者對待作品的專業(yè)素養(yǎng)和嚴謹態(tài)度的衡量標準?！叭f丈高樓平地起”，只要我們保持對優(yōu)秀代碼的不懈追求和“不斷思考，勇于實踐”的態(tài)度，相信未來總有一座高樓因你而起。

have fun！

END