入行也幾年了，回首這幾年的經(jīng)歷。發(fā)現(xiàn)沒有一個項目能夠讓人滿意，不是Bug滿天飛就是延期。到底為什么呢？客戶太刁蠻？管理問題？技術(shù)問題？還是？ 拋開其他因素，聊聊我們開發(fā)人員的問題。
先從目前的項目談起，現(xiàn)在我在項目是在以往代碼上開發(fā)新的應(yīng)用，好多代碼是01年左右寫的，日后不斷的添加新功能，目前源代碼有200M左右。看看代碼，上千行的方法不計其數(shù)，也佩服印度阿三把代碼寫成這樣還能保證業(yè)務(wù)正確，尤其還是銀行相關(guān)的。雖然方法很長，不過Log 確實很詳細，基本可以通過Log 定位那里有問題。而對于目前開發(fā)，難道還有繼續(xù)寫成千上萬行的方法嗎？
目前JEEWeb應(yīng)用，不論是規(guī)范的EJB+JSF 還是開源的Hiberante Spring struts,都是分層的架構(gòu)，應(yīng)該從架構(gòu)上沒有問題，看了看公司另外項目的代碼，雖然已經(jīng)上09年了，也應(yīng)用了JSF Spring hiberante 等很完善架構(gòu)，為什么還是不能讓客戶，發(fā)人員滿意呢？追根究底，軟件其實就是一行一行代碼實現(xiàn)的，所以本質(zhì)還是代碼出問題了！！
現(xiàn)在有前人總結(jié)的設(shè)計模式，OO設(shè)計思想，以及優(yōu)秀的UML工具，很好的領(lǐng)悟這些東西，應(yīng)該可以保證我們的設(shè)計沒有問題，而Spring Hiberante 等優(yōu)秀的工具，在軟件架構(gòu)上也應(yīng)該沒有問題。所以問題還是我們的Code。打開我們的Code，誰能拍著胸口說我們的代碼沒有任何沒有拷貝張貼？誰能保證說我們的代碼具有很好的可維護性呢？往往會有很多理由，比如工期太緊，沒時間重構(gòu)或者都是遺留代碼沒有辦法重構(gòu)。而最好的結(jié)局呢，代碼越來越難維護，Bug多的QA都失去了信心，而我們開發(fā)人員越來越?jīng)]有底氣了，項目也一度延期或被取消。
設(shè)計能力解決問題能力以及職業(yè)素養(yǎng)是我們開發(fā)人員的核心競爭力，而這些能力就是在不斷優(yōu)化我們的領(lǐng)域模型，以及不斷編寫優(yōu)秀的代碼中慢慢提高的，不是看幾本設(shè)計方面架構(gòu)的方面的書就Ok的。正如Clear Code作者說比喻的，軟件開發(fā)人員就是匠人，你寫的每行代碼就是你的產(chǎn)出，你的作品。
其實我們大多數(shù)人其實都知道這些道理，但其實都習慣了，不想改進而已。這就是問題所在！！ 沒辦法，那就從流程上控制，敏捷開發(fā)想從流程上來避免這些問題，首先測試優(yōu)先，使我們不得不前期設(shè)計可以測試的領(lǐng)域模型，結(jié)對編程讓另外一個人檢查你的代碼，讓你不能隨意聊天看網(wǎng)頁，提高效率，培養(yǎng)職業(yè)修養(yǎng)。而實際應(yīng)用呢，好多公司老板感覺兩個人用一個電腦不是效率很低， 一個人不是閑人嗎？所以結(jié)對被取消了，工期一緊，測試取消了。所謂敏捷開發(fā)基本是掛牛頭賣狗肉。
所以，還是從我們自身來解決問題，首先多看看前人的經(jīng)驗總結(jié)，比如ＯＯ設(shè)計思想，在設(shè)計中，通過各種方式在設(shè)計上減低代碼耦合度。在編寫代碼上，遵循成熟的代碼規(guī)范以及不斷的重構(gòu)代碼，減少代碼中臭味。
總之，既然從事了這個行業(yè)，就要熱愛這個行業(yè)，牢記在心的就是：我們的每一行代碼就是我們的產(chǎn)品！保證我們每一行代碼都是高質(zhì)量的，優(yōu)秀的！