| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2020春北航計算機學院軟體工程(羅傑 任健) |
| 這個作業的要求在哪裡 | 提問回顧與個人總結 |
| 我在這個課程的目标是 | 系統學習軟體工程相關知識并進行實踐。 |
| 這個作業在哪個具體方面幫助我實作目标 | 回顧學期初提出的問題，總結本學期的軟體開發實踐。 |
以前提出的問題
軟體工程 - 個人部落格作業
嘗試解答
如何進行高品質的單元測試？
Q: 作者在2.1節 單元測試 中提到了單元測試失效的幾種情況。在筆者實際使用單元測試中，盡管能夠對代碼進行覆寫測試，但是總覺得一些簡單的單元測試無法對代碼的所有運作邏輯進行測試(例如：循環、函數間邏輯)。此時應當如何學習編寫更高品質的單元測試代碼呢？
在軟體工程的項目中，筆者主要負責了前端的工作，在測試上也主要使用功能性測試。在實際的合作編碼過程中，我們發現，實際上大部分的bug在進行子產品的示範過程中都能夠被發現。
是以，我認為前端的高品質單元測試的要點在于合理的子產品分割和定義好期望要求。對子產品任務進行合理的分割，讓每一部分都是一個可以獨立運作的子產品，這樣有利于對任務進行劃分(每個單元有具體的權責配置設定)，也有利于子產品的示範。
在編碼前讨論定義好期望要求，一方面能夠在讨論的過程中共同決定好實作的具體思路，有利于高效開發，另一方面也在編碼前對期望的功能進行了具體的規範，在測試過程中按照期望的功能邏輯進行示範就可以了。
例如，我們組在開發文獻管理界面時，需要定義一個
drawer
，我們便共同決定了這個
drawer
的實作思路，并定義好的其預期功能(如打開效果，資料同步狀态，關閉/取消效果，送出效果等)。在測試過程中，對這些功能進行逐一示範便能夠發現大部分可能會存在的問題。
結對程式設計真的更高效嗎？
Q: 作者在書P86提到，結對程式設計可以取得更高的”投入産出比”。我認可結對程式設計可以有效提高代碼品質，但是我認為合作的效率更好。 1. 二人合作是4隻手在程式設計，從速度上講比結對程式設計更高，能夠快速實作已經制定的目标；2. 結對程式設計面臨二人技術能力不同而可能導緻的一人程式設計、另一人參與度較低的情況；而二人合作可以通過任務量配置設定差異來規避此問題。3. 結對程式設計主要特點是二人不斷交流、不斷互審，那麼二人合作也可以進行不斷交流和審閱。是以，我認為結對程式設計的“投入産出比”可能不如合作程式設計。
在本學期軟體工程的課程上，我也有幸嘗試了結對程式設計開發方法。經過實際體驗，我認為結對程式設計的效率是高的，因為開發效率不等于敲代碼的速度。
如果單純看代碼錄入的速度，那麼結對程式設計的效率一定是不如分工程式設計的。但是，開發絕不是隻有編碼，結對程式設計可以大大提高代碼的品質，減少之後修bug等工作的時間，從總體上看是能提高效率的。
新人如何融入靈活團隊？
Q: 作者在第六章介紹了靈活開發，靈活開發注重人員之間的溝通，能夠有效增加開發進度。
但是靈活開發對于團隊的要求較高，如果團隊人員流動較大，不熟悉項目的新手如何能較快地融入到靈活開發的團隊中呢？
在本學期的軟體工程開發過程中，我們也經曆了轉會，有新的同學加入了我們的團隊。新同學主要的融入方式我認為是首先和以前的開發同學進行合作，共同負責一個較大子產品的開發，之後在熟悉項目後逐漸負責一個子產品的開發。
文檔的維護可能是靈活開發的通病，文檔的更新可能會有一定的滞後性，是以新人不能完全依靠文檔來接手項目，但是靈活開發對于人員之間溝通的注意能讓每個開發者都比較熟悉項目内容，那麼由開發者指導新人 是比較合适的。
該不該立即回團隊成員email？
作者在這裡提供了一些非常有用的建議，例如集中處理Email，微信等。
那麼我們在開發過程中，如果有團隊其他人員的相關問題，是否應當及時回複呢？如果不及時處理，可能會影響團隊其他人員的進度；而及時處理又可能耽誤自己手頭的工作。
我們對項目成員的問題要進行分類，對于非常緊要的問題(阻礙該成員進度推進的問題)，我們可以進行較快的回應；而對需要上手修複的bug或者其他問題我們可以選擇性的集中處理。主要原則是不耽誤自己的開發進度，也在最大程度上幫助團隊成員提高開發進度。
BUG應該立即修嗎？
作者在11.5.5節講到一個比較有意思的事情“小強地獄”，即bug積攢數量到一定程度的隊員要使bug低于門檻值才能繼續開發；作者在後文中也提到一些小bug可能導緻功能重寫。
在自身的開發中，我也出現過由于一些之前的bug沒有及時修複，導緻後續需要大量時間重寫某些功能的情形。那麼，我們是對于出現的bug，是應當發現一個立即消除一個嗎？修bug而影響的開發進度是否值得？
bug不一定要了解修複，但是issue要開好。
對bug進行分類，影響開發進度和功能的bug是需要盡早修複的，而其他的小bug可以等開發階段結束後集中處理。在開發過程中，我們要利用好Github的issue功能，對發現的bug進行記錄，以便後續集中修複。
為什麼創新拓展不被接受？而“線性拓展”有着更好的命運？
作者在第16章談到， 在算法和資料庫領域，創新的想法一開始往往不被接受，而那些在前人基礎上的“線性拓展”則往往有着更好的命運。而這些決定還是很有經驗的期刊審稿人做出來的。
在科研領域，"線性拓展"的工作因為可以和前人工作進行比較，這樣的工作也更好去評價他的價值。創新拓展由于其可能存在的不确定性可能難以受到足夠的重視。當然好的工作一定會發光，我們在進行一些創新性的工作時，也可以在某些次元上和已有的工作進行比較，來說明創新工作的優越性。
新的問題
我們本學期由于客觀原因是進行了遠端開發，由于無法進行每日立會等，靈活開發過程中溝通的效率可能沒有面對面程式設計高。不知道在遠端開發的環境下，靈活開發方法是否适用？或者要進行哪些方面的改進呢？
軟體工程知識點
- 需求
- NABCD分析法：即從Need、Approach、Benefit、Competitor 和 Delivery 六個方面，全面分析目标使用者；
- 在和目标使用者交流的過程中，需要注意引導和挖掘目标使用者對于産品的需求；
- 設計
- 自頂向下：從目标産品的最終形态和功能出發，分拆具體的子子產品；
- 前後端分離：前後端分離設計，通過接口調用進行通信；
- 實作
- 利用Git進行代碼維護，并保持主分支為可以建構的代碼，進行每日建構；
- 使用Github的相關功能：如issue和commit進行關聯等
- 測試
- 後端進行單元測試
- 前端進行功能性測試
- 釋出
- 開發過程中不斷記錄出現的bug，在釋出前一并修複
- 對軟體整體進行壓力性測試
- 維護
- 注意收集使用者回報，對使用者回報的bug進行處理
了解和心得
個人項目
在個人項目中主要熟悉了Github進行源代碼管理的使用，對問題的分析、拆解和具體編碼實作過程。
結對程式設計
結對程式設計環節我們體驗了二人結對時如何進行交替分工、代碼複審、共同确定編碼思路。這一階段主要鍛煉了我在開發過程中的交流能力和合作能力。尤其是在遠端結對的過程中，如何進行高效溝通和遠端配合，對最終完成的代碼品質有着重要的影響。
團隊項目
在能力方面，團隊開發的過程中鍛煉了我的快速學習能力，在學習中實際上手開發。在軟體工程方面，我實踐了設計和實作環節中的一些方法，如Git & Github的使用，自頂向下逐級拆分的設計方法等。在團隊合作的過程中，我鍛煉了合作能力，隻有和隊友的有效溝通，才能維持項目的進度不斷推進。
在實際團隊項目的過程中，也感受到了軟體工程在控制軟體品質和開發進度的過程中的重要性。在之後的軟體開發中，也要繼續實踐在課程中學習到的知識，并吸收更多新的思想。