大作業--社團管理系統總結
附本組GitHub代碼鏈接：https://github.com/hkymygithub/ClubManage
一、我在這次大作業中的工作
1.與組長進行需求分析並記錄
2.根據組長寫的接口進行后端部分函數的編寫及其測試
ActivityManage：共計576行代碼（包含主函數中的各個測試）
……
由於篇幅要求，以下部分代碼省略：
AreaManage：共計188行代碼（包含主函數中的各個測試）
AttentionManage：共計212行代碼（包含主函數中的各個測試）
ClubManage：共計886行代碼（包含主函數中的各個測試）
CommentManage：共計138行代碼（包含主函數中的各個測試）
2.部分頁面的編寫
登錄注冊選擇頁面：
社團活動審核頁面：
活動創建頁面：
活動搜索頁面：
社團搜索頁面：
審核結果的頁面及與數據庫連接：
3.兩次會議的會議記錄
第一次會議記錄：
第三次會議記錄：
4.根據頁面編寫的需要進行后續的接口與函數的增加刪除和修改
5.部分測試數據的編寫（社團、部分活動、場地、部分活動申請、部分社團申請）
6.軟件測試（綠色為具體功能名，藍色為運行沒有出錯的部分，紅色為運行發現問題的部分，紫色為最后的解決方案）
普通學生功能部分：
社長功能部分：
管理員功能部分：
二、工作總結
在這次大作業過程中，我能明顯感覺到我的能力有了很大的提高。
首先是后端函數的編寫，與之前數據庫設計與開發的代碼編寫不同的是，在我寫代碼的過程中，需要考慮到更多的因素，比如我在編寫新建社團的這個函數的時候，並不只是在club這個表中添加一條數據就算完成了，首先，我需要在club這張表中找到當前最大的id，再加一設置為新社團的id，然后在club表中添加相關的記錄，還需要在area表中把該社團的場地設置為私有，並且在身份表中添加社長和管理員的兩條數據。可以說，一方面這鍛煉了我的編寫代碼的能力，另一方面也讓我能夠充分考慮這件事的相關因素，對我考慮事情全面性的能力也作出了考驗。把一件事情考慮周全，這是我們必須要有的能力，同時也是很難做到的能力，我們在日常生活中也是，或者是因為時間限制，或者是因為我們個人覺得麻煩，主動的放棄相關因素的思考，雖然這在當時可能沒有多大影響，但是這可能導致將來很大的錯誤，如果我不進行場地的設置，可能就會出現很多社團共用同一個場地的事情出現，這就很麻煩了。
然后是頁面的編寫，我一直對我的代碼編寫能力不夠自信，感覺稍微難一點的頁面我就完全編寫不出來，recycleview這種是我可望而不可即的，但是在后來，編寫完了活動審核頁面之后，我充分的感覺到了，沒有做不出的事情，只有不想去做的事情。萬事開頭難，在接到這個頁面的任務的時候，我完全不知道應該怎么下手，在組員的幫助和百度上大量資料的查詢后，我成功完成了這個頁面，這一方面 讓我感覺到了前所未有的成就感，一方面也激勵了我，我從寫一個有recycleview的頁面（一個頁面需要5個文件）需要一天時間，逐漸縮短，更能得心應手了（熟能生巧吧）。數據庫的連接也是同樣，做了才感覺自己確實可以。同時，頁面的布局也十分重要，畢竟頁面在實現功能的同時更需要美觀，於是我一開始使用墨刀的數據，后來發現墨刀的數據好像與實際顯示有出入，於是就開始微調，盡量接近預期的效果，減少后面人員的工作量，在這期間，細心和耐心就顯得極為重要。
由於我應該是我們小組最“文”的人了，所以我進行了會議記錄與文檔編寫工作。
軟件測試可以說是我最期待的環節了，一方面這宣告了我們的作業接近尾聲，一方面我可以和自己腦海中幻想出來的有奇特腦回路的用戶斗智斗勇，思考他們各種可能的操作（雖然考慮的可能還不夠完全）。畢竟第一次承擔測試的工作，我就以我自己對於測試的理解去進行了，首先各個功能的正常實現都走一遍，然后找找看會不會有那種“歪門邪道”的操作。
要說有什么遺憾，我覺得要是給我們多點時間我們可以更加的完善這個應用。我們在需求分析階段其實考慮過評論的實現等諸多功能，包括學生對活動的評論，管理員刪除評論等等的功能，為此我們還特地建了一個comment表來存放評論，也寫出了對應的函數代碼，后來發現要實現這些可能需要耗費過多的精力，就作罷了。
如果之后會有人做類似的項目，我有如下幾點的提示：
1.在開始的階段，不要着急寫頁面寫函數，需求確實很重要，定了需求之后，頁面、函數這種都只需要順水推舟，便能輕松解決。
2.關於需求，沒必要想的過於多，我們小組在討論需求階段，想過很多很多的功能，到后來我們組實現的功能其實就主要的幾個，有很多邊際化的功能沒時間去實現，所以重要的是能不能把重點的幾個功能實現好，而不是能不能做很多的功能。（關於需求分析，我們一開始也無從下手，然后現在覺得，就是，先定好有多少種身份，像我們的軟件就是，普通學生，社員，社長，管理員，然后根據每類人去寫他們能做什么，就是對應的功能）
3.在開始寫代碼的時候，感覺到不知道怎么做是很正常的事，畢竟每個人都有第一次嘗試，我們小組也是，我們大部分人都是第一次接觸android studio這個軟件，更別說用這個軟件寫頁面，這個時候千萬不能覺得自己不行，當你這么覺得的時候你就會把自己的能力束縛住，框定自己的能力范圍是很嚴重的事情，這種時候需要大量的搜集資料（查百度這種），不能怕麻煩就不去做，最終你得到自己想要的結果的時候會很有成就感。
附：我因為剛開始不會做，即使很簡單的問題都查百度了
4.編寫頁面的時候不能只實現功能就草草了事，“顏值”也同樣重要。最好專門找個人負責一下頁面的美觀，專人負責的話可以使得整個軟件的風格統一（當然，這個專人的審美最好好一點）。
5.每一次會議不能只是走個過場，會議需要知道當前的進度，以及討論出下個階段的任務，這個任務最好事落實到個人，這樣可以使得下個階段每個人都不會無所事事或者是不知道要干什么陷入混亂，這個任務還需要設置一下大概的優先度和先后順序，防止某個任務沒有完成導致整個項目的進度受到影響。同時，會議不一定要每隔固定時間進行一次，只要是在覺得有重要的事項需要討論（例如整個軟件很重要的部分出現了問題）的時候，都需要及時討論，集思廣益，盡快攻克這個難題，再進行接下來的工作。會議形式也可多樣，在幾句話能說清楚的情況下可以選擇群語音，比較需要一起看東西的時候可以線下會議。
6.測試環節千萬不能忽略，每個軟件作為新生兒，大概率會有大大小小的缺陷，這就需要測試員找出問題。我們一開始對我們的軟件信心滿滿，然后我在第一次測試的時候，發現了許多問題，改正就花了大半天時間，所以千萬不要覺得測試可有可無，對於一個真正的商業軟件而言，我們這種的小問題可能就很致命。
7.最重要的一點，小組成員之間一定要有足夠多的溝通，一方面你不會做的可能你的組員會做，如果你們兩邊同時在找同一個問題（當然，只是小的問題，不是那種超級難的問題，那種大難題，像是能決定整個組的進度的問題，最好是整個小組一起進行搜索），或者你不會的問題你的組員已經做好了的話，會造成時間上的浪費，另一方面，你需要與組員們實時溝通進度以確保你不會拖全隊進度。
三、課程建議
我覺得最好讓每個小組在會議之前先提交一份會議計划，寫一下本次會議需要討論哪些問題和會議流程（例如，首先總結目前進度，然后目前遇到的問題，然后下階段的任務，然后任務分配）。我感覺沒有討論目標的會議難免會有點亂，無論是發言針對什么或者是每個人需要干什么都不清楚，會導致會議的時間浪費在干瞪眼上，而有了計划書能有效的防止時間浪費，能讓會議有條不紊的進行下去，主線明確了，會議進行下去也就不會很亂了。同時，這也可以防止任務型會議的出現，讓小組是真正為了討論而進行會議而不是為了完成幾次例會而開會。