在**開始之前我們進行了詳細的需求分析，包括對老師課題的分析，理解思考老師課題中包含的需求資訊，畫出自己不太理解的或者有疑問的需求部分，然後統一的向老師諮詢，理解好需求，當然這不可能一下子理清楚需求，一有需求上的疑問，要自己理清思路，向老師問出自己的疑問。理清需求的同時，要分模組記錄要實現的功能模組，對要實現的功能要有全面詳細的認識並寫好記錄下來。
全面的認識好需求之後就可以進行資料庫方面的設計，資料庫方面我與同學先各自進行設計，然後進行了詳細的討論，包括需要建什麼表，每個表包括什麼字段，欄位用什麼型別，什麼長度，乙個乙個統一好意見，事實證明這是非常有用的，在後面的**編寫過程中，我們資料庫改變非常少，要改動也是討論一下，一下子就能達成一致的意見。
然後是介面設計，這部分我們開始時沒有選擇好前端框架，用的是bootstrap，但是不是用的官方的原版，而是用的老師給的已經修改過的其他版本的bootstrap，不是說那個版本不好，而是我們對bootstrap還不太熟悉，官方的有**可以直接系統性的了解這個bootstrap，用起來還有很多幫助的工具，老師給的則用起來一頭霧水。有時間可以好好學學bootstrap的使用，用熟了在試試老師給的那個，看看有沒有什麼好的方面。
最後是功能模組的詳細設計，這個部分我們做的不太好，首先是沒有進行詳細的功能實現上的討論，導致我們功能模組劃分的不夠細，很多功能模組中包含了重複的可以劃分的更細的小的功能模組，我覺得這個部分需要花大量的時間進行討論，包括重複功能模組的適當的劃分出來，重複功能模組的工作分配，功能模組實現前後順序的合理分配與調整。保證每個人對自己要做的部分有乙個詳細的認識後再進行各自的**編寫會大大提高效率和功能實現上的質量。
小團隊的適應與磨合
作者有兩次印象非常深刻的小團隊合作經歷，有幾點關於磨合的思考想分享出來。前期可能比專案本身更加重要。前期是個不太具體的說法，這裡想指的是，包括專案發掘，成員招募，團隊組建等內容。總之一切開始真正走入軟體工程生命週期的階段都歸屬於前期。1.1 專案內涵如何表述？專案分一二三等，這是個流傳挺廣的說法。但...
小團隊Git協作流程
git和svn 最大的差異在於git是分布式的管理方式而svn是集中式的管理方式。集中式 管理的核心是伺服器，所有開發者在開始coding之前必須從伺服器獲取 然後開發，最後解決衝突，提交。所有的版本資訊都放在伺服器上。基於集中式的 管理，完全依賴於 伺服器，如果是離線的情況下伺服器不能連線，那本地...
git團隊協作流程
開發者 開始工作前 git checkout master git pull git checkout b branchname 工作中 git add git commit m message 工作完畢 git push 管理者 自己寫 開始工作前 git checkout b branchnam...