提問回顧與個人總結

一、作業要求

我們在學期開始的時候布置了閱讀作業，要大家快速閱讀，同時提出自己的問題。

現在一個學期過去了，同學們完成了一個結對項目，兩個階段的團隊項目，中間還經曆了轉會環節。

正所謂"實踐是認識的來源、目的、動力以及檢驗認識真理性的唯一标準"，在經曆了一個學期的學習和實踐後，請大家寫一個提問回顧與個人總結的部落格。

項目	内容
這個作業屬于哪個課程	部落格園班級連結
這個作業的要求在哪裡
個人部落格作業	初窺軟體工程 2020BUAA軟體工程⋅個人部落格作業
我在這個課程的目标是	獲得成為一名軟體工程師的能力
這個作業在哪個具體方面幫助我實作目标	總結回顧

二、問題解答

問題1. 單元測試時如何有效拆分單元？輸入資料和輸出資料如何構造？

答：單元測試的粒度，依項目而定。例如在團隊項目中，我們做的知識路書web應用，其前端的單元測試是以任務功能進行劃分的，輸入的資料即為覆寫該功能子產品全部邏輯的一組操作。對于結對程式設計項目，單元測試應該以函數或類為機關，輸入輸出的資料即按照類的構造函數或函數的輸入參數進行。

問題2. 即使用了源代碼管理工具，也很容易忘記某個版本究竟是幹什麼的，如何更好地通過message提示自己？

答：使用內建開發環境的git GUI工具，可以更加友善地編輯message，甚至支援markdown文法。還可以github平台的pull request功能，能夠更加清晰地寫清某次代碼遷入做的功能是什麼。團隊開發時，要商議好commit的message和Pull request的message格式規範，例如我們的敏傑開發團隊規定的commit格式為：姓名：功能1；功能2；...

問題3. 怎麼在源代碼管理工具中更優雅地改bug?

這個問題理論上可以使用git rebase的方法進行，但是容易出錯，不是很安全。在我們的團隊項目開發過程中，直接使用順序commit式bug修複，由于很少使用代碼復原，維護的最新版代碼始終是目前功能最多、bug最少的版本。

問題4. 多人合作時，如何解決push沖突問題

不同開發者盡量不要同時修改相同的檔案，每個Issue和Pull request的粒度盡可能細就可以更好地保證這一點。如果真的趕上了必須要修改相同檔案的話，二者需要一起合并代碼，保證雙方的更改不出現沖突。在我們團隊項目的實際開發過程中，每個人負責開發的部分幾乎少有檔案重疊，當然也有少量情況出現了代碼沖突的情況，我們是通過有沖突的開發者共同解決沖突的辦法處理的。

問題5. 如何解決開發基礎差的問題？軟工課上如何解決？

對于我們的團隊項目知識路書的開發初期，隻有hdl一名同學擁有開發經驗，其它成員都是開發小白，但是我們隊伍的成員都有很強的快速學習能力，我們經曆了2年的程式設計訓練，已經有很好的程式設計功底，經過熟悉開發的成員一帶，很快就掌握了基本的開發技術，之後就是滾雪球式的技術積累了，在完成了alpha階段的開發任務後，我們的開發技術就都可以滿足我們項目的需求了。

問題6. 初創公司如何找到技術創新與營銷經營的平衡點？

對于技術初創公司，技術固然重要，但是一定不能掉進唯技術論的怪圈，隻顧技術，永遠在疊代産品、優化産品，而不去想推廣、想營銷。企業總歸是要以營利為目的的，推廣、營銷可以帶來更多的使用者，帶來更多的使用者回報，使團隊更清楚産品的真正需求。同時推廣營利可以招攬更多人才，有更多優秀且志同道合的人加入，同樣會進一步促進技術的發展。

問題7. 軟體工程有沒有什麼解決不了的問題？軟體工程的痛點在哪？

軟體工程解決不了的問題是現有的管理學理論無法很好解決的問題，無法抽象成統一的理論，這類問題的解決要因人而異、因事而異。不同的開發團隊、不同的開發産品都會有不同的解決方法，是以說管理學是一門藝術，軟體工程管理亦是如此，一個軟體工程項目的成敗、管理好壞，軟體工程理論固然重要，但産品經理、項目負責人的管理藝術往往更能決定産品的命運。是以，軟體工程的痛點也在于此，隻有将軟體工程理論，和實踐、經驗深刻結合、互相補充，才能早就一個優秀的産品經理，形成優質的團隊管理文化。

三、新的問題

1. 當團隊成員對價值觀念、産品方向有不同觀點時，應該如何解決觀念上的不一緻？

在《人件》中介紹了有凝聚力團隊的概念，大家都秉持相同的價值觀念、産品觀念，團隊整體的力量将大于個體之和。但是當團隊成員對價值觀念、産品觀念有不同觀點時，應該如何解決觀念上的不一緻、重新回到一個有凝聚力的團隊整體呢？

當觀點可調和時，采用讨論分析等辦法可以得出一個最優的解決方案，讓團隊中的所有成員認可。但是當觀點沖突不可調和時，又該怎麼辦？獨裁？分裂？還是...

2. 何時放棄？

當一個産品的實作難度、投入資源、預期收益等與原定設想不符時，團隊會倍感沮喪，凝聚力和幹勁都會大打折扣。作為項目負責人，有抉擇堅持還是放棄的責任，在何種條件下可以下定決心放棄？有沒有理論上的一種條件，達到這種條件就應該放棄，堅持就是浪費資源？

四、習得知識點

在團隊項目中，我們在實踐中學到很多軟體工程的知識點，下面分類進行介紹。

1. 需求

需求分析是一個軟體工程項目的第一步，抓住一個好的需求往往是項目成功必要條件。我們敏傑開發團隊，經過若幹次會議的頭腦風暴，碰撞出了幾個有痛點的需求，當時的選擇有三：

• 基于深度學習的字型自動生成
• 醫學、化學線上實驗平台
• 圖形化文獻管理工具

經過NABCD分析，我們最終得出，圖形化文獻管理工具這個需求我們團隊更能駕馭，我們本身就是該項目的目标使用者，可以更直接準确地分析出需求。于是我們選擇了知識路書——圖形化文獻管理工具這個項目作為我們的開發目标。

2. 設計

通過撰寫技術規格說明書和功能規格說明書，我們更加清晰地描述了整個項目的設計。在實際操作中，我們在組會中共同繪制ER圖，成員一起在一份ER圖上添枝、加葉、修改，最終共同碰撞出了一份完整、清晰的項目架構，團隊成員也都明确了項目的總體設計。在确定了項目的總體設計後，我們讨論了實作上的設計，由于目前web端應用的閱聽人廣、可移植性強、移植性好，我們選擇了基于web平台的實作設計，并進一步确定了選擇的前後端架構、平台、工具等，大家開始了前期的學習準備工作。

3. 實作

我們首先根據項目特點進行人員分工，我們的項目主打前端應用，後端主要提供CURD等api支援，是以前端共4名成員，後端2名，1人PM兼自由人，可以根據開發進度補充至前端或後端。在開發過程中，我們采用增量式靈活開發工作流，在alpha階段完成了最核心的功能，完成了一個最小可用版。在beta階段，持續重構與優化alpha階段的工作，并增量式添加新的功能。在開發中，類似每日建構原則(daily build)，我們做到了實時建構(always build)，我們保證每一次送出都必須可運作，在代碼互審時，不僅僅要展示所改動的子產品是否工作正常，還應簡要回歸測試原有功能，保證産品時刻可運作。

在項目管理中，我們學到了非常多的知識，在beta階段新成員進組時，我們向其介紹了我們團隊的整個項目工作流，讓其頗為驚歎，這才是軟體工程。關于我們的項目管理可以參考我的這篇部落格使用Github進行軟工開發管理

4. 測試

由于是靈活開發，在測試中也采用靈活開發的風格，我們的實時建構(always build)原則能盡可能保證前端在開發過程中的持續測試，每位成員在開發自己功能的時候，都可以不經意地測試網頁其它部分的功能，一旦發現問題，立即寫入Issue。由于開發過程中已經針對功能進行了較多的單元測試，在實際測試階段我們重點進行了場景測試，将使用者的使用流程分成若幹個工作場景，對軟體進行整體測試，保證使用者不會觸及最明顯的bug，另外還可以以使用者的身份體驗産品，得到新的改進需求。

對于後端，我們采用了覆寫率測試，使用成熟的測試架構，使測試覆寫率達到90%以上，保證了後端api的穩定與精準。

5. 釋出

我們在alpha階段的推廣出現了一些失誤，導緻了推廣效果不佳。主要原因是選錯了“目标使用者”，我們的産品主要面向有科研需求的研究所學生、博士生、導師等，而在alpha階段，我們重點向大學生進行推廣，導緻我們沒有達到預期使用者量。在beta階段，我們根據目标使用者的使用特征，定向地推廣給實驗室的研究所學生，讓他們在組會中嘗試使用我們的軟體，獲得了不錯的推廣效果。另外我們還做了針對大學生科學方法論課程的殺手功能，可以利用這個功能，讓同學們更友善地完成該課程的要求，我們在科學方法論課堂上展示了我們的産品，也收獲了不少的使用者。是以，對于軟體工程，開發技術固然重要，推廣的技巧也必不可少，不然就隻是寫程式，而不是寫軟體了。

6. 維護

對于維護，使用者的bug回報十分重要，我們在開發初期，就在頁面中加入了bug回報入口，在兩個階段的開發中，已經收到了大量的回報資訊，其中不乏對于bug的回報。

另外，成熟的文檔也必不可少，我們分别針對前端、後端、使用者寫了三份詳細的文檔，保證了後續接手的開發人員和維護人員可以快速上手。

五、心得體會

一學期的軟體工程課收獲滿滿。軟體工程課就應該在做中學、學中做。團隊項目中，我從一個開發小白的身份在alpha開發階段一點點摸爬滾打，從我們的前PM大佬學到了很多開發技術、項目管理方法。進入beta階段後，我有幸接替原PM大佬的工作成為PM，和團隊成員一起不斷完善我們的産品。PM的經曆讓我實踐了更多軟體工程領域的學問，我學會了如何與人溝通、如何配置設定任務、如何督促監管任務的執行、如何與團隊合作等等。看着我們的産品從無到有再到基本健全、收到使用者的積極回報，真的是一件無比享受且欣慰的過程。我會珍惜這次軟體開發經曆、珍惜一起結對程式設計的小夥伴、珍惜在北航度過的軟體工程時光～

2020.6.14 補充：最近中國若幹高校被封鎖了matlab軟體，引起了國内社會的不小争議。我覺得類似Matlab這種重要的科研軟體，我國需要投入人力和資金進行研發，對于這類大體量軟體的開發，軟體工程理論的指導不可或缺，國内的各大高校計算機專業和軟體專業應該更加重視軟體工程課程的品質，培養更多優秀的軟體工程技術人員。