中國軟體業真的到了該反思的時候了
中國五千年文化造就了我們諸多的性格,其中之一就是好大喜功,這尤其反映在中國的軟體產業。不錯,我們確實擁有數量巨大的網民,擁有無與倫比的龐大市場與使用者需求,但這並不足以讓我們的步入世界領先行列。在巨大的市場優勢面前常常讓我們有些迷離,有些飄飄然,有些盲目地民族自豪感,喊出諸如“趕英超美”的口號。然而,客觀地講,我們現在卻是差距巨大。
也許你覺得我這話有些崇洋媚外,但靜下心來仔細分析我們自己設計的軟體,我們注重了軟體質量了嗎?我們在如履薄冰地進行每一次設計了嗎?我們的每一個系統都在編寫高質量的程式碼了嗎?也許每個專案的第一個版本我們做到了,但隨著軟體生命週期的延續,與軟體需求的不斷變更,我們真的越來越難以拍著胸口說,我做到了!這就是當今中國軟體之殤:沒有高質量的軟體設計,哪來高質量的軟體系統?
所以,作為中國軟體業中的一員,你應該仔細反思了。下面這篇文章,一個真實的故事,也許可以給你許多的感悟:
2012年,我接到一個任務,對公司一個執行了十年之久的軟體系統開展課題研究,使其能夠由現有的省集中的運營模式,改為全國集中的運營模式。將原有的,每個省一臺伺服器的運營模式,改為將所有業務都集中於一臺伺服器進行運營,毫無疑問,這是一個效能問題,通過加入快取、分散式處理、資料庫分割槽、讀寫分離等技術,從而解決大併發訪問與大資料量處理,問題就解決了。起初,我也是這樣認為的,但我真正深入到這個軟體系統的程式程式碼中時卻發現,問題不是想象中那麼簡單。
雖然之前也有所耳聞,但我真正深入到程式碼中時,還是感到十分的震驚。整個專案中,一個類數百個方法,一個方法數千行程式碼的地方,比比皆是。當你遊走於數百個方法,或者數千行程式碼中時,即使像我這樣工作了十多年的老手,要讀懂也是相當困難,更別說那些剛畢業的新同學。此時,我意識到,如果不改變現有的程式碼結構,這個系統真的無法承載任何的技術改造。
我造訪了參與這個系統多年的老員工,那些“元老”們。他們告訴我,這個系統其實在最開初設計上還是很不錯的。然而,經歷是十年的維護,各種功能需求,加加減減,不斷更新,版本升級上百次,問題就變得越來越大。隨著人員的流動,一些程式碼變成了盲區,誰都不明白它的意思,同時誰都不敢去對它有任何修改,除非迫不得已。每個新員工加入,都不敢輕易修改原有任何程式碼,而是在原有程式碼的基礎上不斷新增程式碼。這樣,隨著功能的不斷變更,新添的程式碼就想腫瘤一樣不斷膨脹,最後由數百行程式碼擴充套件成數千行程式碼,由數十個方法擴充套件成數百個方法,程式碼質量不斷降低。
慢慢地,程式設計師越來越看不懂程式碼了,但他們又要完成自己手頭的工作,因此開發工作變成了一種冒險。那麼公司怎麼能保證每次上線的新程式是正確的呢?那就是測試,投入巨大人力與時間的測試。由於程式越來越複雜,每次修改的測試成本都變得巨大。而這時,由於開發人員覺得,測試人員總數能測出問題來,所以自己只負責開發就可以了,所有的驗證工作統統交給測試人員。毫無疑問,這個專案已經陷入了一陣難於自拔的惡性迴圈之中。維持現狀已然疲於奔命,何談任何技術改造?
然而,我認為這不是一個個案,而是一種普遍現象。大家想想,哪個軟體公司沒有運營數年的遺留系統?哪個系統不是遭遇頻繁變更?在這些系統經歷了數十次變更以後,誰還敢拍著胸脯說,我們的設計依然很清晰,我們的程式碼依然很優質,恐怕不能。
“就這樣吧,好死不如賴活著!”也許大多數人都會這樣想,然而卻不包括我。我從業數十年就一直是一個救火隊員,去拯救那些無法再執行下去的軟體系統。我很少開發新的系統,總是在半途去接手一個老系統。這些系統起初程式碼都十分凌亂,維護十分困難。但是在我接手之日起,事情開始變得好轉。我總是在不斷改造它們,優化它們的程式碼,使它們慢慢變得易於閱讀、容易維護、容易變更。慢慢地,我們的維護工作變得越來越輕鬆,我們開始喝著咖啡,聽著音樂,享受程式設計生活。我採用的方法就叫“重構”。
重構不是高階大氣上檔次的華麗名詞,也不是病入膏肓才拿出來唬人的終極殺招。它不是將原有系統改得面目全非,更不是拿著程式碼一陣瞎改的魯莽之舉。而是一種科學而穩健的持續改善。經過多年的工作實踐,我深深的感到,這種方法是解決中國軟體之殤的最有效方法,因為:
假如你在維護遺留系統,這個遺留系統本身的設計並不好,程式碼質量存在問題,那麼你可以採用這種方法,持續而穩健地改造,最後將軟體的維護納入到一個良性的迴圈中來;
假如你是一個設計者,你在設計一個新系統,但你的設計能力不足夠優秀,不知道怎樣適應今後的變更,那麼沒有關係,思考今天的設計。因為有了重構,我們不用擔心日後的變更。這樣每個人都可以編寫出高質量的程式程式碼;
假如你是一個遺留系統的維護者,你發現原有的程式不能適應新的需求,那麼沒有關係,通過重構先改造原有系統,以適應新的需求,再新增新的需求。這樣做,你會發現你很容易設計出高質量的程式碼,使得新功能的加入不會降低原系統的質量。
當所有軟體企業都做到了這些,那麼中國軟體的質量就開始提高,中國軟體業才真正能夠騰飛。為此,我將我多年的經驗匯聚到《大話重構》這本書中,期望給大家更多的啟迪!大家可以在噹噹、亞馬遜、京東、china-pub等網上書店搜尋,也可以在豆瓣、51CTO、IT168文庫等網上試讀。
噹噹:http://product.dangdang.com/23449367.html
試讀:http://www.ituring.com.cn/book/1375
相關文章
- 老大難的 Java ClassLoader,到了該徹底理解它的時候了Java
- Bitdefender安全專家說:到了該徹底重寫Java的時候了Java
- Fastjson到了說再見的時候了ASTJSON
- 安全專家說:現在到了該徹底重寫Java的時候了Java
- 是時候該學JavaScript了JavaScript
- 向Docker告別的時候到了Docker
- Eclipse,到了說再見的時候了——Android Studio最全解析EclipseAndroid
- 是到了更換專案管理工具的時候了嗎? (轉)專案管理
- 是到了更換專案管理工具的時候了嗎?(轉)專案管理
- 物聯網安全告急是時候該重視了
- 是時候該瞭解一波Protocol Buffers了[Java]ProtocolJava
- 被吐槽遊戲時長太短!?《瓦力歐製造》系列也許到了需要革新的時候了遊戲
- 程式設計師,換身行頭的時候到了!程式設計師
- 是時候該瞭解一波Protocol Buffers了[Android]ProtocolAndroid
- 什麼時候該用vuex?Vue
- 什麼時候該用MongoDB?MongoDB
- 面試的時候應該想的問題面試
- Haskell程式設計精華:什麼時候該註釋,什麼時候不該註釋Haskell程式設計
- 新手::"為中國的軟體業奮鬥"
- 在Driver中呼叫I/O API的時候你考慮到了嗎API
- 執行dbca命令的時候報錯了
- 網站設計的時候應該注意些什麼網站
- 當模型不起作用的時候應該怎麼做?模型
- 是時候學習真正的 spark 技術了Spark
- 中國軟體業,痛在何處? (轉)
- TA們劃重點的時候到了:什麼是例項工作流?
- 你在程式設計的時候,浪費了多少時間?程式設計
- 你在程式設計的時候浪費了多少時間?程式設計
- 什麼時候你不應該使用微服務微服務
- T-SQL什麼時候該使用分號SQL
- 什麼時候應該避免註釋程式碼?
- 是時候扔掉 Postman 了,Apifox 真香!PostmanAPI
- 是時候瞭解React Native了React Native
- 是時候向Chrome說再見了Chrome
- 主動傷害人類的機器人誕生!考驗你人品的時候到了機器人
- 是時候優雅的和NullPointException說再見了NullException
- 從事IT, 中國IT人員最值得驕傲的時候
- 中國軟體業呼喚CMM認證 (轉)