第3-6章做業彙總

第一題：本週的做業請參照此文：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html 制定本組項目的GitHub版本更新流程。--By林培文

    經過文檔的學習，咱們知道它需求是開發的起點，先有需求，然後有功能分支。功能開發完成後，該分支就合併到主分支，進而刪除該分支，即」功能驅動式開發」。首先，咱們先了解下三個流程的基本細節：
   Git Flow：項目長期存在兩個分支，Master和Develop，分別用於發佈及開發。該流程中，還存在短時間分支，進行功能開發、維護等。但不少項目持續發佈，此時維護兩個長期分支，維護開發較大。
    Github Flow：開發過程當中始終保存一個長期分支，即Master，一旦有新的需求，便從主分支中拉出新的分支，在Commit新功能後，發出pull request讓別人注意到你的修改，修改被接受後，Merge進Master。最後，刪除該分支。
    Gitlab Flow：一個用於倉庫管理系統的開源項目，其主要功能以下：代碼託管服務；訪問權限控制；問題跟蹤、bug的記錄、跟蹤和討論；Wiki，項目中一些相關的說明和文檔；代碼審查，能夠查看、評論代碼等。
經過對比以上三種方式，依據項目需求和現實狀況，小組最終決定在Android平臺上實現該項目。而且小組約定按照以下方式進行操做。

   首先，小組成員各自將代碼Clone到本地客戶端。
   而後，依據以下對應的工做流程操做：
     1.依據需求創建對應功能分支;
     2.對代碼進行修改;
     3.完成了某項功能，提交(commit，只是提交到本地代碼庫);
     4.pull request到Web端，讓別人看本身所作的更改，若是存在衝突，解決衝突後在pull request。
     5.小組成員檢查後，在Web端進行Merge。
   到目前爲止，本小組都是按照該方式進行開發，其結果以下：

 

第二題：制定本組的代碼規範、GitHub提交源碼的標準。--By梁旭暉

 　　在一個團隊裏，代碼規範是一件很重要的事情，由於團隊之中，夥伴之間可能須要看懂彼此的代碼，這個時候，代碼規範就顯得尤爲重要。

　　 1、代碼風格規範：

　　　　一、去除沒有用到的引用，避免由於類引用沒有使用而警告。

　　　　二、使用4個空格的tab鍵進行縮進。

　　　  三、條件，循環語句必須使用{}來包含操做，即使只有一句話。

　　　  四、條件，循環語句的{}上下要對齊，每一個「{」和「}」都獨佔一行。

　　　  五、不要把多條語句放在同一行上，即使是變量聲明，也最好另起一行。

　　　  六、已經廢棄的舊代碼請刪除，不要留註釋，註釋的只能是對於代碼的解釋。

　　　  七、命名要規範：

　　　　　　1）不容許使用漢語拼音命名。

　　　　　　2）儘可能少用縮寫，但若是用了，要明智地使用，且在整個工程中統一。

　　　　　　3）避免使用相似的名字，或者僅僅是大小寫不一樣的名字。

　　　　　　4）全局變量大寫。

　　　　　　5）不要使用沒有意義的名字，好比haha。

　　　　　　6）不要使用單個字母，好比x，y。

　　　　　　7）無心義的循環變量，能夠直接用 i，j，k等。

　　　　　　8）多個單詞拼接而成的變量名，後面的單詞，首字母大寫。

　　　　　　9）避免使用長的名字（小於 15 個字母是個好主意）。

　　　　八、註釋要規範：

　　　　　　1）代碼細節的註釋使用//，較長或者多行註釋使用/* */。

　　　　　　2）寫明類目的，藉口的目的。

　　　　　　3）對於比較複雜的函數，提供調用示例。

　　　　　　4）爲不容易理解的變量提供註釋。

　　　　　　5）異常拋出須要提供註釋。

　　　　　　6）代碼修改，提供註釋。

　　　　　　7）自定義函數的功能須要註釋

　　　　　　8）複雜註釋放在函數頭，針對一句的註釋放在句末。　　　　

　　2、代碼設計規範

　　　　一、若是一個功能要屢次使用，請把它封裝爲函數

　　　　二、針對接口編程，不針對具體類編程

　　　  三、一個類完成一個具體的功能，不要有太大的類，不要把不少功能都封裝在一個類中。

　　　  四、儘可能少用全局變量和局部靜態變量。

　　　  五、不要使用goto

　　　  六、非必要的狀況下，不要使用多態

　　　  七、非必要的狀況下，不要使用繼承。

　　　  八、函數的參數最好在5個之內。

　　　  九、一個函數的長度，最好在150行之內。

　　　  十、布爾表達式內的條件在3個之內

　　　  十一、if 嵌套3層之內

　　　  十二、不要省略返回值的類型，能夠用void

　　　  1三、函數的返回值要和聲明類型同樣，不要依賴於自動轉換。

　　　  1四、傳入函數的參數，函數內部要驗證其正確性，不能默認用戶傳入的都是正確的參數。　　　　　　

 

　　參考文獻：http://blog.chinaunix.net/uid-9354-id-2425025.html

　　　　　　　http://blog.csdn.net/kimylrong/article/details/7700311

　　　　　　  http://www.docin.com/p-655201628.html

　　　　　　  http://wenku.baidu.com/view/8b03b3ff0242a8956bece430.html

　　　　　　  https://www.douban.com/note/82618786/

第三題：組長組織每週例會（可使用羣微信羣試驗一下天天溝通項目開發進度的方法）須要有證據可以在博客上公佈。--By郭青雲

　　咱們組的小夥伴們在接到每週的做業後，不管是在線上仍是線下都積極參與了討論哦。小夥伴們還熱情地爲項目的開發提出了不少頗有用的提議，由於線上討論的截圖太多，因此這裏決定只選取每週討論內容的四張截圖放在了下面^_^.

　　第一週：第一週做業任務

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 　　第二週：第二週做業任務

 

 

　　第三週：項目需求討論

 

第四題：根據鄒欣老師的教材相關內容，肯定小組成員的角色，細化項目需求、時間計劃、列出產品積壓工做項和預計開發時間。--By侯偉婷

　　通過和小組成員的討論，咱們肯定了有關小組成員角色、項目需求、時間計劃等事項。

　　根據以前的項目經驗和各項技術的熟練程度，咱們小組的角色分工以下。

 　　　　　　　　　　　　表格1 角色分工

成員	角色分工
林培文	工程師、UI設計，前端開發
郭青雲	工程師、系統後臺框架設計、接口設計
梁旭暉	工程師、需求分析、後臺維護
侯偉婷	工程師、系統測試、編寫文檔、數據庫設計

　　提到項目需求的話，就要着重說明一下項目的功能性需求，咱們看到了上一屆完成的項目，大致思路是和他們一致的，就是給出必定的題目由用戶答題，用戶答題以後，後臺負責判斷答案的正確與否。可是咱們在此基礎上作出了以下拓展：

 　　　　　　　　　　　　表格2 項目功能細化與需求擴展

拓展功能	功能描述
年級選擇	按照小學具體狀況，共設置6個年級的題目，不一樣年級的學生選擇本年級的題目答題，並給出答對和答錯的題目數量。
題目要求	一次能夠批量給出100道以上的題目，並保存在文本文件中，而且保證題目不重複。
難度選擇	針對同一年級的學生水平也會高低不一樣這一狀況，咱們將爲用戶準備 自測水平的題目，以後根據用戶的水平層次來分配難易題目。
年級排行榜	爲了讓提升同窗們的學習動力，咱們還將設置年級排行榜，即咱們對同一年級學生的答題總題目，正確回答的總題目，答題速度等數據進行統計，利用上述數據做爲指標來進行排行，可讓同窗們看到其餘同窗的回答狀況，不斷向優秀的同窗學習！
每週競賽	設置每週一次的數學答題競賽，在良性競爭的比賽下，讓全部人的數學成績能夠逐步提高。

　　細化項目需求後，就要說一說對這個項目的時間安排了，通過咱們組的討論，至少要三週才能完成，且是在沒有其餘學科，沒有其餘課題或項目的影響下。其中至少須要兩週時間來進行界面的設計工做，同時後臺服務器框架搭建也須要一週，後臺的功能代碼按照模塊來並行進行的話，也會花一段時間。

　　預計開發時間在兩週以後，由於包花費一週時間進行需求分析，開發工具和環境的準備，同時正逢國慶節，因此大概會在兩週以後進行項目的開發工做。