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

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

• 個(gè)人分工
• 編程總結(jié)
• 團(tuán)隊(duì)合作
• 對(duì)軟件工程的思考
• 個(gè)人總結(jié)
• 課程建議

1. 個(gè)人分工

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

2. 編程總結(jié)

（別問(wèn)萨咕，問(wèn)就是全棧開(kāi)發(fā)）

• 首先一個(gè)好的設(shè)計(jì)方案勝過(guò)一切，如果開(kāi)始的設(shè)計(jì)不好叠艳，之后實(shí)現(xiàn)具體的功能只會(huì)越來(lái)越窄徐矩，直到選擇重構(gòu)掐隐。

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

• 多用管理工具厉颤，Git必不可少，項(xiàng)目開(kāi)發(fā)部署工具比如Travis也很重要凡简，單元測(cè)試更是如此逼友，核心功能必須多次測(cè)試，數(shù)據(jù)庫(kù)的鎖也必須飽經(jīng)考驗(yàn)（俗稱(chēng)必加鎖+測(cè)鎖）秤涩。

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

3. 團(tuán)隊(duì)合作

在一個(gè)項(xiàng)目的開(kāi)發(fā)過(guò)程中津畸，團(tuán)隊(duì)合作真的很重要振定，整個(gè)項(xiàng)目從需求分析，數(shù)據(jù)庫(kù)設(shè)計(jì)肉拓，再到微信小程序和后端開(kāi)發(fā)后频，最后到管理端的Web端開(kāi)發(fā)，除了代碼量大暖途，各種方面還需要仔細(xì)地考慮卑惜，一個(gè)人基本是不可能完成整個(gè)項(xiàng)目的。

因此驻售，我覺(jué)得在團(tuán)隊(duì)里面分工和互補(bǔ)十分重要露久。

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

• 此外，互補(bǔ)也非常重要吃靠。實(shí)際上我個(gè)人覺(jué)得互補(bǔ)是分工的基礎(chǔ)硫眨。因此，在開(kāi)發(fā)過(guò)程中的每次分工巢块，我覺(jué)得應(yīng)該考慮每個(gè)人擅長(zhǎng)的方向和不擅長(zhǎng)的方向礁阁，盡可能讓大家都在自己熟悉或者做得更好的方向開(kāi)發(fā)。比如族奢，在需求階段姥闭，我們分成兩批進(jìn)行需求調(diào)研，一批進(jìn)行用戶(hù)需求的調(diào)研越走，一批進(jìn)行相關(guān)類(lèi)似產(chǎn)品的調(diào)研棚品，溝通能力強(qiáng)的成員進(jìn)行用戶(hù)需求調(diào)研，最終用戶(hù)需求調(diào)研小組與琴房管理員和部分用戶(hù)進(jìn)行了多次溝通廊敌，我們小組的需求方向瞬間就明確了許多铜跑。再比如，對(duì)于審美方面骡澈，我們小組的女生就比其余三個(gè)男生好許多锅纺，因此讓她負(fù)責(zé)UI設(shè)計(jì)和實(shí)現(xiàn)這一塊也是非常合理的，最終小程序的界面看起來(lái)還是非常不錯(cuò)的（我個(gè)人覺(jué)得簡(jiǎn)直超過(guò)了預(yù)期了）肋殴。但是做到互補(bǔ)地分工需要了解組員且經(jīng)常和大家溝通伞广，好在我們小組經(jīng)常集體開(kāi)發(fā)拣帽， 因此我們大家都較為了解各自擅長(zhǎng)和熟悉的部分的。

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

4. 對(duì)軟件工程的思考

• 工程開(kāi)發(fā)流程非常重要券敌，如果不是從需求分析空闲，原型設(shè)計(jì)薪鹦，迭代開(kāi)發(fā)扁达，測(cè)試正卧，優(yōu)化等步驟來(lái)，而是想寫(xiě)普通的大作業(yè)一樣跪解，有了題目埋頭就開(kāi)始干炉旷，最后無(wú)法實(shí)現(xiàn)一個(gè)較為成熟，功能完善且設(shè)計(jì)合理的項(xiàng)目的叉讥。

• 敏捷開(kāi)發(fā)很重要窘行，但是最初階段的設(shè)計(jì)也非常重要，絕對(duì)不能把希望寄托在迭代期間大改需求图仓，大改系統(tǒng)設(shè)計(jì)抽高。如果不是最初階段團(tuán)隊(duì)對(duì)于問(wèn)題的深入了解分析，是很難設(shè)計(jì)出好的系統(tǒng)原型的透绩，之后的開(kāi)發(fā)更不會(huì)很順利了。個(gè)人現(xiàn)在覺(jué)得瀑布模型開(kāi)發(fā)的思路也值得借鑒壁熄。實(shí)際上帚豪，我覺(jué)得我們團(tuán)隊(duì)在第一輪迭代開(kāi)發(fā)初期類(lèi)似于以瀑布模型開(kāi)發(fā)，首先先完整全面地調(diào)查需求草丧，然后設(shè)計(jì)狸臣，然后開(kāi)始實(shí)現(xiàn)（如果這樣結(jié)束了項(xiàng)目就成了瀑布模型典例了），等我們實(shí)現(xiàn)了基本的功能后就開(kāi)始敏捷開(kāi)發(fā)昌执。因?yàn)槲覀冏铋_(kāi)始的設(shè)計(jì)思路基于比較完全的需求調(diào)研烛亦，最后在敏捷開(kāi)發(fā)過(guò)程中獲益良多诈泼，即使期間有新的需求（例如長(zhǎng)期預(yù)約，校內(nèi)接口煤禽，藝術(shù)團(tuán)等）铐达，我們都可以非常順利地將這些功能兼容到現(xiàn)有的系統(tǒng)中，如果我們一開(kāi)始只是追求快速開(kāi)始檬果，快速搞出一個(gè)產(chǎn)品瓮孙，而沒(méi)有經(jīng)過(guò)非常具體細(xì)致地調(diào)研分析，然后直接不斷在這個(gè)基礎(chǔ)上迭代选脊，把希望寄托在不斷的迭代周期上杭抠，之后的開(kāi)發(fā)可能沒(méi)有現(xiàn)在這樣順利。

• 代碼管理恳啥。一個(gè)工程必須有對(duì)應(yīng)的代碼管理工具偏灿，不必細(xì)說(shuō)。

5. 個(gè)人總結(jié)

• 團(tuán)隊(duì)開(kāi)發(fā)必不可少
• 隊(duì)友都非常給力呀
• 分工合理是整個(gè)團(tuán)隊(duì)運(yùn)轉(zhuǎn)起來(lái)的必要條件
• 開(kāi)發(fā)時(shí)盡量考慮兼容性和性能钝的，否則之后改難受翁垂。
• 作為一個(gè)組長(zhǎng)，有時(shí)還是挺有壓力的扁藕，主要是因?yàn)楫?dāng)大家都不知道怎么選擇的時(shí)候沮峡，基本上是由組長(zhǎng)做出決斷的。比如我們使用koa拒絕了Django亿柑，比如我們放棄賬號(hào)登陸系統(tǒng)邢疙，選擇用手機(jī)號(hào)，再比如時(shí)間粒度選擇10分鐘而不是1小時(shí)望薄，用數(shù)字串存儲(chǔ)可用時(shí)間疟游，web前端進(jìn)行二次開(kāi)發(fā)開(kāi)源框架等。一些無(wú)關(guān)痛癢的決定還好痕支，還有機(jī)會(huì)改回來(lái)颁虐，但是影響大的決定一經(jīng)做出就很難回頭了。如果出現(xiàn)大問(wèn)題卧须，整個(gè)團(tuán)隊(duì)的心態(tài)和氛圍都會(huì)受到很大的影響的另绩。但是最終的成就感非常大，感覺(jué)自己收獲也非常大花嘶，當(dāng)然也不僅僅是技術(shù)層面上的笋籽。

6. 課程建議

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

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

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

• 微信搶票小組開(kāi)發(fā)非常好楼熄，希望可以進(jìn)一步擴(kuò)展這種小組開(kāi)發(fā)作業(yè)忆绰。