提問回顧與個人總結

項目	内容
這個作業屬于哪個課程	2021春季軟體工程（羅傑 任健）
這個作業的要求在哪裡
我在這個課程的目标是	初步掌握軟體開發技術
這個作業在哪個具體方面幫到我	對本學期軟體工程的學習經曆進行思考與總結
提問部落格	個人閱讀作業2

提問與思考

注：斜體字為提問部落格中的問題

Q1：結對程式設計中如何選擇搭檔

我認為結對程式設計中搭檔的選擇很重要，那麼選擇與自己能力互補的搭檔比較好還是與自己能力相近的搭檔比較好？

在結對程式設計中，因為有随時的複審和交流，程式各方面的品質取決于一對程式員中各方面水準較高的一位。（《建構之法》 4.5.2）

在提問部落格中我分析了能力互補的搭檔和能力相近的搭檔分别的優缺點，在結對程式設計的實踐中我認為我的搭檔是與我能力互補的。我的代碼風格不是很好，而我的隊友在這一方面做得非常出色，是以在一開始我的隊友花費了很大的功夫幫我改代碼風格，為了之後的作業可以順利進行，我會學習隊友的代碼風格并且努力向他的代碼風格靠攏。我的隊友在一些算法設計上會有瑕疵，我在看他的代碼時會給他提出一些改進建議。

雖然沒有機會體驗與能力相近的搭檔一起結對程式設計，但是我對這個問題已經有了一些新的看法。與自己能力相近的搭檔合作，大家磨合起來會比較順利，但是隻能達到兩個人擅長的方面做得更好，不擅長的方面并不會有改進；與自己能力互補的搭檔合作，前期磨合需要花費很大的精力，但是兩個人可以互相修正對方的不足，減少項目的短闆，同時兩個人可以互相學習，對個人提升幫助很大。

是以，我覺得，如果是一個短期的、要求效率的結對項目，和與自己能力相近的搭檔在一起合作可以很快的默契起來完成項目；如果項目時間比較充分，那麼和與自己能力互補的搭檔在一起可以提高項目的品質，并且對自己也有一定的提升。

Q2：靈活團隊中的測試人員的作用

了解到在靈活團隊中，隊員的工作内容與傳統團隊有較大的不同，書中對Scrum Master和開發人員介紹得很詳細，是以我對測試人員的工作還有一些疑問。

以前規格說明書由PM來寫，測試由測試人員來做，現在每個人都全面負責，自己搞定規格說明書，和别人溝通，同時自己搞定測試。（《建構之法》 6.3）

有靈活專家建議測試人員可以擔負起産品負責人的部分責任，同時掌握驗收測試流程，對産品的最終品質負責。（《建構之法》 6.2）

從這兩段話，可以看出在靈活開發中測試人員主要工作是在沖刺驗收期，那麼在靈活開發的初期和中期，測試人員需要做哪些工作？靈活團隊中的測試人員與傳統團隊中的測試人員有什麼差別？

在我們的團隊中，沒有專門的測試人員，而是由後端開發人員同時編寫，并且我們團隊的開發模式是一邊開發一邊測試和修改，而不是像傳統團隊開發後期由測試人員進行測試。這樣做一個是可以投入更多的人員在開發上，而開發人員對代碼更加熟悉，更容易編寫測試代碼，這樣可以提高整個流程的效率，更加能展現靈活開發的要求；另一個是在開發中可以及時糾正錯誤，減小了因為錯誤對前後端對接以及與該功能有關的其他功能子產品的影響，也避免了錯誤堆積造成修複難度過高等情況。是以，在靈活開發中開發人員搞定測試也是比較合理的。

Q3：如何平衡軟體産品的利益相關者之間的沖突

在《建構之法》8.2中介紹了很多軟體的利益相關方，每一方提出的需求和意見很有可能是有沖突的，書中并沒詳細說明如何平衡這些沖突。例如，客戶的需求是便宜好用的軟體，系統/應用內建商需要從軟體中牟利，兩者需求相悖。當軟體需要支付較高費用時，往往會出現盜版軟體、破解版軟體，反過來傷害了商家的利益。

可以看出，如果不能很好平衡各方的需求反而會對各方利益造成損害，那麼應該如何平衡各方需求的尺度，減少類似這種事件的發生呢？或者說，這種平衡應該視具體情況而定，那麼是否有一些需要遵循的标準呢？

有關這一點，在本學期的課程中并未涉及到，是以沒有新的思考。不過，在團隊項目中出現過需求多而時間少的沖突，我們團隊面對這樣的沖突是按照功能的重要程度先做重要的功能，後期時間不足的情況下會舍棄一些重要程度低的功能。我們對重要程度的定義是使用者越想要看到的功能優先級越高，對使用者體驗感影響越小的功能優先級越低。但是，在真實場景中肯定不能這麼随意地删減功能，那麼遇到這種情況的解決方法可能隻有PM盡力與甲方溝通和加班了。

Q4：“小強地獄”這種按照小強的數量判斷是否需要修複bug的評判标準是否合理

我們都是按優先級來進行的，開發新功能的優先級遠大于修複小強的。

如果開發人員的小強（Bug）數量超過一規定值，則此君被送入“小強地獄”，在地獄中，他唯一能按做的就是修複小強，直到小強數量低于此門檻值。（《建構之法》 11.5.5）

可以看出，“小強地獄”的唯一評判标準是小強的數量。我的了解是，數量不能成為判定是否必要修複小強的唯一标準，有一些bug會影響産品的總體運作，比如導緻測試人員不能測試一些相關的技術點，或是對其他人的開發流程産生影響，比如在思路、資料上對他人有誤導，我認為這些bug即使數量很少，也需要立即修複，否則會影響團隊中其他成員的進度。一些bug不會導緻嚴重的連鎖反應，可以考慮積攢起來，用一段時間集中修複，避免在修複bug和開發新功能之間來回橫跳，提高效率。

我們的團隊開發并沒有使用”小強地獄“這種規則，不過在團隊開發中的經曆讓我并不認同書中”開發新功能的優先級遠大于修複小強的“這句話。我們在開發中由于時間比較緊張，是以有一個bug因為對現有開發沒有造成影響是以沒有及時修複，而是帶着這個bug繼續開發，結果之後的功能暴露了這個bug，當我們再想去修複這個bug的時候，發現修複難度和工作量都比剛開始大很多。

由此看來，一些bug并不适宜積攢起來集中修複，“小強地獄”這種規則還是比較生硬的，單純憑借數量判斷開發人員是否需要修複bug很容易将那些對之後開發産生影響的bug漏掉，反而影響進度，雖然靈活開發強調開發的效率，但是從保證項目品質的角度來說，我并不認為開發新功能的優先級遠大于修複小強的。

Q5：公司的短期實習生應該怎麼培養

在項目開始之前, 有很多隊員還沒有接觸過程式設計語言（例如C#），導緻PM在配置設定任務時很難用時間來衡量，就拿寫一個Web Service這一子產品來說，一個熟練的程式員可能隻需要兩個小時，而對于初學者來說，就得先花兩天來了解Web Service的實作機制和原理。在有限時間的催促下，導緻一些緊急的任務不斷向高手集中，而初學者的任務越來越少。這時應該怎麼辦？ （《建構之法》 11.6）

IT行業是一個強調效率的行業，像假期這種短期的實習生，既不能讓其像老員工那樣高效的完成任務，花精力培養也不能給公司帶來什麼效益就實習結束了，是以短期實習生的處境挺尴尬的。也有很多公司幹脆不提供短期實習，實習時長至少都是3個月、6個月，平時課業繁重的同學可能隻有大四才有機會實習。那麼有什麼方法可以讓公司願意花精力培養這種短期實習生呢？

通過團隊項目以及中間的轉會，發現大家學習和上手一個項目的速度都很快，在實習中應該也可以快速上手項目。有關這種短期實習的問題确實比較沖突，我們能做的就是在平時多找機會鍛煉自己，面試前好好準備，在面試時展現出自己的能力，讓企業認為你有為他們創造價值的能力。

新的問題：轉會後如何快速上手？

在alpha和beta之間有個轉會，雖然我沒有經曆轉會，但是我想知道轉會後如何快速融入一個新的組，快速看懂這個組之前的龐大的代碼，以及快速學習和适應他們的代碼風格？

知識點學習

需求階段

需求階段學習用NABCD方法來分析需求。

需求分析對于沒有經驗的新手來說會比較抽象，往往隻會考慮到分析Need這個角度，導緻分析并不全面。NABCD法給我們了很好的指導方向，讓我們從需求、做法、好處、競争、傳遞五個角度來進行需求分析，我們可以更加全面的了解和分析自己的産品。

設計階段

設計階段需要産生詳盡的設計文檔。我們隊産生了功能規格說明書、技術規格說明書、資料庫設計文檔和原型圖等。通過參與這些設計文檔的編寫，知道了設計階段需要進行哪些工作，如何進行設計工作為之後的開發提高效率。

實作階段

• 技術上，React前端架構，Typescript語言等前端技術。
• 工具上，比如用swagger管理接口，CI/CD實作自動化測試，ESlint_fix自動修複代碼風格等，采用husky設定GitHook，實作每次commit時自動進行代碼格式的檢查和修複。
• 團隊合作上，學會了與前端負責人溝通，與PM溝通，與後端對接接口。

測試階段

前端可以從不同浏覽器核心及版本角度進行測試，後端可以進行單元測試，這兩個可以在開發過程中邊開發邊測試邊修改。對于整個産品進行壓力測試、場景測試等。

釋出階段

• 為了更能展現産品的價值，以及獲得更加有針對性的使用者回報，産品的釋出和推廣應該更加面對該産品的目标人群。
• 使用好的方式對産品進行宣傳可以達到事半功倍的效果，我們組做了對産品進行介紹的宣傳首頁，還有一些組做了宣傳視訊、宣傳推送等，這些都是非常值得學習的宣傳方式。

維護階段

維護階段已經經曆過測試階段，産品已經沒有明顯的bug，這時候應該針對釋出後的使用者回報以及實際營運情況對産品進行維護。這就需要設計使用者回報的管道以及監測産品使用情況的方法。我們在産品中提供了使用者回報功能，并且建立了使用者回報群，軟體監測方面使用定時器方法來監測活躍使用者數。

個人總結

個人項目

個人項目主要是完成了個人閱讀作業和案例分析作業。通過個人閱讀作業#1，閱讀了很多IT人的部落格，體會他們的經曆與思考，讓我對計算機這個專業，以及北航帶給我的教育都有了新的認識和思考。通過個人閱讀作業#2，我對靈活開發有了細緻的了解，其中學習到的許多理論知識在之後的結對程式設計和團隊項目中都對我起到了很大的幫助。同時，這次作業還引導我們練習CI/CD的使用，CI/CD也成為之後兩個項目中得力的工具。案例分析作業指導我從産品功能、市場等多個角度對産品進行分析，這也是我第一次深入且全面地對于産品進行評測、調研産品的背景以及市場情況，也為之後的團隊項目的産品的需求分析以及功能設計提供了思路。

結對程式設計

結對程式設計讓我體驗了全新的駕駛員-領航員的開發模式，我和我的隊友ljj的技能點差異挺大的，通過不斷的磨合慢慢找到了我們配合的方式。我也通過結對程式設計改變了一些我一直存在的問題，我的代碼風格一直比較随意，以前個人程式設計時不太能展現弊端，但是結對程式設計時我發現我這種随意的風格給我的隊友帶來了很大的困難，給我們的代碼整合以及疊代工作帶來了很大的麻煩，我意識到這個問題後及時與隊友溝通，在隊友的指導和幫助下我努力将我的代碼風格改為比較規範的形式。同時我也從我隊友的身上學到了許多，讓我感觸最深的是有一次我們始終找不到弱測的bug，當時已經臨近ddl，我已經是近乎放棄的心态了，但是是我隊友的堅持讓我們最終找出了bug，通過了弱測，這讓我很受鼓舞。

團隊項目

團隊項目讓我體驗了比較完整的需求分析、設計、實作、測試、釋出、維護的産品實作流程，通過整個團隊的合作與努力，我們實作了一個很有意義的項目—— 觀隅資料集可視化平台，我覺得非常有成就感。在團隊項目開發階段，我遇到了很多困難，比如沒有時間上手技術棧，隻能硬着頭皮一邊做一邊學；沖刺階段撞上考期，兩邊無法同時兼顧……但是我的隊友都非常nice！前端大佬lyl非常耐心的幫我debug，解答我的問題；PM允許我在考期那幾天減小工作量，考試結束後再補回。感謝我的隊友，讓我圓滿完成團隊項目的開發，也讓我感受到我們謎語人隊的團結與包容。