プロジェクトの概要
1.1プロジェクトの概要
コミュニティ管理システムは、最初のセットの分析を必要とします
第二に、個々の作業
2.1予備的作業
製造要件、文書によって調製レポート、インタフェースの文書書き込ま一部を製造するための責任は、データがグラフを流れます。
PS：教師データは、当社グループの図を流し最初の報告は、おそらくこれが私のハイライトの一つ（プラスアイテム）可能性があり、高い評価を与えましたか？
2.2後期作品
2.2.1全体
UIインターフェースフロントページの原因で、インタラクションロジックは、接続の動的相互作用のフロントエンドとバックエンドのデータ・インタフェースを担当するバックエンドインターフェース要件と提案された取引所、担当メンバーと、ROUTER設計をルーティングします。
私の仕事の一部2.2.2（特定）
個人管理部
コミュニティビュー：、すべての学校コミュニティを表示する詳細については、特定のコミュニティをクリックしてください。
協会詳細：表示情報化社会のスター、コミュニティ情報、コミュニティのイベントは、アプリケーションのフォームページに参加するためにジャンプする追加ボタンを提供し、最近のコミュニティ賞レコードを組織しました。
協会は、申込書に参加：アプリケーションやその他の情報を完了するための理由は、アプリケーションを送信し、送信ボタンをクリックしてください。
イベントは、表示：特定のイベントの詳細を表示するをクリックして、すべての活動が承認されている表示します。
マイコミュニティ：ショーのユーザーがすべてのコミュニティのリストを参照して、特定のページへの参加をクリックしてください。
マイコミュニティの詳細：このページは内部コミュニティ情報のメンバーを示しており、セキュリティ情報は会長によって発行されました。
コミュニティ管理部
承認のメンバー：リストのすべての申込書、申込書と申込書がまたは拒否、状態が変化する様子を示しています。
経営のメンバー：リスト社長のメンバーに加えて、コミュニティのすべてのメンバーが、プレイをクリックする
活動が適用されます：活動申込書を、承認を得るために、送信ボタンのクリックを記入します。
通知マネージャ：関数の追加と削除の多くは努力の重複に属しているため、発行されたすべての通知を表示、具体的な実用的なインタラクティブな機能はありません。
公開された予告：内部コミュニティの発表
会情報レビュー：このページはのみ達成される賞は、関数は非効率的な労働力を繰り返す所属変更、機能を追加達成する予定はありませんでした。
規制当局の承認セクション
公開された予告：予告の一部に同じ原理が、すべてのメンバーのための通知。
通知マネージャ：通知Managerの管理者のリリースでは、同じことがCRUD機能を実装していません。
ホーム個人情報セクション
ホーム：表示するユーザーアクティビティ、通知、コミュニティの数と、管理者によって発行された通知が表示されます。
個人情報：個人情報の表示は、CRUDの機能が実装されていません。
セクションのスクリーンショット
第三に、学習経験や提案
3.1経験
3.1.1技術的側面
ほとんどを再生するように、ソフトの仕事は素晴らしい仕事のためには、私は、フロントエンドの主要部分の一部を担当していVUE.jsが、特にこのコンポーネントライブラリーでは、この進歩的なJavaScriptフレームワークだけでなく、要素、UI VUEビルドを呼んでいます。最初は、私は回り道をたくさん取る、例えば、知識を学ぶための教育ビデオを鑑賞することを選択し、今では本当にあまりにも多くの不必要な時間を費やすが、ほとんど成功したいと思います。我々は最終的にサンプルプロジェクトを通じて、当社の学習ニーズを完了するために、二次開発に、より包括的なフロントエンドgithubのプロジェクトを決め、チームを選んだので、より学習の知識は、実際の戦闘に基づいている必要があります。また、我々はまた、フロントとリアのポストの間の通信データを学び、最後に取得し、特定の原則のない深い理解がありませんが、JSON形式を学習するだけでなく、私たちの知識を広げ、離れ放課後からも、より詳細な調査することができ。など最初から静的なページでもホワイトページルートをルーティングの基本原則は、動的バインディング、今だけのよう大雑把ある熟練した動的なページを準備すること、およびインタフェースを介してバックエンドのデータを処理することができ、要するに、この大きな仕事をするためにできること人々が恩恵を受ける。
3.1.2協力グループ
由于前期需求分析不够完善，导致后期前后端出现了分歧，比如对一个人能加入几个社团这一问题出现了争论，由于前端设计的时候是按照一人仅能加入一个社团进行设计的，而后端数据库设计时是一对多的，所以出现了一些问题，最后通过两者折中，一人可加入多个社团，但仅能是最多一个社团的社长，暂时解决了这个问题。所以前期的需求一定要详细，不在于功能要有多少，重要的是每个功能都足够详细，在后续开发过程中不会出现问题。
小组合作中，团队精神非常重要。例如当组内有个成员仅仅做了极小的工作量，势必会影响整个团队的进度，因此每个队员都要有团队精神，要定时完成自己负责的工作。组内考核是一个比较好的手段，这样可以公正的展现出每个成员的工作量，在最后的评分中也能够更加公正。
同样的，沟通也是非常重要的，成员之间不应该仅仅埋头干自己的工作，而是要与其他人探讨哪里需要改进，前后端的接口也需要通过沟通来编写，避免出错。
3.2 遗憾
由于时间紧，组员较少，因此许多计划功能未能实现，如财务管理相关的需求，前端也仅仅展示了web端，这对移动需求日益增大的现代社会显然是不够的。希望在以后的学习生活中能够更进一步。
3.3 建议
1.课本重点不是很明确，期末的考试有点慌，如果可以的话可以划些重点。
2.在大作业开始前可以提供一些样例供同学参考，比如说前几届学生项目需求的格式、每周的进度、最后的成果，通过参考前人的经验，后续的工作也能够更好的开展，不然一开始总会感觉一头雾水，不知如何下手。
3.其他都很好！