軟工團隊 - 預則立&&他山之石

團隊任務計划

時間	人員	任務
10.23-10.29	張昭錫	初擬Android代碼規范
	李永盛	初擬PHP代碼規范
	劉晨瑤	初擬Git代碼規范
	劉晨瑤	組織對規范文檔的討論、修改完善規范文檔確定終板
	李永盛	服務器測試、框架搭建
	蘇偉鵬	學習項目的PHP框架
	陳龍江	學習Android測試工具的使用
	張昭錫、熊立強、陳龍江、胡俊欽、駱景昭	學習Android MVP模式、對照項目需求和原型界面學習Android控件
	李永盛、張昭錫、劉晨瑤	初步架構設計
	劉晨瑤	需求規格說明書終板
	劉晨瑤	完善原型設計
10.30-11.05	劉晨瑤	Alpha終板原型
	劉晨瑤	組織討論和修改架構設計
	陳龍江	編寫測試計划
	李永盛、劉晨瑤	接口設計文檔
	李永盛、蘇偉鵬、劉晨瑤	數據庫設計
11.06-11.16	劉晨瑤	組織每日站立式會議、把控項目進度
	張昭錫	Android MVP模式框架搭建
	張昭錫、熊立強、胡俊欽、駱景昭	Android客戶端編碼
	陳龍江	客戶端測試
	李永盛、蘇偉鵬	服務器端編碼
	李永盛	服務器端測試
11.17-11.19	李永盛、張昭錫、熊立強、駱景昭、蘇偉鵬、胡俊欽	項目完善
	張昭錫、熊立強、胡俊欽、駱景昭	學習和初步實現推薦文章算法
	李永盛、蘇偉鵬	學習垃圾過濾算法
	劉晨瑤	收集用戶試用反饋，形成總結和改進方案
	陳龍江、劉晨瑤	測試計划改進
	劉晨瑤	Alpha階段總結
11.20-11.26	劉晨瑤	組織每日站立式會議、把控項目進度
	張昭錫、熊立強、胡俊欽、駱景昭	完善客戶端編碼、加入推薦算法
	陳龍江	客戶端測試
	李永盛、蘇偉鵬	完善服務器端編碼、加入垃圾過濾算法
	李永盛	服務器端測試
11.27-12.03	張昭錫、李永盛、駱景昭、蘇偉鵬、熊立強、胡俊欽	正式版本完善
	陳龍江	同時在線人數等壓力測試
	劉晨瑤、張昭錫、胡俊欽	撰寫用戶手冊
12.04-12.10	劉晨瑤、胡俊欽	撰寫宣傳文案和推廣
	劉晨瑤	發布正式版本、作出開發總結

細化后的issue：https://github.com/StardustProject/Stardust/issues

他山之石采訪記錄

采訪是的“一不小心就火了”隊，隊長逸超學長和我們團隊的個別成員認識，交流起來也相當的輕松愉快~

項目開發經驗

• Q： 我們有看到其他學長寫到，項目的開啟可以由一個比較有經驗的人把項目的架構寫好，然后再由其他人進行填充，但是負責安卓端的開發人員都沒有項目經驗，如何開啟一個項目？
  A：我們當時是寫着寫着就寫起來了，就我自己來說，安卓的話，到目前為止，整個項目的結構大概就是activity，adapter，請求代碼工具包之類的。具體的話，可以學一下MVP模式，嘗試一下。用這種方式的話，整個工程結構、層次肯定比較清晰，但是初期可能會碰壁，遇到很多坑。或者說你們也可以用自己的一套規定。​

• Q： 關於接口方面，有什么建議，需要團隊一起制定嗎？
  A：接口的話，至於是不是一起定義，如果其他人都不熟悉的話，由熟悉的人一個人來定義也是可以的。另外，接口文檔要寫好，記錄工具的話就不要再用word了，我們自己的經驗就是后期文檔太亂，多使用協同工具，apizza可以嘗試使用一下。

• Q： Android客戶端和后台PHP端有使用什么框架嗎？
  A： Android端的話好像沒有。但是你們Android不是要做圖片，一般不自己寫，可以用glide，網絡請求庫的話，現在比較流行的是Retrofit+RxJava。PHP端我們當時用的是ThinkPHP的框架，當然做接口開發的話，也有很多輕量級框架可以用：Lumen、Slim。你們已經搭好的Laravel，比較傾向於全棧方向，屬於比較集成的，當然這些框架的選擇，只要你們覺得OK，都可以。

• Q： 我們對項目測試還沒有一個清晰的概念，學長能說說要如何測試及制定測試計划嗎？其中要注意一些什么嗎？測試是手動測試還是自動測試，如果是自動測試用的什么工具？
  A：當時的軟工項目上，我們沒有主要的項目測試人員，項目基本上沒有什么測試，寫過一個自動化測試測試過登錄界面，主要是對接口進行一些測試。你們要做的話，可以寫一些單元測試、自動化測試，對每一個功能函數進行測試。對於服務端接口的測試，通過堆棧發起請求去請求接口，進行壓力測試。目前暫時可以不考慮高並發問題，項目后期，對於這個問題，可以考慮限制流量方式來解決。

• Q: 看《構建之法》里面說到測試驅動功能，我在結對作業中使用的是測試先行的方式，結果編碼量和編碼時間都指數爆炸。學長是傾向於測試驅動功能呢還是先寫功能再測試？
  A: 一般我寫是先寫完再測試，好像不管是公司里面還是其他團隊都是這個樣子。

• Q: 整個Alpha階段只有10天，編碼時間相對緊。在這么短的時間內發布一個release版本，是一個什么概念？
  A: 建議的話就是，你們在做之前要把各自的工作給做好，分工要明確。因為我們之前做的話，最開始分工不明確，而且當時相比我們上一屆，4個人，他們人數更少。這種編碼的工作不是人越多寫得越快，因為你們還要解決各種沖突，包括代碼的沖突，還有隊員交流這些。所以這個就需要組長好好協調。

• Q: 團隊成員基本沒有項目經驗，學長有沒有什么建議？
  A: 這才是鍛煉啊！Android端，我的建議就是，learning by doing，就是你要這個功能，就去找，之后想深入了解的話，再去擴展。你們現在做的東西都是會去用而已，比如你們要去實現什么功能，就去把這個控件學一下怎么用，而后面如果要深挖的話，就不是只是會用的程度了，要去了解底層是怎么實現的。所以你們這個階段沒做過什么是沒關系的，就是基本上要去學會怎么用，如果有興趣的話再去深挖。你要寫這個東西的話，最要看的就是，他整個邏輯是怎么傳遞的，如果你搞清楚了的話，順着那條路慢慢寫，最后肯定寫的出來。

團隊成員協作

• Q： 有出現團隊里某個隊友進度落后全團隊都在等的情況嗎？這時候怎么辦？
  A： 我們當時的服務端的接口都已經完成了，但是其實我們是在Alpha階段最后一天才開始對接口的。導致這個的原因主要也是分工不明確。分工模糊，我們那時候項目有四個端，很多東西是重復，比如查看結果是一樣的，后面對於重復的界面要用誰的，就炸了，誰也不服誰。

• Q： 學長們都說好基友千萬不要在一個團隊是為什么？是后期沖刺經常鬧矛盾嗎（個人能力導致代碼無法交付亦或是因為覺得他人寫的代碼“過丑”）？團隊情緒如何把控？
  A： 寫代碼就會有沖突嘛，主要大家要相互理解。我們當時Alpha階段，安卓端的開發人員就有三人發生沖突。每個人能力不一樣，掌握的技能也不一樣，走在前面的人可能需要等待剛開始起步的同伴，這時候就要耐心一點，當然，每個人手頭上有可能各種事情，在這種時候要表現出足夠的耐心也是比較難的。另外，各種規范要制定清楚，也能減少一些沖突的發生。對於團隊成員中代碼不優雅的情況（比如四個for），現階段對於你們團隊的情況可能比較次要，先把要做的功能做出來，保證功能能正常使用，標記tag，后期來進行產品的優化，因為你們團隊現階段最首要的任務就是如何在這么短的時間把你們的產品比較完整的做出來。

時間周期安排

• Q： 離第一次的Alpha版本發布只有一個月左右，學長們是怎么解決在這么緊的時間完成大部分的功能的？
  A： 其實你們不要太過緊張，完備規范，明確分工，注釋清晰（注釋一定要寫清楚！！），這樣就可以了。

• Q： 是否有發生在某一環項目的實際進度趕不上計划的情況，應該如何調整？
  A： 熬夜啊。
  Q：？？？

其他

• Q: 學長的項目分工的時候，為什么沒有一個負責測試的同學呢？
  A: 因為我們那個選導系統功能復雜項目太大，任務做不完，后面測試都比較水。接口是有測的，Android端這邊雖然測也是有測，但是單元測試做的就比較少，做了一個登陸界面的單元測試、自動化測試。測試這一塊，后面整合系統的時候也沒有怎么測。而且中間有個隊友去比賽了種種原因，后面分工要磨合很困難。而且有些人不熟，人手也不足，所以就沒有做很系統的測試。

• Q: 逸超學長是團隊的PM，但是在Alpha階段也參與了很多編碼工作，為什么？
  A: 其實貫穿整個過程，我的編碼工作還是挺多的。也是因為這個，導致后面整個組的分工也比較不明確。而且Alpha階段和Beta階段是不同人在管，后面磨合也出現一點問題。所以我給你們的建議就是，組長就不要參與編碼，專門管控整個項目就好了。你要的是別人完成得怎么樣，而不是你也直接參與。

• Q: 那所說的分工不明確是什么樣，比如說只分了誰去寫服務端，誰去寫客戶端，而沒有分具體誰到某一個模塊這種程度？
  A: 對。因為兩個人做不同模塊，后面協調起來，沖突會比較少一點。如果兩個人做同一個模塊，一來代碼會沖突，二來兩個人之間也要互相詢問對方的代碼。

• Q: 我看到有個學長的博客說到AS的git功能很好用，但后面他又說圖形化的界面雖然能提高效率，但根本的還是命令行，覺得命令行更好。git只是一個工具，如果用圖形界面開發效率更高的話，為什么要執着於命令行？
  A: 那些圖形界面，本質的話用到的還是命令行。但對於你們現階段的話，為了追求效率，為了完成作業，還是推薦使用圖形界面，就是AS自帶的git功能。但是你們學到后面的話，其實還是命令行比較好用。因為你選擇命令行的形式的話，你肯定對git了解更多更深，對於回退、合並、切換分支，你能知道他們具體的命令是什么樣子的。然后圖形界面的話，有個優點的話就是，你可以看到那條分支線，合並操作的話也很簡單。所以兩者各有優點，如果你會用命令行的話，你用圖形界面也肯定很好上手。最根本的還是命令行。

• Q: 我看到當時學長們軟工的commit注釋有類似“整合上屆代碼，氣煞我也，在里面發現了錯誤”、“隊友需要，改了返回數據格式”、“寫的快奔潰了，感謝產品不殺之恩Orz”，為什么長這樣的pull request也讓過了呢？學長們現在在公司做項目是否有一套固定的git規范？對於commit的注釋需要甚至詳細到操作了哪個類的什么函數嗎？
  A: 學長A：你回答，學長B：你是PM你回答，學長A：當時我們對於git基本沒有制定一定的規范，所以才導致了這個問題。對於git，可以給你們說說我最近的使用經歷。最開始肯定是提交一個最初的master， 然后從master拉出一個dev的分支，按照dev分支這條線，開發人員根據實際拉出一條feature分支，對於feature的命名規范 “版本_開發人員名字_功能描述”，測試好了，再merge到dev分支。

任務分配比例

劉晨瑤	李永盛	蘇偉鵬	張昭錫	駱景釗	胡俊欽	熊立強	陳龍江
20%	20%	5%	20%	10%	5%	5%	15%

反思&總結

在采訪學長之前，把他們隊伍的博客從第一篇起一直看到了最后一篇。看到每日站立式會議照片里的學長們從薄薄的短袖T恤一直到后來厚厚的羽絨服（其中一個學長正搓着手取暖），突然間即使還沒開始這段旅程就已經感慨萬分。當然，其中也看到了學長們博客中體現出來的一些問題，都帶有疑慮的在采訪中問了這些不算太正兒八經的不解之處。比如為什么任務分配中沒有測試人員、為什么commit注釋千奇百怪、為什么Alpha階段結束后54張issue卡片還剩下多達12張...雖然問題本身看起來有點不是太友好qwq，但正是通過這些得知了一些非常真實的感受和真實的情況，包括后來還問了不少技術上的問題，太多很細致的問題就沒有一一在上文列出，總之受益匪淺。

以及一些自己的反思。問了自己很多次，為什么所有任務無論多早開始，都會在deadline的最后一秒甚至后一秒后兩秒后三秒完成？這個千古難題其實之前在線下就問了學長，學長的回答是安啦，都是常態。但是屢次如此，還是覺得有點難受。

---

聽說逸超學長去了美團，然而接受采訪的時候身上穿的還是美圖的文化衫 （逃