軟件工程開發之道：了解能力和復雜度是前提

小引

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

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

2. 哪些地方我們需要注意復雜度的問題？

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

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

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

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

7. 為什么我們需要對代碼和設計進行重構？如何做？

8.? 如何保證軟件開發的質量呢？

能力

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

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

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

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

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

如果沒有難題，成員單獨解決了，那么組長需要把解決方案理解透徹，把好關，同時好好學習。

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

上面是對組長的要求，這里第1位的是學習能力，就是對于未知領域的熱愛和領悟能力。

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

這里面需要理解力和執行力的培養。這個需要一段時間的磨合，整個團隊才能夠形成強大的戰斗力。

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

培養主觀能動性需要驅動力，一般來說有這么幾個:

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

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

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

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

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

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

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

很多程序員上來就會陷入到思考如何拯救星球的迷霧中。這個思路的第一要務就是要先區分有多少種星球，然后對這么多的星球進行分門別類。然后在項目運行時判斷某個輸入參數來指定是地球以后，再進入到思考如何拯救地球的任務當中去。

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

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

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

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

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

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

復雜度

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

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

不管是變量的命名還是函數的命名，我們都希望看到名字，我們應該能夠理解這個變量或者函數大體是關聯到什么樣子的事情。

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

第二是程序邏輯的復雜度。線性順序執行的復雜度為1, 出現分支以后要乘以分支的個數。分支可以是條件判斷也可以是循環。所以盡可能的避免分支的出現是降低程序邏輯復雜度的重要手段。

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

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

第三是架構設計的復雜度。架構設計涉及到模塊設計和系統設計。要盡可能的把一些公用的模塊或者子系統抽取出來，比如安全相關的，日志相關的，工具相關的等等，這些公用的功能可能會被所有其他的業務模塊或系統所調用。

在調用這些公用功能的時候，越簡單越好，并且調用者不需要關心具體的內部實現，只需要知道如何使用就可以了。

這樣做的目的是讓程序員專注到業務代碼的設計上來。

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

與部署相關聯的還有集成部分。如果能夠實現自動化或者從模板中創建那是非常好的狀態。

第五是測試的復雜度。測試分白盒測試和黑盒測試。白盒測試的復雜度直接關聯著代碼層級的復雜度，代碼層級的復雜度越高，當然白盒測試的復雜度也就越高。

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

這種代碼的風格就是簡單直接，復雜度線性化。

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

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

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

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

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

（未完待續……）

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。