如何做好軟件開發工作的思考

這篇文章我們來談一下如何做好軟件開發工作的問題。

要做好軟件開發工作，涉及方方面面的因素。本文就從筆者的角度出發來談筆者能看到的一些問題。

1? 共識

其實我感覺共識，并不是很復雜的東西。比如說一條船沉沒了，船上的所有的人都無法幸免。對于我們做項目也是一樣的。不是爭誰高誰低。還是想著一起把這個事情做好。

那么這個地方就有一個問題，怎么才算可以把事情做好？拿主意的那個人必須是個通才, 至少在面對當前這個問題的時候，能夠做出非常全面的把握。然后把想法兒說出來以后大家感覺可行，大家再去執行。

1.1? 舉個例子：

人上100，形形色色。

打個比方說吧，你請一幫人來家里做客。大家都玩的興高采烈，感覺客廳也非常寬敞，非常明亮，非常干凈，外面的景色也很舒服。但偏偏有人喜歡跑到廁所里去看，然后拿廁所的狀況跟客廳里的狀況進行比較，說你的廁所沒有客廳干凈。

這個就沒法談了。根本就不在一個層面上，有的人喜歡去查看黑暗，有的人喜歡崇尚光明，這個是價值觀的問題。

有人就是關注那些黑暗的東西，讓自己不痛快，然后讓別人也不痛快。碰上這種事兒，實在太鬧心了，干脆，眼不見心不煩。惹不起，躲得起。

畢竟時間寶貴，有那么多有用的事情要做呢。

2? 軟件開發復雜度

軟件開發的難度跟硬件開發最大的區別就是軟件開發的不可預知性，有時候碰上很多問題，我們無法用以前的經驗來框制。

2.1? 代碼相關的復雜度的控制

這個時候沒有別的辦法只能披荊斬棘先從開始到結尾畫一條線，一直找到一個可行的方案。

一條線代表一個功能需求的解決。接下來再解決其他的功能需求，那么這樣整個項目就會有很多很多條近乎平行的功能需求線，這樣復雜度就是線性的增長。

這是我個人能夠看得到的，在架構代碼和模塊代碼方面最理想的情況。

2.2? 系統部署相關的復雜度的控制

其次就是系統部署和運行方面。越簡單越好。簡單到一步。一步完成部署，比如點擊一個按鈕，運行一條命令。開發調試部分也是越簡單越好。每個小模塊兒是一步，多個模塊兒集合在一起的系統調試部署也是一步。

2.3? 新需求相關的復雜度的控制

我以前就碰上過這樣的問題。那是一個在線教育平臺，里面的功能有用戶管理(學生老師校長代理商)，班級管理，課程管理，視頻直播聊天室，考試系統，試卷評估，課程購買等等。后來老板要求加的一個功能是實時上課提醒，上課前一小時提醒，上課前24小時提醒，提醒方式有短信和郵件。

前面這套系統已經跑了一段時間了，后來加的這個功能跟前面的系統有關聯，但是關聯度不大。主要是后端的工作，而前邊應用的后端主要是提供API的功能。這個提醒的功能，主要是后端的服務輪詢功能。如果在以前系統的后端上增加功能的話，勢必會增加系統的復雜度和不穩定性。所以我采用的方案是單寫一套系統，包含前端和后端，共享前套系統的數據庫。

這樣在不影響前套系統正常運行的情況下，也解決了新需求。?我們做軟件系統就是這樣，做的東西越多，經驗就越豐富，就越能夠對整個系統做出更全面的把握。

對，正如大家所想的，這就是微服務架構的一個具體實現。

3? 代碼審查

對于代碼的修改，我們主要關注如下幾點:

3.1? 代碼的復雜度是不是降到了最低？

先說一下代碼設計的復雜度。

代碼設計的復雜度應該是收斂的，而不應該是發散的。也就是說在起始點復雜度為10的話，那到終止點的時候復雜度不能超過10。

如果終止點的復雜度超過了起始點的復雜度，committer?需要對代碼的整個設計結構進行審視。

再說一下代碼行的復雜度。

有人為了減少修改代碼的行數，在一行代碼中寫上多個函數調用。比如通過在函數的參數中傳入另外的函數。這種編寫代碼的方式會提高單行代碼的復雜度，我們應該把參數中的函數調用提到前面去，先把參數算出來，然后把計算出來的參數值再傳入到函數調用中。

這是大道至簡，好的代碼要返璞歸真，每個人都能看懂。

3.2? 如果有重復性的代碼，這種代碼的重復是不是必要的?

比方說，減少重復性的代碼會增加復雜度的話，我們一定要避免增加復雜度而允許這些代碼的重復。

這是兩害相權取其輕。

3.3? 驗證是必要的。

一定要創造條件跑一跑所審查的代碼。比較簡易的方式就是寫好充足的單元測試和集成測試。

這是以客觀結果為前提，不要盲目相信自己的主觀判斷。

4? 軟件重構

關于老產品整改的問題。如果只是縫縫補補的話，可能起不到化繁為簡的目的。其實做類似這種工作的話，有一個比較可行的方案。就是把現有的產品當做一個成型系統也就是現有運行的產品，不要做大的改動，頂多就是修改bug。

然后以這些成型的系統為基準，去寫新的系統。相當于參照一個大的白盒就寫一個小的白盒，這樣新的小的白盒質量上肯定比大的白盒性能上要有優勢。因為相當于開卷考試。

這樣子按部就班去做的話，就會比較靠譜。

有朋友會說上面的做法是重寫，字面意義上沒錯的。

4.1? 重構還是重寫？

實際上不矛盾。區別就是重構的方式應該從下往上還是從上往下。比如說我們現在大部分的重構都理解為從下往上來做。也就是感覺這個文件里頭有壞代碼的味道，然后就改這個文件，這樣做是沒有問題的。

比如現在有些教練遇到的問題，就是發現上下文不是很清晰，這個代碼為什么要這么寫？為什么一個文件有1萬行或者3萬行，這個來龍去脈不是很清楚。

這個時候可能就需要從整個子模塊來進行一個自上而下的分析。梳理出這個子模塊的功能需求是怎樣的，需要有多少個公共接口？內部公共接口的實現方式是不是應該像目前這樣的？

一個文件能夠寫成1萬行或者3萬行，肯定是有一定歷史原因的，絕大程度是由于全局把握的編程能力不夠造成的。

像這種情況，如果從這個文件本身去做重構的話，難度非常之大，但是如果從上往下，從模塊的整個設計角度來做重構的話，可能就容易一些。

4.2? 具體的參考步驟

這個時候需要做的具體步驟可以參考如下:

1.根據功能需求定義公共接口。

2.根據公共接口寫出測試案例代碼。

3.這個時候可以按照測試驅動開發的理念去填充代碼。

4.代碼可以從現有的代碼中抽取出來。

5.在抽取的過程中進行整理重構。

這樣，這個子模塊完成以后，就可以嘗試去替代現有的子模塊，看看能不能在整個系統中安全的運行。

這個是我理解的，從子模塊兒角度來看待一個重構過程。

4.3? 依此類推

對于整個系統來說，我們又可以分成很多個子模塊。然后又可以對各個子模塊各個擊破，最終完成對整個系統的重構。

如果一開始對整個系統進行重構的話，也是可以從自上而下的角度來看的。

比如說開始的時候先把所有的子模塊看成一些占位符，假定他們已經完成他們的接口了。那對于整個系統來說，它本身就是一個子模塊，屬于提綱挈領的那個模塊。

這個過程，從字面意義上可以理解成重寫，實際上，它也是一個重構的過程，因為我們肯定會重用這個系統本身的一些現有代碼和現有的邏輯。

5? ?軟件測試

軟件測試部分，我說說我對單元測試，集成測試，測試案例選取以及工作量問題的看法。

5.1? 單元測試

說一下單元測試部分的思考。

關于測試案例的編寫，主要是有兩個方面，一個是代碼物理行的覆蓋率，一個是代碼邏輯的覆蓋率。

物理行的覆蓋率相對來說比較簡單，有工具可以直接報出來。經常說的，100%的覆蓋率，85%以上的覆蓋率，都是物理行的覆蓋率。

代碼邏輯的覆蓋率就相對隱蔽一些。

打個比方說一個函數里面有兩個條件判斷分支。每個分支有兩種條件: if-else。

要做到物理行的100%覆蓋，我們可以這樣做到: 寫兩個測試案例。一個是if同時成立，另一個是兩個else同時成立。

要做到代碼邏輯的100%覆蓋，我們需要創建4個測試案例。包括上面的兩個測試案例以外，還要加上另外兩個if else交叉的情況。

這也就解釋了為什么100%的物理行覆蓋率，無法杜絕bug的產生。

因為沒有做到代碼邏輯的100%覆蓋。

從上面的例子可以看出，如果做到代碼邏輯的100%覆蓋，工作量比較大。但是如果沒有集成測試做配合的話，這一部分是必須要做的。

5.2? 集成測試

再說一下集成測試的思考。

針對上面的代碼邏輯覆蓋率的問題，一個折中的方案就是使用集成測試來結合物理行的代碼覆蓋率。

集成測試主要是用戶的需求功能單元。也就是通過某個測試案例，可以集中地反映在指定情況下用戶是如何獲得對應功能的。這一部分是模擬真實的用戶使用場景。

5.3? 測試案例選取

關于測試案例選取的思考。

測試案例的選取主要有如下方面，一是邊界值的指定，用于測試一些不常用，但有可能會出現的用戶輸入，二是常規值的制定，這一部分主要是演示用戶在大多數情況下所提供輸入的處理情況。

5.4? 測試代碼工作量

關于測試代碼工作量問題的思考。

一般情況下我們都承認沒有測試的代碼是不完整的代碼。因此測試代碼無論如何都是要寫的。

那么如何寫測試代碼才能最省時省力呢？

我的體會是在模塊或者項目編寫的時候，同時配置好測試框架。先針對一些成型的代碼進行測試案例編寫作為示范。如果代碼還沒有成型就寫測試案例的話，會帶來非常不必要的測試代碼修改工作量。所以這里有一個時機把握的問題。

除了最開始的測試框架代碼部分，一般來說大面積的測試案例代碼的添加是在項目已經成型的時候才開始的。案例代碼除非特別情況，不要有任何條件判斷。基本上都是平鋪直敘的一條直線的邏輯。測試案例代碼，由于其特殊性，可能存在很多重復的現象，這個都不是問題。

軟件開發

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