軟件論道一：能力與復(fù)雜度

小引

在本文中我們將探討如下問題：

1.?軟件工程需要哪些能力以及如何保障這些能力？

2.?哪些地方我們需要注意復(fù)雜度的問題？

3.??考試的目的是什么？

4.??莫要讓規(guī)范束縛了我們的手腳，成為技術(shù)的奴隸。

5.??要讓人的能力發(fā)揮到極致，良好的心境是必須要有的。

6.??專注于自己擅長的事情。那么，在軟件工程當(dāng)中，這樣的理念應(yīng)該如何貫徹呢？

7.?為什么我們需要對代碼和設(shè)計進行重構(gòu)？如何做？

8.??如何保證軟件開發(fā)的質(zhì)量呢？

能力

能力是成敗的關(guān)鍵，這一節(jié)我們會探討一下軟件工程需要哪些能力以及如何保障這些能力。

所謂軟件工程能力實際上就是解決具體問題的能力，也就是把實際中的問題轉(zhuǎn)化成項目代碼的能力。

說一下人員能力的提升這一塊兒。一個項目中一定要有一個靈魂式的人物。盡管我們說現(xiàn)在的軟件工程開發(fā)是一個團隊的合作成果，但是這個團隊中必須要有一個大腦，不能有多個大腦。

這個怎么理解呢？對于小的團隊來說，假設(shè)有10個人的團隊，那我們就說組長就是這個團隊的靈魂。組長需要帶領(lǐng)大家進行調(diào)研工作，最后作出結(jié)論進行取舍。這地方可以理解為架構(gòu)設(shè)計方向的制定。

這一步看清楚以后，接下來就需要把這些活兒分配給各個成員。組長需要緊密跟進項目的進展，比如說遇到難題了，組長需要跟成員一起去解決掉，而不是交給成員去單獨攻克。

如果沒有難題，成員單獨解決了，那么組長需要把解決方案理解透徹，把好關(guān)，同時好好學(xué)習(xí)。

對于組長的要求是假設(shè)整個團隊10個人，只剩下組長一個人，他也應(yīng)該有能力把這個項目維護下來。

上面是對組長的要求，這里第1位的是學(xué)習(xí)能力，就是對于未知領(lǐng)域的熱愛和領(lǐng)悟能力。

接下來說組員。組員第一要務(wù)就是把分配下來的任務(wù)好好完成。

這里面需要理解力和執(zhí)行力的培養(yǎng)。這個需要一段時間的磨合，整個團隊才能夠形成強大的戰(zhàn)斗力。

再一個是主觀能動性的培養(yǎng)。如果任務(wù)完成了，就應(yīng)該主動去尋找新的任務(wù)去做，有活的時候好好干，沒活的時候找活搶著干。

培養(yǎng)主觀能動性需要驅(qū)動力，一般來說有這么幾個:

第一，是自我價值實現(xiàn)的欲望，首先是天生我才必有用的自信，也就是每個人都想做些事情，尋找自身的價值，并把自身價值融入到團隊的工作當(dāng)中。

第二是外在的獎勵，這些獎勵可以包含物質(zhì)上的，名譽上的等等。也就是杰出的工作得到了認可。

上面是對于組員的要求，這里處于第1位的是執(zhí)行力，就是得到指令以后快速完成任務(wù)的能力。

現(xiàn)在說一下工程方法這一塊。比較流行的算是敏捷方法論。在敏捷方法論中一般有兩種方向一種是開發(fā)團隊驅(qū)動，一種是項目經(jīng)理驅(qū)動。不管采用哪一種方向，這種方法論的一個基本要求就是能夠在短期內(nèi)有看得見的輸出，并且有持續(xù)的輸出。

這種方法論用的舒服了的話會給整個團隊帶來很強的成就感和昂揚的斗志，從而激勵團隊成員把工作當(dāng)做一種樂趣。在現(xiàn)實的應(yīng)用中敏捷方法論可能會被形式化，比如每天大家都站在那里花幾分鐘的時間講幾句話。如果是這樣子的話，就走偏了。?為了避免形式化，應(yīng)該以輸出為導(dǎo)向。及時向其他團隊成員更新自己的狀態(tài)。

現(xiàn)在說一下算法和邏輯部分。對于軟件技術(shù)，我認為大多時候是把它當(dāng)做一個工程技術(shù)來運用的，也就是拿著這個工具去解決實際的用戶需求的。在技術(shù)運用的過程中，我們會不斷地使用各種各樣的算法和邏輯來隨機應(yīng)變的處理我們的業(yè)務(wù)流程。對于具體的算法和邏輯，完全是case?by?case的。我們先不深入探討個例。我們要探討一個非常重要的概念，就是復(fù)雜度的問題。

我與很多程序員共事過，尤其是高級程序員，發(fā)現(xiàn)很多人都有一個習(xí)慣，喜歡把簡單的問題復(fù)雜化。美其名曰要考慮周全，要考慮周到。這里說一個很簡單的例子，比如說我們拿到一個項目，這個項目的需求是拯救地球。

很多程序員上來就會陷入到思考如何拯救星球的迷霧中。這個思路的第一要務(wù)就是要先區(qū)分有多少種星球，然后對這么多的星球進行分門別類。然后在項目運行時判斷某個輸入?yún)?shù)來指定是地球以后，再進入到思考如何拯救地球的任務(wù)當(dāng)中去。

如果你問為什么要把這個問題思考的這么復(fù)雜，因為我的需求只是拯救地球而已。一個非常高大上的理由就是他想做一個通用的項目，以后可以支持更多的星球，從而方便擴展。

基于這種思路去做項目，項目會越做越復(fù)雜，團隊會越來越龐大，成本自然也就急劇的上升。

亞馬遜在這個方面是吃過很多苦頭的。在早期的項目中，有些程序員設(shè)計項目過于復(fù)雜，導(dǎo)致這些人升職離開項目以后，其他人根本無法接手維護這個項目，即使再去找原來的設(shè)計者，他們也無能為力了。因為復(fù)雜度太高了。

關(guān)于流程和工具。這兩個方面可以合在一起說。流程需要簡潔高效，直擊要害解決問題。工具也是一樣的。雖然每個人的喜好有些不同，有的人喜歡界面，有的人喜歡命令行，這個都沒關(guān)系，那就選能夠給自己帶來最高工作效率的那種工具和流程。

在嵌入式驅(qū)動開發(fā)領(lǐng)域里面，有些公司是用普通文本編輯器來寫代碼的，代碼審查是用比較軟件的方式手工合入代碼的。雖然驅(qū)動式開發(fā)中的代碼量不是應(yīng)該特別多，比如說一個driver，如果代碼量很大的話，可能就存在設(shè)計上的問題了。即使代碼量很小的情況下也應(yīng)該使用比較先進的工具來處理,?比如代碼編輯可以使用vs?code,?eclipse,?qt?creator等等，代碼審查可以使用平臺工具如github,?gitlab,?bitbucket,?gerrit,等，代碼查看可以使用git工具(?fork,?git?extensions)等等。

以上只是用一個例子來闡釋避免使用非常原始的工具，既容易出錯又效率低下。

復(fù)雜度

現(xiàn)在來談一談復(fù)雜度的問題，軟件開發(fā)中的復(fù)雜度當(dāng)然是越低越好。一般談到復(fù)雜度，我們可能想到了各種邏輯上的復(fù)雜度，設(shè)計上的復(fù)雜度，實際上在軟件過程中復(fù)雜度涉及到方方面面，我們來看一下，具體有哪些方面我們需要注意復(fù)雜度的問題。

第一是命名規(guī)則。先舉個例子，我定一個變量叫word。有的人喜歡把它寫成wd。這個就增加了這個變量定義的復(fù)雜度，你從wd很難明白，這個變量是word的意思。

不管是變量的命名還是函數(shù)的命名，我們都希望看到名字，我們應(yīng)該能夠理解這個變量或者函數(shù)大體是關(guān)聯(lián)到什么樣子的事情。

所以謹慎的使用縮寫是避免命名規(guī)則復(fù)雜度提高的重要前提。

第二是程序邏輯的復(fù)雜度。線性順序執(zhí)行的復(fù)雜度為1,?出現(xiàn)分支以后要乘以分支的個數(shù)。分支可以是條件判斷也可以是循環(huán)。所以盡可能的避免分支的出現(xiàn)是降低程序邏輯復(fù)雜度的重要手段。

如果程序分支不可避免，要盡可能的把程序分支放到最高的邏輯層。這樣做的目的是為了避免在下層處理的時候出現(xiàn)發(fā)散式的分支。發(fā)散式的分支會急劇的增加程序的復(fù)雜度。

復(fù)雜度越高，程序越難維護，復(fù)雜度超過一定程度，人類程序員是無法處理的。

第三是架構(gòu)設(shè)計的復(fù)雜度。架構(gòu)設(shè)計涉及到模塊設(shè)計和系統(tǒng)設(shè)計。要盡可能的把一些公用的模塊或者子系統(tǒng)抽取出來，比如安全相關(guān)的，日志相關(guān)的，工具相關(guān)的等等，這些公用的功能可能會被所有其他的業(yè)務(wù)模塊或系統(tǒng)所調(diào)用。

在調(diào)用這些公用功能的時候，越簡單越好，并且調(diào)用者不需要關(guān)心具體的內(nèi)部實現(xiàn)，只需要知道如何使用就可以了。

這樣做的目的是讓程序員專注到業(yè)務(wù)代碼的設(shè)計上來。

第四是系統(tǒng)部署的復(fù)雜度。系統(tǒng)部署包含幾個不同的階段如開發(fā)階段，測試階段和生產(chǎn)階段。不管是哪個階段，部署的步驟越少越不容易出錯。有些系統(tǒng)天然的需要很多指令的配置，如果是這樣的情況，需要編寫一個批處理的文件來簡化外部使用者的部署步驟，把多個步驟變成一步。

與部署相關(guān)聯(lián)的還有集成部分。如果能夠?qū)崿F(xiàn)自動化或者從模板中創(chuàng)建那是非常好的狀態(tài)。

第五是測試的復(fù)雜度。測試分白盒測試和黑盒測試。白盒測試的復(fù)雜度直接關(guān)聯(lián)著代碼層級的復(fù)雜度，代碼層級的復(fù)雜度越高，當(dāng)然白盒測試的復(fù)雜度也就越高。

白盒測試需要注意的一個重要問題是不要使白盒測試這部分的代碼脫離實際業(yè)務(wù)代碼的設(shè)計。也就是說白盒測試它的依附對象就是我們實際的業(yè)務(wù)代碼，從架構(gòu)設(shè)計上說是一個附屬層，不要試圖在這里使用什么軟件設(shè)計藝術(shù)或者所謂的編程藝術(shù)。

這種代碼的風(fēng)格就是簡單直接，復(fù)雜度線性化。

黑盒測試的復(fù)雜度來自于業(yè)務(wù)需求分析。要有非常清晰的文檔說明，需要對測試步驟和預(yù)期結(jié)果寫的非常清楚。

第六是技術(shù)的復(fù)雜度。技術(shù)的發(fā)展趨勢一般是越發(fā)展越簡單，功能越強大。那么在設(shè)計和開發(fā)的過程中，要避免使用老舊的技術(shù)。關(guān)于技術(shù)框架的選擇，要提前做好調(diào)研。前端選什么框架，要不要選擇某些UI庫，后端選什么框架，要不要選擇某些程序庫，原則上是為了簡化我們的學(xué)習(xí)過程，提高開發(fā)效率，增強整個項目的可維護性。需要具體問題具體分析。

第七是隊伍結(jié)構(gòu)的復(fù)雜度。隊伍構(gòu)成一定要短小精悍，人多不一定好辦事。像亞馬遜提倡的是兩張披薩團隊，意思是說整個團隊兩張pizza就能吃飽。大體估算就是10人左右的一個隊伍。當(dāng)然這只是一個參考指標。

整個隊伍的目標一定要明確。所有的人都向著那個目標邁進，分工可以不同，但是目標一定要一致。

目標+分工是隊伍成功運作的關(guān)鍵。具體來說就是把目標分成多個任務(wù)，每個任務(wù)里又可以分成小任務(wù)，那所有的人都去做對應(yīng)的任務(wù)，自己讓自己忙起來，而不是別人讓你忙起來。

軟件開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。