軟件項(xiàng)目隨著不斷地演化，會(huì)變得越來越復(fù)雜，而這種復(fù)雜性，如果不加以合理的管理，很可能會(huì)走上失敗的道路。這其中有可能出現(xiàn)問題就是源代碼，在本文，我們就來看看軟件是如何越來越變得復(fù)雜的，我們?nèi)绾问褂么a指標(biāo)來提高代碼的質(zhì)量，以避免軟件在復(fù)雜性變革過程中走向失敗。
軟件演化過程
自從 1967 年人類研究出軟件之后，其在社會(huì)上的地位就一直很重要，接下來的日子里就是如何創(chuàng)造出模型和實(shí)踐來開發(fā)出更高質(zhì)量的軟件。還有一部分人就是在不停的追蹤研究軟件的進(jìn)化過程，探究這一演化過程到底帶來了什么樣的后果。
軟件演化過程中誕生的法規(guī)
在上世紀(jì)七十年代，Manny Lehman 提出了一套 8 個(gè)法案以詳細(xì)解釋軟件演化的方式，下面就是應(yīng)該和現(xiàn)如今還有關(guān)聯(lián)的 4 個(gè)法案。
1. 持續(xù)改變
一個(gè)軟件隨著用戶的使用量的不斷變化，軟件會(huì)越來越?jīng)]用，除非這款軟件不斷適應(yīng)參加新域的需求，例如：新的法案?jìng)€(gè)規(guī)章制度對(duì)這一軟件的推動(dòng)。
2. 復(fù)雜度不斷增加
軟件常常會(huì)隨著時(shí)代的發(fā)展變得很復(fù)雜，復(fù)雜程度且越來越高，除非有相關(guān)的管理機(jī)制出現(xiàn)來管理。
3. 功能不斷增長(zhǎng)
一款軟件的功能數(shù)量也會(huì)跟著時(shí)間的流逝而增加，因?yàn)橛脩舻男枨笤谧兇蟆?/p>
4. 質(zhì)量也有可能在下降
軟件的質(zhì)量感毫無疑問會(huì)不斷下降，阻止這一趨勢(shì)的辦法就是通過人為方法來改善。
軟件系統(tǒng)的老化
一旦開發(fā)者對(duì)軟件的復(fù)雜度管理失去控制的時(shí)候，就會(huì)出現(xiàn)一個(gè)我們稱之為“軟件老化Software Aging”的現(xiàn)象，簡(jiǎn)單說來就是隨著時(shí)間的流動(dòng)，其復(fù)雜性不斷上升，質(zhì)量不斷下降。這些特征會(huì)導(dǎo)致一些比較危險(xiǎn)的后果，首先就是軟件變得無法理解，更沒辦法修改，會(huì)影響團(tuán)隊(duì)生產(chǎn)力。正是由于這樣，這款軟件也就不可靠了，開發(fā)者根本沒法理解、修改、消除bugs。
從長(zhǎng)遠(yuǎn)角度來說，軟件老化的結(jié)果就是將這個(gè)軟件扔掉，然后取代的是一個(gè)新的。這很容易理解，與其花很多錢去維護(hù)一個(gè)老舊的軟件，還不如買一個(gè)新的、便宜的呢！
如何阻止軟件老化？
這里有一些實(shí)踐可以幫助我們管理軟件復(fù)雜性，以此來阻止軟件老化的進(jìn)程。
文檔可用于記錄軟件架構(gòu)、用戶需求，還可以用來解釋代碼決策。在我看來，給軟件架構(gòu)和用戶需求編寫文檔是重要的，但我不同意用文檔來解釋代碼。
極限編程（Xtreme programming）所建議的兩個(gè)實(shí)踐我認(rèn)為是比較有用的，尤其是在開發(fā)可維護(hù)的軟件。結(jié)對(duì)編程（Pair programming）和集體所有（Collective Ownership）能夠幫助我們?cè)趫F(tuán)隊(duì)里分享好的知識(shí)，這樣寫出的代碼肯定質(zhì)量是比較高的，因?yàn)槿藗兺ǔＪ歉鶕?jù)不同的觀點(diǎn)來編寫和分析同一個(gè)代碼庫。
其他的實(shí)踐我想說的就是代碼審核，在這篇文章里它也是重中之重。
代碼審核
代碼審核就是一種不斷分析代碼的行為，旨在保證代碼標(biāo)準(zhǔn)，符合用戶需求。其方式無非就是手動(dòng)的、自動(dòng)的。
手動(dòng)代碼審核
手動(dòng)代碼審核通常是由開發(fā)人員分析代碼，而這些代碼通常是由整個(gè)團(tuán)隊(duì)完成的，這個(gè)評(píng)審過程非常類似于評(píng)審會(huì)議（sprint reviews）。手動(dòng)評(píng)審的好處就是能夠在團(tuán)隊(duì)里分享技術(shù)，增加大家對(duì)項(xiàng)目的了解程度。相對(duì)的就是比較浪費(fèi)時(shí)間，在分析代碼的時(shí)候根本沒時(shí)間去寫代碼。
自動(dòng)代碼審核
雖然可以自動(dòng)執(zhí)行代碼審核，但是我覺得即使是那樣，也不該忽略手動(dòng)代碼審核的地位，事實(shí)上我覺得兩個(gè)方法是互補(bǔ)的。自動(dòng)代碼審核是一個(gè)過濾器可以抓住初的小錯(cuò)誤，節(jié)省很多時(shí)間。使用自動(dòng)審核就是可以建立一些指導(dǎo)方針，電腦是可以創(chuàng)建一些簡(jiǎn)單的指標(biāo)，這些指標(biāo)在代碼衡量里有顯示。
代碼衡量
代碼衡量（Code Metrics）被用來代表不同的軟件指標(biāo)，例如：尺寸大小、復(fù)雜性、耦合和內(nèi)聚。個(gè)被使用的代碼衡量就是六十年代的 Lines Of Code (LOC)，用來測(cè)量生產(chǎn)力和工作效率。但是使用 LOC 測(cè)量不同語言編寫的軟件的復(fù)雜性是不公平的，就像把 Ruby 和 Objective-C 放在一起做比較是不可取的。
隨后，就出現(xiàn)了很多有名的代碼衡量方式，為常見的就是1994年提出的CK metrics，還有1995年提出的MOOD metrics。
用來計(jì)算代碼衡量的工具
有很多工具可以自動(dòng)計(jì)算這些衡量，有的是免費(fèi)的，有的是收費(fèi)的，有的支持好幾種語言，而有的只支持一種語言。
Sonar
Sonar 應(yīng)該是企業(yè)用的多的提取衡量數(shù)據(jù)的工具，它可以分析超過20種編程語言，并提供合理化的圖標(biāo)幫助理解。Sonar 還可以用在開源項(xiàng)目里，如果想把它用在個(gè)人項(xiàng)目里的話，可以安裝一個(gè)本地版本或者是用一個(gè)像 CloudBees 一樣的服務(wù)。
NDepend
NDepend 是一個(gè)用來分析.NET 代碼的商業(yè)工具?？梢苑治龀^ 82 個(gè)衡量，并且通過不同的圖形方式將其視圖化。
CodeAnalytics
在我的碩士畢業(yè)展示里面，我就是用 CodeAnalytics 從 C# 代碼里提取衡量。
寫在后的總結(jié)
文章里已經(jīng)展示軟件的進(jìn)化過程，它的危險(xiǎn)性，以及如何組織項(xiàng)目老化。通過代碼審核可以大限度的降低軟件復(fù)雜性所帶來的麻煩。通過代碼衡量指標(biāo)來計(jì)算并優(yōu)化代碼質(zhì)量。
盡管代碼衡量已經(jīng)研究了數(shù)十年，但是我想很多開發(fā)者和公司都知道其為何物，并知道如何使用它們來改善代碼質(zhì)量，使之更加的可維護(hù)，提供更可靠的軟件。
本站文章版權(quán)歸原作者及原出處所有 。內(nèi)容為作者個(gè)人觀點(diǎn)， 并不代表本站贊同其觀點(diǎn)和對(duì)其真實(shí)性負(fù)責(zé)，本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。本站是一個(gè)個(gè)人學(xué)習(xí)交流的平臺(tái)，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對(duì)作者和來源進(jìn)行了通告，但是能力有限或疏忽，造成漏登，請(qǐng)及時(shí)聯(lián)系我們，我們將根據(jù)著作權(quán)人的要求，立即更正或者刪除有關(guān)內(nèi)容。本站擁有對(duì)此聲明的最終解釋權(quán)。
