一、解答自己提出的問題

結對程式設計總能做到1 + 1 > 2 嗎？教材中第四章出現了結對程式設計(Pair programming)，這是一種變態的程式碼複審，有別於傳統的Code Review。書中強調"複審的目的在於糾錯改進與教育更多的開發人員"，隨後在4.5.3節說到Pair中兩人對程式深入瞭解，複審效果好。但程式碼複審包括具體程式碼、效能、設計規範等多方面，Pair中有時間像Code Review一樣周全的考慮嗎？在傳授經驗這個方面，Pair中比較多的也是口頭交流吧，那麼有些經驗不就只停留在兩人之間了嗎？當開發想到一個新idea，為什麼不形成書面形式在Code Review中“讓更多的成員熟悉專案各部分的程式碼”？為什麼想著不間斷地複審而不去花時間提高團隊Code Review的效率？

結對程式設計的優點是可以進行實時的程式碼複審與交流，從而提高二人的工作效率,減少可能出現的bugs。在團隊開發中，相同分工的人員也適合以結對程式設計的形式進行開發，修復難以發現的漏洞時結對程式設計也往往能快速定位問題。而團隊內的程式碼複審可以讓成員對一份簽入程式碼從一致性、編碼風格、安全與冗餘等方面綜合監督，同時及時發現所用技術方案/框架的不足，減小試錯成本。相比於結對程式設計大量的面對面交流，程式碼複審還能自然地衍生出技術說明、API說明等文件，一份確定的程式碼規範不可或缺，一方面可以統一專案程式碼風格，另一方面也能提高團隊程式碼複審的效率。總之，在實際開發中是否進行結對程式設計，都需要從時間、工作重合度、成員相性等方面考量，靈活選擇開發的方式。

程式碼測試中覆蓋率要達到100%嗎？教材提到“100%的程式碼覆蓋率並不等同於100%的正確性”。從投入產出比的角度考慮，覆蓋率達到100%勢必要更多地考慮瑣碎的問題，覆蓋率不錯的情況下邊際收益豈不是下降了？100%的程式碼覆蓋率並不說明程式碼正確，我認為覆蓋率是一個基本指標，而不是目標。全覆蓋的測試不一定考慮全了外部的問題

程式碼覆蓋率是一個基本指標，而不是目標，也不能保證程式碼完全沒有問題。結對程式設計專案中雖然實現了較高的行覆蓋率，但分支覆蓋率與特殊輸入資料方面沒有做到儘可能完善，導致在評測中仍出現了一些問題。在實際團隊開發中，生產環境中的各種細節需要考慮，程式碼的效能，可靠性與可拓展性也很重要，軟體不是做到剛好可用的程度就行了，釋出前需要通過壓力測試、CI/CD自動化測試等手段保障質量。在生產環境中，可能遇到開發時難以察覺的問題，如資料的儲存安全與鑑權問題、遠端伺服器頻寬限制，因此無法全面考慮周全時，就需要開發組吃狗食或儘早釋出徵求使用者反饋，及時處理新問題。其次一個例子是多裝置適配的問題，無論WEB/移動端/小程式都可能遇到，團隊專案僅釋出於Android平臺，而Android裝置型號過多，在釋出軟體後，確實在部分機型上出現了解析度自適應、硬體效能不足的問題，軟體釋出前可以增加測試用裝置、使用WeTest等工具，以解決機型適配問題。

根據敏捷理論，對於執行原定計劃更傾向於響應變化，並與客戶合作。所以在衝刺中產生新的需求不應是常態嘛。真有重要變化時，為什麼不在Scrum Meeting中一齊討論此改動的重要性和急迫性再考慮進不進行工作上的調整？既然每次新的需求產生時都可能波及到系統中多個模組，或者是現在完全沒有考慮的優化方向，那麼有時重構不可避免，拖到Sprint結束會不會導致問題積壓，錯過重構的黃金時間，Sprint中的安排不可改變嗎？敏捷還強調個人和交流，這在小團隊很奏效，團隊規模大了以後難以保證高效的交流。而且相比傳統的軟體開發模式不重視正式的文件，這在團隊工作交接的時候會不會有困難，敏捷開發中怎麼將一個專案做大做長遠？

實際團隊專案中，只有兩次衝刺的工時，因此需要適當捨棄一些邊緣功能，儘可能接近開發計劃吧，比如考慮到開發時間與功能重要性，團隊軟體最終沒有實現好友、聊天等功能，但將精力投入在聯機遊戲這個核心功能之上。同時在β階段初期，為了實現聯機功能，及時花時間修改了原有程式碼，抽象出“玩家”實體，以防止衝刺階段中出現難以拓展程式碼的問題。敏捷開發中，很重要的一環就是在衝刺結束後根據使用者反饋及時調整計劃，修改需求，團隊開發中在β階段就根據反饋額外加入了教程等功能。

為了保證團隊工作的交接，首先程式碼本身需要有良的架構，不能內部過度耦合；其次要保證有必要的規範化的文件，如客戶端/服務端的介面說明文件，程式碼細節方面首先需要統一程式碼風格，否則接手者可能難以適應混亂的編碼方式；同時需要pydoc/jsdoc等格式化的註釋，方便快速上手程式碼。

寫不出好程式碼的PM是好PM嗎？既然PM要做其他的那麼多事情，那麼對TA的程式碼能力有要求嗎，要求多好呢？我認為PM應該做到的是對開發使用的技術路線與架構有個基本的認識，才能更合理地評估某一功能開發的難度，這樣可以避免異想天開的設計，也更方便與開發者交流。

PM也不一定需要對開發使用的技術路線與架構都很瞭解，有能力把握住團隊專案的全棧開發的要求太高了，所以我認為合適的團隊組織形式是根據開發方向固定經驗最多的一輛位成員作為技術顧問，並負責團隊的技術選型與程式碼架構設計。在課程團隊開發中，PM更不可代替的作用應是團隊開發計劃的制定、PUSH成員落實開發進度、及時協調成員間的工作。

創新不必是領域內專家，關鍵不必是技術？如果很多企業都只安於跟上主流技術，一味追求這些模式創新，怎麼解決相關市場的同質化問題？

軟體不一定需要通過技術創新成功，在團隊專案中，大家都是在做傳統的網際網路軟體，而且都是C端的軟體。因此軟體背後使用什麼技術，使用者很難關心，使用者的評價往往是依據實際使用中的直接反饋，因此團隊開發的重點是進行“模式”上的創新，應用現有的技術/框架去滿足使用者最重要的需求。沒有硬性指標，因此在開發中只需要實現安全、可靠的服務端，效能只需要滿足個體使用的需求，如解決伺服器頻寬限制、應對大量併發訪問等；開發中需要實現好用的客戶端，因為客戶端直接與客戶打交道，UI介面設計、互動流程設計、網路效能優化都是值得投入大量開發精力的模組。

同時團隊專案中開發的軟體為移動端遊戲，因此創新方面還涉及到遊戲機制的創新，這方面開發組沒有選擇獨立從頭設計一套遊戲機制，主要考慮到自定遊戲機制可能對玩家入門產生一定門檻，因此和廣大遊戲一樣，開發的遊戲基於多種遊戲玩法，對原有遊戲機制進行了細節上的修改與創新。

二、實踐中學到的知識點

首先需求分析階段需要通過問卷等調研方案獲得一定量的真實反饋，使用者需求很難是自己心中想當然的樣子，它需要資料來佐證。同時另一個重點是對現有競品的調查，找出自軟體拿得出手的差異化功能是必要的，表面的同質化會直接影響使用者使用的慾望。

對於一個萬行級的團隊專案，開發前的設計相當關鍵，如上文言，經過專門的程式碼架構設計才能把軟體功能模組化，拆分成可分配的任務。同時作為遊戲開發組，團隊專案中設計環節更加重要，遊戲機制上的變更難以預測，有時需要根據反饋修改遊戲底層邏輯，因此開發中的遊戲狀態機設計與遊戲執行指令碼需要解耦合，有良的可拓展性

開發中高效工作的關鍵是及時的溝通與合理利用Git等多人協作開發工具，我體會到了每日例會的重要性，小組成員可以在例會上找到開發的節奏，及時總結並找出現存問題。在測試方面，不但要做好客戶端/服務端的單元測試，也要綜合考慮軟體的安全性，如資料傳輸與儲存的加密。當然，團隊開發中，遊戲客戶端的多裝置適配與測試、服務端的壓力測試都是不可或缺的一環。

軟體釋出後，如果很難通過過硬的核心功能吸引長期使用者，則有必要通過各種宣發手段招徠使用者，即使是短時性的使用者，因此需要通過微信、產品主頁等方式積極進行宣傳。在維護方面，如果想把團隊專案長遠地做下去，那麼詳盡的文件是必要的，同時在迭代開發中，要充分考慮到軟體更新對舊版本的影響，在WEB開發中，介面地址的更改並無太大影響，但在Android平臺上已釋出的APP會遇到介面不可用的問題（如替換HTTP為HTTPS），這時就需要在代理閘道器處進行重定向，在不強制更新的情況下把對使用者使用的影響降至最低。

三、 專案經歷之中的心得