提問回顧與個人總結
Author: 17373015 喬玺華
| 項目 | 内容 |
|---|---|
| 這個作業屬于哪個課程 | 2020春季計算機學院軟體工程(羅傑 任健) |
| 這個作業的要求在哪裡 | |
| 我在這個課程的目标是 | 學習軟體工程的開發知識，初步具備多人開發軟體的能力 |
| 這個作業在哪個具體方面幫助我實作目标 | 分析自己目前的需求以及對未來的展望，還有對過去的反思 |
| 提問部落格連結 | BUAA 2020 軟體工程 個人部落格作業 |
目錄
- BUAA 2020 軟體工程 提問回顧與個人總結
- 一、對自己提出的問題進行解答
- 二、還不明白的問題
- 三、學到的新知識
- 四、心得了解
一、對自己提問的回答
問題一
Q1：單元測試必須由程式的作者本人來編寫嗎？
《建構之法》在2.1.2節中提及單元測試必須由最熟悉代碼的人（程式的作者）來寫我承認這個觀點存在優越性，代碼作者必然是最了解代碼各部分的功能實作，了解每一行代碼的目的和局限性，而且單元測試有時候需要開發對代碼進行部分重構才友善進行，開發自己做這些重構也比較順手。
- 但同時我認為開發工程師自己編寫單元測試存在一下幾個弊端：
- 大部分的開發人員缺少優秀的測試思想，單元測試很有可能隻是十分簡單的測試樣例，能夠通過單元測試發現bug的幾率極低，這樣的單元測試更加傾向于形式而不具有實際價值。
- 開發人員有可能在編寫程式的時候，就對某個知識點存在錯誤的認知，這也會導緻他在編寫單元測試時仍然帶者錯誤認識，即無法編寫出能夠發現該錯誤的單元測試
- 開發人員寫業務代碼的時間就已經十分緊迫，缺少足夠的編寫優秀的單元測試的時間。
- 組内測試人員為開發人員編寫單元測試存在以下優勢：
- 測試人員編寫的單元測試能夠保證用力的覆寫和全面性，擁有豐富的測試經驗以及發現漏洞的敏銳能力
- 編寫單元測試能夠幫助測試人員更加了解具體代碼的架構、流程等，為日後的測試打下良好的基礎。
單元測試确實應該由最熟悉代碼的人來編寫，隻有代碼的編寫者才知道自己代碼段内的各個環節，以及測試的時候應該對哪些部分進行嚴格測試，單元測試相對于測試人員進行的産品測試來說，更傾向于是一個門檻測試，隻是為了簡簡單單對産品進行一下測試，檢視是否有一些十分明顯，甚至不需要給測試人員測試就能發現的bug，這樣的測試可以極大的減少由于開發人員自身的某些失誤或粗心導緻的bug數量，算是對自己代碼的一個檢驗，目的并不是為了消除代碼中的全部bug，而是為了對自己進行一下檢驗，讓自己有一定的信心能夠把代碼給測試人員進行測試。
問題二
Q2：結對程式設計中兩人的角色是否需要不停的輪換？
《建構之法》4.5.4節中提及在賽車越野比賽中，并沒有出現過領航員與賽車手不斷輪換的情況，這是因為賽車手擅長駕駛汽車，而領航員擅長分析比賽路線以及周圍情況，做出準确及時的判斷，在結對程式設計中，我認為亦然。隻有當結對程式設計雙方能力相近，擅長領域相似的時候，才存在輪換的可能性，而在大多數情況下，必然是一人水準高出另一人，且兩人必然擅長各自擅長的領域而沒有太大的交際，駕駛員-領航員模式下，若是讓水準較低的一方擔任領航員，很有可能最終的結果是水準較高的乙方分飾兩角，而水準較低的一方隻能幹坐，被動的接受。這種情況對于程式設計效率的提高沒有任何幫助。
- 駕駛員和領航員不斷輪換角色，不要連續工作超過一小時，每工作一小時休息15分鐘，領航員要控制時間。
保持原有想法不改變，結對程式設計時，兩個人的角色并不需要太多的互換，雖然是兩個人，但也是一個團隊，在進行工作時，完成自己相對擅長的工作，遠比定期輪換，要學習新知識，做自己沒有接觸過或是不擅長的工作來的更加高效。工作進行到一半，角色的互換往往會帶來小組工作效率的下降，若有一人對于目前的工作産生了困難，可能還需要咨詢另一名隊員，而此時不僅會導緻個人效率的降低，同時拉低了隊友的效率，造成惡性循環。這樣的作法或許對個人的提升極為明顯，畢竟四舍五入每個人都接觸了結對程式設計工作的幾乎全部内容，但軟體開發，更甚者靈活開發講究的是高效，迅速，更傾向于工業上以做出成品為第一目标，是以我還是偏向結對過程中，保持個人角色，有始有終。
問題三
Q3：靈活開發是否需要優質的開發文檔撰寫？
我通讀了《建構之法》第六章靈活流程，其中的靈活開發給我留下了深刻印象，靈活開發講究的就是高速和高效，每日都開例會（立會），但這一切似乎都是口頭一些講述，似乎并沒有提及開發文檔的撰寫，是靈活開發為了追求速度的效率，跳過了開發文檔的撰寫，還是說靈活開發有一套專屬的開發文檔撰寫方法？如果确實有，那麼老師可不可以大緻描述一下靈活開發的開發文檔與平時的開放文檔有什麼差別？若是沒有，那麼是不是該考慮增加開發文檔的撰寫，因為一旦有緊急情況發生，原來開發小組的人員出現了缺失，需要新鮮血液補充時，新來人員可能需要一份書面的文檔才能更好的了解項目内容，項目進度等，而口頭的描述可能會出現遺漏或口誤，導緻不必要的麻煩。
很有幸，我們組在進行随機人員轉會時，我成為了随機數選中的那個人，是以也親身經曆了離開熟悉的團隊，參與到另一個完全陌生的團隊項目中，由于當時選團隊的時候進行了慎重的考慮，第二個團隊的任務在beta階段剛好和原團隊類似，都是前端APP的開發，恰好是我熟悉的工作，并且由團隊PM給我進行了簡單的講解，目前的團隊狀況還有進展等，并沒有花費太多的時間，我就迅速地開始展開工作了，同樣沒有閱讀以往文檔，靈活開發，注重的就是速度和品質，精美的開發文檔可以等到開發結束後進行編寫，在開發階段，就應該全心全意投入到開發中。
問題四
Q4：PM是否需要具有很強的項目相關的專業能力嗎？
在閱讀了《建構之法》9.5中PM的能力要求與任務後，我注意到作者提及一個合格的PM，需要..個人認為作為項目經理，不僅需要極強的溝通能力，必然需要能夠了解項目全貌以及其中大緻的實作方式的能力，PM個人需要有過編寫項目的經曆，如果項目相關的專業能力不夠，如何在緊要關頭判斷出優先級，做出正确的判斷；同時項目經理需要知道各種技術的實作難度以及是否能夠實作，這樣在與客戶交談的過程中，才能夠進行有效的交涉，為客戶提供令人滿意的服務，同時也不會為項目組接來某種極其困難或是根本無法實作的項目功能，合理根據工作量進行分工協作，上司團隊的人必然需要有一個全面的知識儲備，具體的實作細節或許并不需要太過清楚，但大緻思路需要個人有所了解。而書中并沒有提及項目相關的專業能力，而僅僅是泛泛而談了一下
- 一定的專業能力
PM的專業就是了解和表達
我認為PM确實需要很強的專業能力，我經曆了兩個項目的小組，每個小組的PM都實際或多或少的參與到了生産工作中，或許代碼産量并不是特别高，但也都利用他們的專業知識，對于整個開發過程做出了不可缺少的貢獻，或許他們不用親自寫代碼，但他們可以做到對一些問題的評估，在作決策的時候提出自己的專業性意見，并且可以完成代碼的review工作。或許這是因為這樣的軟工團隊還不夠成熟，在現實工作環境裡，可能PM并不需要太多的專業性知識，而是僅僅完成開發與甲方之間的交流、協調。
這樣的回答是經曆了一個學期的軟體開發工程後，在實戰以後才能得出的經驗，“紙上得來終覺淺，絕知此事要躬行”，這樣的詩句不無道理。
Q5：代碼覆寫率測試是否具有實際意義？
《建構之法》13.2.2節中提及若是代碼覆寫率測試結果無論高低，都需要進行後續的測試，那麼為什麼要進行代碼覆寫率測試呢？我在網上進行搜尋後，得到的回報并不能說服我，如是用來發現沒有被測試覆寫的代碼，但在建構測試代碼階段必然會針對每個區域進行測試，又何來沒有被測試覆寫的區域一說；代碼覆寫率可以作為測試自我審視的重要工具之一，但這樣的說辭并沒有太大實際價值，并且對于後續的測試也不會有實質性的幫助，甚至代碼覆寫率高存在讓測試人員提前滿足的可能性，導緻之後的測試被弱化，豈不是得不償失。100%的代碼被執行了，是不是意味着再也不用寫新的測試用例了呢？
答案是否定的。
我仍然無法了解代碼覆寫率的意義，經過一學期的開發，代碼覆寫率對于我們的開發工作而言，形式大于意義，僅僅是一個百分數，在實際開發工作中起不到太多的實際作用，測試的時候都會根據個人的了解進行全面的測試，然後在測試完畢後，為了代碼覆寫率達到一定的高度，而去修改自己的測試代碼，感覺有一些形式主義，或許是還有一些實際的意義，隻是我們開發時間太短、開發項目過簡單，導緻無法發現，我也期待在以後的開發過程中，能夠逐漸了解代碼覆寫率的價值。
- 需求
需求方面，可以使用投票網站，找一部分的目标使用者群體進行投票，選擇優先開發的需求
- 設計
建議先使用某些專業軟體繪制出一個大緻的demo，這樣的在實作過程中，遠比個人全靠空想進行布局來的更加高效
- 實作
首先需要對實作方法有個大緻了解，即搭建基本架構，細節部分可以慢慢琢磨，但大架構需要在最開始就有一個正确的認識。
- 測試
許多編譯器都有一些插件支援代碼的測試功能。
- 釋出
釋出階段，需要内容足夠吸引潛在使用者打開連結，進行下載下傳，可以使用文字+圖檔的方式，吸引使用者。
- 維護階段
維護階段，在APP内部開設bug報告管道，及時與使用者進行聯系，對于bug産生的現場進行還原，盡最大可能迅速修複。
要說感觸最深的，應該就是團隊開發階段，因為我們團隊真的有一個很優秀的PM，是以我們的項目被很好的分割成了每一天的大小，每天完成項目的一部分，我很享受每天中午開例會，彙報前一天的工作情況，并且對于自己接下來一天的工作進行一個大緻的估計，也很感謝團隊的組員，大家都很努力，都會盡可能的及時完成自己的任務，在組員遇到困難時，也都會伸出援助之手，對内氛圍十分融洽，這樣的經曆也讓我有了一個深刻的感受，團隊合作的力量終究是能夠超過個人的，一個團隊或許隊内組員并不都是大佬，但隻要分工明确，努力的結果将會不亞于，甚至可以超過大佬的團隊，我也是第一次認識到團隊的力量真的可以做到很多，之前可能難以想象的事情。