1、總結
初始---終焉
學習到的能力的預期&&總結
- 加深下對c#伺服器編碼的了解。 --- 雖然隻是加深了對移動端小規模的伺服器的了解，但個人還是挺滿意的。
- 争取能從頭好好學習一下c#語言。 --- 期中的時候買了一本一千多頁的c#進階程式設計，隻看了一百多頁，不過有跟着進行代碼練習。。。任重道遠。
- 若團隊打算采用Java編寫伺服器，希望也能學好java吧。 --- 在我的強烈要求下我們還是采用了asp.net web api 啊哈哈哈。
- 希望自己成為一個合格的程式猿。 --- 漸漸地發現碼農和程式猿的差別。碼農是隻要實作功能再苦再累也會機械化地敲完。而程式猿是考慮如何讓自己的代碼更有層次，如何讓自己寫起代碼更輕松。同樣任重道遠。
對項目課程的期望&&總結
- 雖然不是PM，但也希望能更好地整體把握整個項目，不過可能精力不足，說到底還是希望PM能夠梳理好整個團隊。 --- 我們組的PM雖然有時候會犯糊塗，但還是很靠譜的，不過希望他能夠自信些，強硬些，這樣對整個團隊的發展都是利大于弊的。
- 希望能學到更為規範的項目搭建過程。 --- 從之前的需求分析、原型設計到之後的編碼規範、環境選擇以及最後的兩次沖刺中，我深深地感受到了很多東西是代碼之外的，同時也是同樣甚至更重要的。
- 希望能寫好文檔。 --- 額，除了一開始有寫接口文檔和最後的測試文檔之外，我就沒寫過多少文檔，也沒有進行深度的學習也沒感覺有什麼鍛煉。不過，文檔很重要！隻是我不喜歡寫QAQ
- 希望能學好怎麼使用Github。 --- 項目一開始因為我們伺服器是我一個人包辦的，是以并沒有用github。不過後來因為老師要求，整蠱了兩三個小時把vs連接配接github弄懂了。然後現在看着上面的github記錄，感到深深的滿足感，我也算能基本使用github了，哈哈哈。
對項目的願景規劃&&總結
- 先定好題目，一個好題目是一切的起點。 --- 我最近一直在思考一個問題，是選擇重要還是努力重要，我現在更傾向于前者。（當然不能因為這個理由而輕視努力，隻有選對了，努力了，才能有所成就）選題目就是選擇，隻有選好了，之後的努力才有價值。我覺得我們的題目選得不錯，隻不過努力差了點，有些點沒做出來。
- 規範好團隊的編碼規範，使得代碼易讀。 --- 這一點我們團隊做的還是挺好的！
- 做好産品原型。 --- 産品原型很重要！我們産品原型中有一個跳轉邏輯有點問題，導緻後來android開發的童鞋都不明白之間的參數傳遞以及跳轉邏輯，耗費了一些時間。
- 希望大家編碼時能夠多交流。 --- 這點，我因為是一個人開發伺服器，而且其他組員用java，我用c#。并沒有多做交流
- 希望能克服一個又一個的八阿哥。 --- 克服不了也要克服，實在過不去，就用繞的！
- 希望能做出自己真正想做的東西。 --- 立項還不錯，技術差了些。
假如你所知道的是一個圓，那麼你以為你不知道的是圓的邊線，你真正不知道的是圓外的所有！
提升這種東西，提升之前我的直徑為1，以為自己所不知道的也就一個派，現在我的直徑為2，才知道我不知道的是兩個派，以及兩個派外的無垠。
- 學習了 Asp.Net Web Api架構以及其所蘊含的MVC思想。
- 學習了 WPF 架構以及其所蘊含的MVVM思想。
- 學習了 在Android以及Web Api 中實作 Http 通信，傳輸文字，圖檔和檔案。
- 學習了 雲伺服器的部署，VS的Web Deploy釋出，VS的Github的使用。
- 學習了 Postman的使用。
- 深入學習了 C#。
- 淺淺地學習了 Android開發。
- 學習并經曆了 一個産品從一個idea到成型的大緻過程。
- 代碼量大概 C# 3500行 XMAL 200行 js 200行 java 500行（xjb估的）。
2、人月神話
經驗總結
- 敲代碼之前得先多想想，不然到後面你會發現自己xjb寫了一堆沒什麼用的代碼。
- 一知半解的時候直接上手感覺會學得更快。當然要做東西的話，不能在試驗的代碼上直接擴充，要參照上一條。
- 溝通很重要。以沒時間為由對溝通不上心，到最後時間将會懲罰你們。
- 沖刺的時候，鍛煉很重要，每次敲到煩的時候我就去踢球，踢完球一身輕松，效率蹭蹭上。
- 當遇到技術難點的時候，不要一味地上網去找解決方法，然後copy代碼來嘗試，而應試着更了解技術難題的細節，并針對這些細節一一進行學習與思考。
執行個體分析
- 在實作Android端與Web Api的圖檔傳輸的時候我嘗試了很多種方法，但是由于沒有系統學習過Http通信，當時一下子要處理雙端的通信，一下子就蒙蔽了。然後開始百度，開始谷歌。一開始是直接找代碼，然後瘋狂貼代碼改代碼進行測試。。。後來花了兩天沒什麼進度，反倒是讓我對整個通信過程有了更深的了解。然後我花了半天，把Http通信的基礎以及雙端的主要函數學習了解了一下。花了半個下午去踢球，洗完澡坐在電腦前一會忽然發現Android可以模拟Http封包并以Multipart/Form-data方法進行傳輸，可以同時傳輸檔案和文字，然後Web Api用MultipartFileData 類進行接收。于是就過辣。
3、告諸往而知來者
以告來者
- 就像老師所希望的那樣，下一次希望學弟學妹們在開發過程中能得到更多潛在客戶的意見，進而做出真正讓客戶滿意的作品。
- 團隊的pm在協調好團隊的同時，也應該強硬點積極點，這影響到團隊中的氛圍。
- Github在團隊協作方面确實好用，建議在開始項目之前抽時間學習Github。
- 然後其實代碼量沒有那麼多，做好規劃，不會是多大的負擔，最怕就是拖延症。比如我，什麼熬夜通宵都是為之前還債罷了。為什麼會覺得熬夜比較有效率，因為你内心有對白天荒廢的愧疚感！
- 開始代碼前，每個組員都應該完全熟悉掌握産品原型。
誡己
- 效率！效率！熬夜對身體不好！PS.嘴上這麼說，你還不是熬夜在寫這篇文章？
- 做好時間規劃，不管是敲代碼還是學習，比如你現在要挂了你知道嗎？再不讀書，再逛Steam，再喜加一，你藥丸！
- 不要輕易放棄，放棄等于藥丸，内心低落也要逼一逼自己還債。還有一個禮拜就到連環七門考了，開心嗎？
4、606
關于606NotConnected這個名字
- 團隊名很明确，是關于6班的6位小夥伴之間的故事
- Http 的606狀态碼對應的是 Not Acceptable 不能被接受的。。。額這個名字貌似不好。而Not Connected确實也可以表達出606狀态碼的一些特性，同時也希望小夥伴們在編碼時能沉下心做到與外界Not Connected（額，好吧這是我掰的）
關于團隊
- 萌芽階段：大家都是老熟人也沒什麼拘謹的，隻是确實有些沒經驗的小夥伴會不敢于表達自己的意見。還記得開學初的幾次開會，看上去有模有樣的，但其實還是在輕松愉快的“展望”中過去了，恕我直言，效率有點底下。不過現在想想也是萌萌的。
- 磨合階段：整個項目下來，編碼壓力最大的是我們的Android用戶端的“主程”(以下簡稱為我舍友)，不僅要大量編碼，同時還要帶動一些沒有基礎的同學一起編碼，然後經常幫他們擦屁股。什麼？你問我？我一個人負責伺服器端，再寫點Android的通信檔案輕松自在，小規模編碼人多真不一定是好事。然後，在Alpha階段的最後一天晚上，還有很多問題(Alpha版本示範的時候我們貌似閃退了三次？)，我舍友都要抓狂了，整個心态爆炸的感覺，邊敲代碼還邊抱怨其他人拿過來的東西不滿足要求，還要改。然後，我就安慰他别着急，并坐在他旁邊看他編碼，心平氣和地，時間就到了四點半，然後睡三個小時上戰場！磨合階段，大沖突沒有，小摩擦也很少，大概我們組的童鞋都比較内向吧。老實說我們團隊在磨合期的處理并不妥當，犧牲了部分人，比如我舍友，他雖然沒和其他人起沖突，但是他确實因這磨合期而感覺到痛苦與疲憊。
- 規範階段: 開始Beta階段後，大家貌似找到了一種節奏，原本随和的PM也開始有了自信也更有力地監督着團隊的項目進度。是以我們Beta階段貌似沒有熬過夜。因為有了Alpha版本的雛形，大家也有了明确的目标。什麼第一版界面太醜？改！UI設計不好？換！大概是這種節奏，這種行動力挺高的節奏。
- 創造階段：不是很了解将注意力集中到如何創造是什麼樣的感覺。不過，高度自治貌似沒有做到，有時候還學要PM在尾巴後催促，大概是沒有到達這個階段吧。
5、EXM? English Disquisition？
PS.Sorry,My English is not better,so I maybe can't complete it great.
PS.考試将近我個人真的沒太多精力去通讀這麼長篇的英文論文，是以我選擇機翻。。。
Code quality analysis in open source software development
- 粗略地看完整篇的機翻，我忽然發現貌似隻有最後兩段與衡量自己的代碼品質有關？
- 本篇論文前半段都是對開源代碼以及開源元件進行的抽樣品質調查，而後公開結果，說所抽樣的開源結構化代碼品質高于反對開源的人的預期，但也低于普遍的工業化代碼的品質。然後就在讨論如何提高開源代碼品質？
- 怎麼說呢，開源已經是大趨勢，連固執如微軟，近年不嘛也把.Net開源了嘛。什麼Windows開源？夢裡想想就好。前兩年我第一次接觸Unity的時候，很多人拿它和Cocos2d相比，直言它不開源是最大的劣勢，然後最近我忽然發現Unity Pro版貌似開放源代碼了（隻不過要收費就是了）。而且我們在開發的時候也從開源社群中找到了Picasso這個開源元件，大大地幫助了我們開發，我不能不說開源真的很重要。隻是若商用項目大量使用開源元件，也是一個很大的隐患，是以這篇論文才一直在探索如何提高開源代碼的品質。
- 個人認為，以做項目為生的程式猿應該懂得站在巨人的肩膀上，做到幹淨利落地實作功能。是以對于項目的開發，開源項目真的是必須的。
- 個人感覺自己的代碼還是挺規範的，除了幾個地方備注少了點。然後代碼結構這個問題，因為我是根據架構來做的，并沒有太多自己的設計，要說有就是寫了幾個方法類，是以感覺還是差了些火候，特别是前些天複習了設計模式之後，才發現其中一些想法之巧妙。
6、進行時而非完成時
- 第一點。老實說，臨近期末真的沒辦法進行推廣，而且之前被試用使用者吐槽這并不是使用者級别的App，我們也意識到我們這款App的不足，短期也不會進行釋出到商店的嘗試。
- 第二點。第二點的證明我覺得我們在兩次沖刺階段的十七篇部落格就可作為資料證明。http://www.cnblogs.com/606notconnected/p/6044648.html
- 第三點。個人覺得自己寫的伺服器端因為是一個接口一個接口寫的，拓展維護什麼都很友善。這是github的位址: https://github.com/606notconnected
7、公主沉睡了，屠龍的勇士還在燃燒
我們的公主已然沉睡，屠龍的勇士到最後救出了公主，卻沒能讓她睜開眼。
開學初的部落格裡的自我介紹我就說了，我是一個玩心很重的人，什麼都想去嘗試。
但是，很多時候一顆安定的心比一顆躁動的心來得更為重要，是以我沒能做出一款真正使用者級的app，是以公主依然沉睡。
我之是以選擇就讀計算機系，是因為我有一顆想做遊戲的心。
當初年輕，不懂得路途的艱苦，隻有一腔熱血。現在了解得越來越多，但也改變不了我的信念。
我不是一個嚴格意義上的程式猿，因為我對數字不敏感，我更想做一個藝術型的程式猿。拿着數位闆畫着圖，打着打擊墊譜着曲，敲着鍵盤碼着代碼、寫着劇情，閑時看着動漫，聽着小曲，踢踢球，玩玩遊戲，和基友吹吹逼，這是我的理想生活。（什麼女朋友？心疼自己1s） 當然，畢竟是理想呀。
我希望我不是為了工作而生活，我是為了生活而工作。我希望我未來的工作是我真正感興趣的。足球？已經沒有多少可能性了。動漫？并不是藝術生。遊戲？不是當主播的料，嗯，我要成為遊戲開發者。
遊戲是門藝術。
隻是國内的遊戲公司有幾家是靜下心做遊戲的呢？感覺以後有經驗了，也要混迹于小作坊了，哈哈，生而自由。希望以後大家能看到一款遊戲的開發成員名單時，驚奇地說道：霧草？這是我軟工課上的同學？
哈哈，屠龍的勇士還在燃燒！至于龍屠了嗎？誰管呀。