M1/M2階段總結

• 以前提問的博客

問題解答

---

問題 1
關於代碼複審，複審者是否應該參與編碼？若是複審者也參與編碼的話，那麼不免任務量較多，但若是不參與編碼的話，工做分配的彷佛不太均衡。

咱們的團隊項目在M1和M2階段沒有刻意去作Code Review，只有在發現bug後纔會由你們一塊兒來進行debug。這個過程當中咱們也發現了不嚴格按照代碼規範來寫代碼會給調試bug帶來諸多不便。有時一段代碼連當時寫代碼的人都已經要花好長時間才能從新看懂，更不要說其餘人了。

根據個人瞭解，一些大公司對Code Review的要求很嚴。每一個程序員除了寫代碼，還要對相應的一段Code進行復審。據個人學長說他的代碼第一次Code Review的反饋結果中絕大多數都是針對代碼註釋的，甚至連英文註釋中的語法錯誤都指了出來。聽起來很恐怖。

問題2.
關於敏捷開發，敏捷開發的過程彷佛很混亂，它的需求彷佛常常會改變，這樣不就是沒有設計好就開始寫代碼？那麼不免遇到很大塊的代碼須要修改。

咱們在M2階段的開發中就遇到了這樣的問題。以前原定的開發計劃，因爲學校服務器的緣由而泡湯，只能放棄以前已經作了一半的討論區開發的工做。

可是在開始寫代碼以前仍是要有一個整體的設計，若是以後有改動，則要對相應的設計進行修改。

問題3
敏捷開發的過程在我看來僅適合一些小型的項目，大型項目中若是想應用的話會搞得一團糟，是否是呢？

經過詢問一些正在實習的同窗、學長，我發現目前的小型創業公司彷佛都採用了敏捷開發的項目，一些大公司其實也把工做分爲了一個個相對較小的項目組，每一個項目組或多或少的都會應用到敏捷開發的一些思路。

問題4
單元測試要求對一切輸入都有正確的輸出，不能依賴本身的其餘模塊的代碼，那麼這不免會使咱們傾向於把每個模塊都設計的很大，從而減小單元測試的壓力……該如何避免這種狀況？

這個問題如今看來彷佛沒有什麼意義。由於在寫代碼的時候根本不會考慮到單元測試的問題……因此你們在寫代碼的時候基本都是按照應有的邏輯來寫。作單元測試時也就只能正常作了。

問題5
結對編程，僅是指兩我的共用一臺電腦，一我的寫，一我的看嗎？兩我的進行任務分配，每人完成本身的任務，也是一種互補的編程形式，這算不算結對編程呢？

對於結對編程的定義，書上已經說得很清楚，兩我的進行任務分配，只能叫作「協做編程」，結對編程的重點在於兩我的同時完成一份code，從而使得代碼具備較高的正確率，減小一些沒必要要的錯誤。

新的問題

---

產生了一個新問題就是：在團隊的開發效率開始變低時，做爲PM應如何激勵團隊成員來保持開發熱情？是否應制定一系列的獎懲措施？這個問題在企業中或許很容易解決，可是做爲學生，同窗間彷佛很難去強行要求他人。

論文回顧

---

現在從新去閱讀那些文檔，我終於明白了，做爲一個項目的開發者，你首先要對本身的項目感興趣，以後才能作出漂亮的、有用的項目。若是本身都感到無聊，那麼項目的質量也可想而知。

此外，開發者應該常常與用戶進行交流，確切的知道用戶須要什麼，咱們才能針對用戶的需求進行改進。

固然，程序的健壯性更好有切實的保障。

我還從中看到了一句感受頗有意思的話：保持項目的簡單性。設計達到完美的時候，不是沒法再增長東西了，而是沒法再減小東西了。

我以爲目前的不少產品都能從這句話中學到不少。

知識點

---

• 需求： 在進行需求分析的過程當中，我學會了分析目標用戶、以及進行場景分析。經過問卷調查、投票等方式找到項目所要解決的核心問題。
• 設計： 在設計階段，我明白了API的重要性。
• 實現： 在項目的實現階段，我第一次經過github配置了milestonw、issues以及燃盡圖
• 測試： 在測試階段，我對場景測試、測試矩陣有了大致的瞭解。
• 發佈： 在發佈階段，我瞭解了產品發佈的流程。以及版本號的管理
• 維護： 經過用戶反饋，可讓咱們瞭解到產品存在的bug並進行維護。