原部落格連結
原問題1：有沒有系統的方法來提高一開始的文檔的設計後的品質呢
在之前的OO課程上，我已經深刻領會到了設計的重要性，而且在這次的團隊開發中，我也是負責從需求分析到代碼設計的轉換，是以對設計這個過程有一定的了解。
如果要我現在回答上面的問題，我覺得我會說，唯一的方法就是：多看書提高自己的水準，多實踐改正問題，多反思并不斷更新設計，才能提高設計的品質。而且這一切的前提我覺得是需求分析做的很充分。關于這一點，在下面的新問題中我會詳細闡述。
原問題2：在評判軟體的好壞時，是不是需要考慮軟體背後的成本來對軟體好壞進行評判呢？
這個問題老師已經給我做了解答，一定是需要綜合考慮各個因素評判好壞的
原問題3：對于沒有集體主義精神的人該如何管理呢？
管理是門很大的學問，不過還好在我們的團隊項目中，大家都是有責任心的。
新的了解和收獲
新收獲1：需求分析十分重要
我們的團隊開發是瀑布模式，即一部分人先制定遊戲的内容，然後我來把他們的遊戲内容轉化為代碼的設計，在設計好後，我們開始編寫代碼，一切看起來很和諧，但是如果考慮我們現有的時間成本就會發現這樣的模式并不可取。
假如遊戲内容設計人員花了一周時間制定了遊戲内容，然後設計人員花一周時間把他們的遊戲内容轉化為代碼設計，最後開發人員進行代碼的編寫再花一周。可以看到在内容設計人員設計遊戲内容的過程中，代碼設計人員和開發人員其實無事可做，而在代碼設計人員和開發人員開發時，遊戲設計人員又會沒有事情可做，這就好比一個單周期的CPU，同一時間隻有一個部件在工作，是以我一直在想能不能把這個模式轉化為類似流水線的模式？因為我們的開發時間其實挺短的，也就最多一個月時間，況且還有其他課程需要學習，開發時間短，任務重，瀑布模式雖然好，但是可能沒有那麼多時間順次的走完一個流程。
我嘗試在遊戲内容設計人員給我一部分内容後我就開始設計，設計好後就可以開始開發了，但是當他們把另外一部分内容設計給我的時候，我内心是拒絕的，因為如果要把他們的另外一部分内容加進來的話，需要改動之前的一些架構。雖然軟體開發講求可擴充性，但是還是會有一些擴充的方向是一開始沒有考慮到的，是以我們在β階段對α階段的改動是很大的，就是因為需求的改動太大了。
是以我個人認為，在瀑布模型中，需求分析是絕對不可以與其他階段并行的，需求分析是接下來所有階段的基礎。
新收獲2：架構選擇時，盡量選擇成熟的開發工具
這次我們做遊戲選擇的開發工具是一個新的編輯器，随着開發過程的深入，這個新編輯器逐漸的顯露了出它的一些缺點：
- 本身有一些bug
- 相關的技術文檔還不完善
- 技術社群的很多問題沒人解答
- 沒找到做單元測試的方法
- 遊戲場景檔案不能很好的支援github的沖突處理（場景檔案應該是自己生成的json格式的檔案，如果多人開發時有了沖突，會發現有幾百甚至上千處沖突需要合并，而且場景檔案的内容還不好了解），這就導緻多人合作開發成了問題
是以在選擇開發工具時，選擇成熟的，已經多個版本疊代的工具，才能減少開發的成本。
新收獲3：代碼規範真的很重要，而且代碼規範的嚴格遵守更重要
多人開發，每個人都有每個人的編碼習慣，如果沒有一個統一的規範遵守，會發現最後寫出來的代碼可讀性較差，也不利于接口之間的對接。
學習到的知識點
需求階段： NABCD模型，認真分析需求，而且要盡早做，做充分
設計階段：設計階段很重要，設計的好才能更好的分工合作
實作階段： 即使自己不負責測試，也不能說自己寫的代碼連測都不測，代碼的品質是自己保證的不是測試人員給你保證的
測試階段： 單元測試很重要，但是首先你在選擇架構時要選擇一個能做單元測試的
釋出階段： 不要以為釋出階段很簡單，把檔案打包一下上傳就好了。釋出要盡早做，因為可能有許多未知的事情，比如還要考慮稽核時間。
維護階段： 使用者回報很重要。