消失了半個多月了啊，算算時間，好像確實有近個把月沒有好好的寫博客來了。我一直很想寫博客的，之前有老師問過寫博客的動力是什么。我想了想，我覺得可能是我比較喜歡看書吧，不管是專業書還是小說（好吧，我承認，對自己感興趣的書才會去收藏，閱讀），看多了總有股想自己寫寫的沖動。然而，並沒有足夠的能力和文筆寫出來。后來發現有博客這種要求並不是很嚴的東東，也就喜歡上了。
之前這段時間實在太忙了，好多並行任務擠到一個點上去了，也就忽略了博客了。好在，這段時間終於扛過去了，團隊沖刺的這段時間喜怒哀樂也經歷了很多：學習，敲代碼，找BUG，修BUG，和隊友討論，甚至還因為某些觀點不合和PM西瓜吵了幾次，總之，這段時間感觸多多，收獲多多。接下去的時間內應該可以擠出時間來寫博客了，把這段時間的感觸，收獲寫寫。
這篇就寫寫這次團隊沖刺的一些感悟吧。
1.站立式會議
這點還是有些東西可以寫的，本來我們團隊把每日站立式會議理解錯了，我們一開始是認為這次開會把任務發布下去，等稍微有些成果的時候再來開會總結，並繼續發布下次任務。因此，一開始我們是兩到三天開一次會，因為團隊成員可以說都是新手，前期用來學習的時間教多，能做出成果出來的較少。
后來才發現理解錯了每日會議的意義，每日站立式會議不僅僅只是匯報自己已完成的任務和接下去要做的事，以及自己碰到的困難。我覺得會議的重點再於讓團隊里各個成員都能清楚的知道團隊項目目前的進展；團隊各個成員進展；我是否需要先停下自己的任務，先去幫助隊友等等。而且，會議還是個討論項目的好機會，畢竟平時有問題基本都是QQ聯系，文字描述不好說清各種問題。
當然，更重要的就是要讓PM隨時掌控項目的進展，我這次做的只是個編程人員，PM西瓜每次開會前都會先整理一堆內容，辛苦了！
記得最深的一次站立式會議是說完會議主題之后的討論，那次的討論是關於數據處理的某個邏輯。之前有在每日沖刺博客上說過，附上鏈接：【Alpha】Daily Scrum Meeting第三次 。還好PM西瓜即使終止了爭論，過后西瓜又對爭論點詳細分析了下，這個問題也算是解決得不錯了。
2.Github工作方式
這點太有話寫了。畢竟還因為Github的工作方式跟西瓜大吵了一頓，不，是討論，討論！因為之前有過一次Git工具使用的作業，在那次作業多花了點時間琢磨，自認為已經算是掌握得差不多了（ㄒoㄒ我錯了）。
這事是這樣的，團隊項目就放在一個總倉庫里，我一開始的想法是，團隊成員都需要有直接push的權限。你說代碼是需要復審的，直接push不行。那好，我們建兩個分支，我們只push到dev上，dev到master上的合並由你來，這樣算是復審了吧。你說這樣要是不注意push錯會出問題的。這個簡單，不是有版本回退嘛（其實版本回退也不是那么好用的，血與淚的教訓）。你說github正確的團隊方式是需要通過pull request的。什么，pull request,那個不是給團隊外的人想做貢獻用的嗎，如果是你說的那樣，那還要Team這個干嘛，而且每次同步最新版都得clone不是特別麻煩嘛。（原諒我年輕不懂事，亂說話）······
跟西瓜的那些對話，現在都還記得特別清。當時，西瓜算是被我說服了吧。不，應該說我一直不同意西瓜的方式，西瓜只能暫時先采用我說的方式試試看。試看。看。。結果直接出大問題了！！！
當時項目剛起步，很多沒考慮清楚的，比如到底哪些文件不需要加入倉庫的，而且也沒跟隊員強調一定得Push到dev分支。結果，有一次，因為隊員的編碼不小心修改過了一些別人的代碼，而且是重要的代碼，然后還直接push到了master分支上面，加上事先項目沒設置好忽略文件，把工作空間也加入了倉庫，結果直接導致了程序的崩潰，根本連編譯都過不了，更不用說運行了。
經歷了這次大問題后，西瓜特意花了時間去查找和總結了Github的團隊工作方式，並花時間教會了我們怎么操作。這里也得感謝下劉乾（@SivilTaram）同學，他也給我們講解了一些。這次算是一次大大的教訓吧，不要太高估了自己，也不要總覺得自己的才是對的，嘗試去試下別人的說法，或許能更好的解決問題。還有，網上的資料並不是全對的，要懂得自己辨別！（那個誰，是誰寫的pull request是專門給團隊外的人使用的，我信了！我居然信了！！我還堅定不移的信了！！！）
最后，附上西瓜大大的團隊github教程,特別詳細的哦。GitHub團隊項目合作流程
3.編碼規范
從第一次學習的C語言時，老師就有強調說良好編碼風格的重要性了。如果只是自己寫的程序，或許還體驗不到，頂多是忘記了某些變量，某些方法的含義，但花點時間還是能想起來的，畢竟那是自己曾經敲過的。但，如果是團隊合作開發的項目。我只能說，那個誰，對，就是你，帶眼鏡的那個，你要是再敢試試用a來命名，我就。我就。。我就用a1來命名，沒錯，就用a1。看你還敢不敢。
這次我們團隊的編碼規范我覺得做得很不錯，當然最大的功勞應該是西瓜，編碼規范的文檔是由西瓜整理出來的。然后我們團隊特意花了一晚上的時間來討論編碼規范文檔的內容，規定了各種命名方式，注釋方式等等。
前期時，我是負責前端界面的編寫，因此我對各種控件的命名打的交道是最多的。剛開始編碼時還沒習慣過來，也還是隨便命名，后來發現，需要命名的控件太多了，有重復了，怎么辦啊！！這時才意識到原來編碼規范文檔不是一份用來交作業的文檔，是用來參考使用的。於是，開始按照着文檔里的各種規定來給控件命名。一開始經常有些規定忘記了，需要不斷的打開文檔查看，覺得有些麻煩。后來又意識到不是可以 Crtl + F 的嘛，這下查找也快多了。用着用着，時間久了就大概成了一種習慣了。
到了后期，我是直接把編碼規范文檔的鏈接放在桌面（編碼規范文檔放在github上排版更酷，更方面閱讀），如果是熟悉的規定，直接敲了。如果不確定，都習慣性的點擊鏈接，打開文檔，Crtl+F。我覺得編碼規范對我最大的幫助就是我命名的時候不再是隨便來了，以前我也很討厭一個命名要打那么長的字符，但現在，你單單給個tvName我都想削了你，這是tv什么Name,你好歹給詳細一點。
好吧，我還是得承認，雖然編碼規范的命名部分我學到了很多，但風格方面還是有自己的習慣，老是忘記要按照文檔來。比如文檔說注釋方法的注釋最好用/** */，但我實在不習慣，好多次還是直接使用//。但空行方面我做得還是不錯的，團隊里的那個誰，對，就是你，再敢時不時的空個四五行出來，我就。我就。。我就。。。恭喜你猜到我要說什么了，沒錯，我就空個八九行出來，看你還敢不敢。
最后，附上西瓜大大整理的編碼規范文檔，值得參考哦。編碼規范
4.框架使用
其實，框架用得好的話，可以省下不少功夫。但也不可以太過依賴框架。助教（@沉默的代碼）說過，如果離了框架就干不了事的在HR面前會大大減分哦。
這次的團隊項目引用了很多框架，打開build文件你會發現，dependencies那邊居然滿滿十來行代碼，如果你打算clone我們的項目試着跑起來的話，建議你先退出，重新進，然后去洗個澡，吃個蘋果，運氣好的話沒准就已經編譯完成。
其實，我一直不清楚，為什么我clone Github上面的項目到本地跑時，總是會一直卡在下載依賴包那邊，老半天都過不去。這次團隊項目也出現過這種情況，隊友引入了一個依賴包，我同步最新版，結果下載了二十幾分鍾，就是一直在下載，編譯過不了。后面退出，重新打開就自己好了，不知道為什么。以后有時間得好好研究下這個問題，Github上面的好東西可不少，要是都沒辦法跑起來的話，那損失也太多了。如果你知道怎么搞定，麻煩趕快告訴，我已經漏掉好幾個Github的干貨了。
好了，接下去開始寫寫團隊項目引入框架的坑。我覺得我就是助教說的那個離了框架就干不了事的人，怎么辦！！！我是負責前端界面的，到目前為止還沒寫過自定義控件（囧），都是引用的別人的框架。像什么側滑菜單啊，進度條啊，圓形圖片啊，彈窗啊，之類的。我都是在逛Github上面時，發現有好東西，就fork到自己那里，能用上更好了。其實，我也是算是個剛入門的安卓新手，很多自定義概念並不是很清楚它的原理，而且這次項目時間少，為了能在短時間內就能有成果出來，只能不斷網上查找別人寫好的框架拿來使用。但這有很大一個問題。
因為時間少，所以不斷的使用框架，同樣因為時間少，來不及深入了解框架，導致了我引入了很多可以說是有重復的框架。比如這個框架已經提供了彈出，按鈕等，但我還需要一個進度條，所以又引入了一個框架，結果新引入的框架不僅提供了進度條，還提供了彈出，按鈕等。所以，我已經想好了，等繼續學習安卓，能力夠了后一定要把這個團隊項目的界面再重新搞一遍，把不需要的刪掉，深入去學習框架，而不是像這次這樣為了能實現一個功能就引入一個框架。
最后，來個吐槽吧，引入了個afinal框架，結果發現不知道是自己對它了解不深，還是它提供的功能有限，好多思路用它都無法實現，最后氣得都想不睡覺了！！！附上隊友使用這個框架的體會。【Alpha】Daily Scrum Meeting第七次
5.代碼沖突
代碼沖突這塊算是家常便飯了，我就不信有哪個團隊合作開發沒碰到過代碼沖突的。（什么，有？！我聽不見，別跟我說）
合作開發中，就算分工得再模塊化，總還是會有那么些地方是相關聯的，也就是誰都會修改到的代碼塊。萬一，不幸的你們同時修改了，github又不能自動合並，沖突就來了。跟沖突打的交道多了，其實也就沒那么可怕了（當然，我說的是小沖突，大沖突別來找我，我也想躲這它，至從遇見過那么一次后我就怕了）。沖突有是有分類的，有的只是位置沖突，比如你把某個方法塊放到最后去了，但內容沒改。這點比較好解決。還有的就是對同一個地方進行了修改，這個就需要手工去判斷該刪掉哪個，該報存哪個，或者都保存。
其實，解決代碼沖突可以借助AS來，AS提供了人性化的界面操作，很方便解決沖突的。這段時間跟AS打的交道多了，突然發現其實AS提供了很多很實用的工具哦，后面看看有時間沒，單獨整理份博客出來，歡迎關注期待哦。
解決沖突這邊，git提供的版本管理其實也很有幫助，如果解決沖突到后面程序崩潰了，想退回版本可以用git，如果commit的記錄有很多無用信息，又不想push到github上面去，也就是不想要那個commit記錄，但回退版本的話代碼又會沒了，其實這些都可以解決，git就提供了多種回退方式，里面就有只撤銷commit記錄，代碼保持最新的的方式等等。所以說，那么火的工具自然有它火的理由，不要只是接觸過它就自認為自己已經掌握了，還有很多高級的用法等着去學。（不是在說我，不是在說我，不是在說我，三遍！！）
6.代碼質量
代碼質量這塊，哎，我都有點不好意思寫下去了。記得助教（@沉默的代碼）說過，初學時，為了能實現功能，怎么亂怎么來。怎么感覺還是在說我！！！怎么辦！！！
由於畢竟是剛接觸的安卓，看完大概的書完后就要用來寫出這么一個不像是Demo的項目出來了，壓力確實很大。代碼里面問題最大的就是重復量太多了！！還有就是相互之間的關聯太深了，用專業術語來說就是，耦合度太高了。什么意思，舉個簡單的例子，登陸用戶的身份有三種可以選擇，不同的身份對應登陸后的界面有所改變。實現時並沒有把身份單獨抽出來寫成靜態常量，而是直接在代碼需要的地方用""寫上去，比如"user_teacher"，這會導致一個什么情況，當我覺得這個命名不好，需要再修改下時，必須到所有有用到這個變量的地方手工修改一遍。
至於代碼重復量問題，很多都是直接復制粘貼的。這個界面有這個功能，這個控件，剛好另一個界面也都有，好，怎么實現，代碼直接復制粘貼過去，參數以及id修改下搞定。結果，項目里面很多地方全是重復的代碼，原諒我實在不會實現什么資源復用之類的。雖然自己在看代碼時，也有些不好意思了，但心里也漸漸有些想法了，想着以后如果要重構代碼時，哪些必須不能再重復，哎，要學的還是有很多的！
6.團隊沖刺總結反思
總的來說，這次的團隊沖刺收獲還是有的，雖然成果並沒有預期的那么好（理想總是美好的）。
棟哥說過，編碼前的文檔准備是為了編碼的方便，想想開發過程中，我有真的好好的去參照那些事前准備好的文檔嗎？編碼規范文檔應該符合要求了，畢竟時不時的查看；原型應該也有符合要求了，設計界面時都是參照着當初設計好的原型來做的，然后在基礎上稍作修改。哦，對，還有需求規格說明書文檔！我去，怎么就把這個重要的文檔給忘了！！棟哥不是說功能的實現要按照驗收驗證標准來的嗎，不要自認為某個簡單的控件簡單的功能不需要就不寫上去，要按照驗收驗證標准上的來！
這點確實是個不足的地方，想想當初為什么沒有按照需求規格說明書文檔來。我一開始是花了一周多的時間完成界面，然后開始參與業務邏輯的編寫，這個時候時間已經不多了，而且每天西瓜也都布置了具體的任務，具體到要實現哪部分的內容，雖然我並沒有參照着文檔來，或許西瓜就是參照着文檔來給我們分配的任務呢？當初確實有這樣的想法，所以才沒有去打開文檔。
還有另一個想法就是，驗收驗證標准自己也有參與書寫，因此編碼過程中總是自認為自己清楚的知道需要實現哪些，不需要再去翻看文檔。（怎么感覺我的自認為毛病很嚴重！！）還有最后一個想法就是，當初書寫驗收驗證標准的時候，不管是對系統的理解，還是知識上，經驗上都有所欠缺，然后實際編碼實現時才發現，有些功能並不需要實現，有些控件去掉的話界面會更好看。因此覺得文檔里的驗收驗證標准有很多並不成熟的要求，所以才不去參照着這個文檔來。
好了，先這些吧。等會還有課，最后附上我們項目的github地址，歡迎fork,不過代碼質量確實是有點不怎么好，還望您在吐槽的時候勿忘指教，Thanks!!! CourseManagement
7.程序演示
最后，附上程序的演示，些許細節有錯誤，不要在意哈。（(∩_∩)）
登陸演示
發布任務，導入文件，查看任務演示
導出文件演示
查看教師信息，修改教師信息，添加教師信息，導入教師表演示
個人信息查看，教師身份登錄演示
