THU琴房預(yù)約項目終于告一段落了~~~~

以下是在軟工三課程項目——《THU琴房預(yù)約》的個人體會總結(jié)，結(jié)構(gòu)如下：

• 個人分工
• 編程總結(jié)
• 團隊合作
• 對軟件工程的思考
• 個人總結(jié)
• 課程建議

1. 個人分工

• 小組組員的任務(wù)分工
• 調(diào)研相關(guān)同類小程序
• 前端測試
• 負責(zé)小程序端邏輯實現(xiàn)
• 負責(zé)管理端（Vue）架構(gòu)實現(xiàn)（整體架構(gòu)，路由等）以及部分頁面（路由）實現(xiàn)
• 前端Travis部署
• 代碼分支管理及Wiki管理

2. 編程總結(jié)

（別問，問就是全棧開發(fā)）

• 首先一個好的設(shè)計方案勝過一切，如果開始的設(shè)計不好，之后實現(xiàn)具體的功能只會越來越窄，直到選擇重構(gòu)。

• 然后是盡量走出舒適區(qū)，我們小組鼓勵大家多踩坑，多了解其他技術(shù)，以及不能僅僅局限于自己需要實現(xiàn)的方向。如果業(yè)界有成熟的解決方案，一定比自己民科解法好；如果兩個人都了解數(shù)據(jù)庫，兩個人討論得出的結(jié)果一定比一個人好，如果兩個人都了解koa，遇到問題的時候聊一聊說不定省了幾個小時查資料。

• 多用管理工具，Git必不可少，項目開發(fā)部署工具比如Travis也很重要，單元測試更是如此，核心功能必須多次測試，數(shù)據(jù)庫的鎖也必須飽經(jīng)考驗（俗稱必加鎖+測鎖）。

• 前端開發(fā)速率基本低于后端開發(fā)速率，尤其是多前端時，后端的邏輯基本不需要變，但是前端卻需要重新寫很多東西，例如我們小程序端和Web管理端很多功能類似，前端需要些很多，但是后端基本重用函數(shù)就行。

3. 團隊合作

在一個項目的開發(fā)過程中，團隊合作真的很重要，整個項目從需求分析，數(shù)據(jù)庫設(shè)計，再到微信小程序和后端開發(fā)，最后到管理端的Web端開發(fā)，除了代碼量大，各種方面還需要仔細地考慮，一個人基本是不可能完成整個項目的。

因此，我覺得在團隊里面分工和互補十分重要。

• 分工對于一個團隊的開發(fā)效率影響非常大，如果分工不合理的話，不光影響進度，更會讓整個團隊混亂，大家都不知道該干什么，容易出現(xiàn)自己做的事情和別人沖突了或者兩邊實現(xiàn)不同導(dǎo)致重構(gòu)，由于在之前的微信搶票過程中，我們小組有一段時間出現(xiàn)了一些分工不太合理，比如兩個人實現(xiàn)同一塊功能，好在我們及時開了一次會，經(jīng)過大家的商討，最終也統(tǒng)一了意見。因此在琴房開始的時候，我們就非常明確每個人在代碼實現(xiàn)這一塊的大方向分工（前端邏輯，前端UI，后端邏輯，數(shù)據(jù)庫管理），之后我們只需要負責(zé)每個人規(guī)定（寫在git的interface.md等文件上）好各自向外的接口，之后整個團隊的開發(fā)效率就比開發(fā)微信搶票時的效率高多了。而且，分工好后對于代碼管理也很方便，容易定位到bug的出現(xiàn)原因。

• 此外，互補也非常重要。實際上我個人覺得互補是分工的基礎(chǔ)。因此，在開發(fā)過程中的每次分工，我覺得應(yīng)該考慮每個人擅長的方向和不擅長的方向，盡可能讓大家都在自己熟悉或者做得更好的方向開發(fā)。比如，在需求階段，我們分成兩批進行需求調(diào)研，一批進行用戶需求的調(diào)研，一批進行相關(guān)類似產(chǎn)品的調(diào)研，溝通能力強的成員進行用戶需求調(diào)研，最終用戶需求調(diào)研小組與琴房管理員和部分用戶進行了多次溝通，我們小組的需求方向瞬間就明確了許多。再比如，對于審美方面，我們小組的女生就比其余三個男生好許多，因此讓她負責(zé)UI設(shè)計和實現(xiàn)這一塊也是非常合理的，最終小程序的界面看起來還是非常不錯的（我個人覺得簡直超過了預(yù)期了）。但是做到互補地分工需要了解組員且經(jīng)常和大家溝通，好在我們小組經(jīng)常集體開發(fā)， 因此我們大家都較為了解各自擅長和熟悉的部分的。

最后，我印象非常深的有一次會議，我們小組在需求調(diào)研完畢后開了一次時長超過3個小時的會議，我們小組討論了整個項目的基本功能和擴展功能，整個系統(tǒng)的設(shè)計方案，以及迭代周期和分工。期間我們根據(jù)調(diào)研得到的結(jié)果在白板上設(shè)計整個系統(tǒng)架構(gòu)，大家一起想方法，最終定下了基本的系統(tǒng)設(shè)計方案，頓時感覺目標(biāo)清晰了許多。之后的開發(fā)過程雖然有些改動，但是基本都是按照這次會議定下的路線走的（僅有1-2次大改，原因是發(fā)現(xiàn)不合理的設(shè)計和不夠兼容擴展的功能）。

4. 對軟件工程的思考

• 工程開發(fā)流程非常重要，如果不是從需求分析，原型設(shè)計，迭代開發(fā)，測試，優(yōu)化等步驟來，而是想寫普通的大作業(yè)一樣，有了題目埋頭就開始干，最后無法實現(xiàn)一個較為成熟，功能完善且設(shè)計合理的項目的。

• 敏捷開發(fā)很重要，但是最初階段的設(shè)計也非常重要，絕對不能把希望寄托在迭代期間大改需求，大改系統(tǒng)設(shè)計。如果不是最初階段團隊對于問題的深入了解分析，是很難設(shè)計出好的系統(tǒng)原型的，之后的開發(fā)更不會很順利了。個人現(xiàn)在覺得瀑布模型開發(fā)的思路也值得借鑒。實際上，我覺得我們團隊在第一輪迭代開發(fā)初期類似于以瀑布模型開發(fā)，首先先完整全面地調(diào)查需求，然后設(shè)計，然后開始實現(xiàn)（如果這樣結(jié)束了項目就成了瀑布模型典例了），等我們實現(xiàn)了基本的功能后就開始敏捷開發(fā)。因為我們最開始的設(shè)計思路基于比較完全的需求調(diào)研，最后在敏捷開發(fā)過程中獲益良多，即使期間有新的需求（例如長期預(yù)約，校內(nèi)接口，藝術(shù)團等），我們都可以非常順利地將這些功能兼容到現(xiàn)有的系統(tǒng)中，如果我們一開始只是追求快速開始，快速搞出一個產(chǎn)品，而沒有經(jīng)過非常具體細致地調(diào)研分析，然后直接不斷在這個基礎(chǔ)上迭代，把希望寄托在不斷的迭代周期上，之后的開發(fā)可能沒有現(xiàn)在這樣順利。

• 代碼管理。一個工程必須有對應(yīng)的代碼管理工具，不必細說。

5. 個人總結(jié)

• 團隊開發(fā)必不可少
• 隊友都非常給力呀
• 分工合理是整個團隊運轉(zhuǎn)起來的必要條件
• 開發(fā)時盡量考慮兼容性和性能，否則之后改難受。
• 作為一個組長，有時還是挺有壓力的，主要是因為當(dāng)大家都不知道怎么選擇的時候，基本上是由組長做出決斷的。比如我們使用koa拒絕了Django，比如我們放棄賬號登陸系統(tǒng)，選擇用手機號，再比如時間粒度選擇10分鐘而不是1小時，用數(shù)字串存儲可用時間，web前端進行二次開發(fā)開源框架等。一些無關(guān)痛癢的決定還好，還有機會改回來，但是影響大的決定一經(jīng)做出就很難回頭了。如果出現(xiàn)大問題，整個團隊的心態(tài)和氛圍都會受到很大的影響的。但是最終的成就感非常大，感覺自己收獲也非常大，當(dāng)然也不僅僅是技術(shù)層面上的。

6. 課程建議

• 針對性較強的內(nèi)容可以適量少一些。比如好幾次課程都是和小程序開發(fā)相關(guān)，這對那些不是小程序開發(fā)的組來講也不太好。而且，像Vue，react等web前端框架講解就相對少一些，我覺得這些更加通用，可以適當(dāng)增加一些內(nèi)容。

• 希望有學(xué)長在開學(xué)初就來介紹介紹開發(fā)初期應(yīng)該準(zhǔn)備什么，有哪些坑，團隊?wèi)?yīng)該怎么樣運行。

• 數(shù)據(jù)庫課程似乎有些晚，如果可以的話，可以在系統(tǒng)設(shè)計原型階段之前講講數(shù)據(jù)庫可能更好。

• 微信搶票小組開發(fā)非常好，希望可以進一步擴展這種小組開發(fā)作業(yè)。