---
# System prepended metadata

title: workspace

---

# 作業手順と開発規則

## hackMD email address

hackMDフリープランのメンバー上限が三人なので それぞれください
- tokyotechtotbe999@gmail.com
- marumarunekoneko0@gmail.com

## 分業

- マネージャー
    - 担当者: 中野
    - レポート作成, 進捗管理
- フロントエンド
    - 担当者: 乙部 石倉
        - サブ: 中野
    - ページ構成
        - リストと遷移
        - 必要な構造体の列挙
    - UI
        - デザイン
        - ヘッダー/フッター
        - ページ
- バックエンド
    - 担当者: 中川 平野
        - サブ: 
    - ユーザー
        - ログイン
        - 組織作成/管理/ユーザー管理
    - 要求物
        - 作成/編集/削除/購入
        - 品追加/品削除/購入数変更
        - タグ作成/タグ付け外し

### 割り振り - フロントエンド

- ベースデザイン決め
    - Figma

- ランディングページ　みんなで

- 新規アカウント作成　中野
- ログインページ　　　中野

- 組織選択　　　　　　石倉
- 組織作成　　　　　　石倉
- 組織ページ　　　　　石倉
- 組織編集　　　　　　石倉

・要求物ページ　　　　乙部

・商品ページ　　　　　乙部
・商品編集　　　　　　乙部
・商品作成　　　　　　乙部

・タグ作成　　　　　　中野
・タグ編集　　　　　　中野

・ヘッダー　　　　　　石倉
・ユーザーページ　　　中野 

### 割り振り - バックエンド

- init.build + docker
- domain
- service
    - user
    - org
    - need
    - item
    - tag
    - et al

## 進行

## 開発計画
- 12/16 ~ 12/18
    - フロントエンド: 画面デザイン案
    - バックエンド : データベースの作成・ルーティング
- 12/19 ~ 12/25
    - フロントエンド: 要求物ページ、商品ページ、作成（全般）、 ヘッダーフッター作成、組織一覧、ログイン、新規アカウント作成ページ、 
    - バックエンド : API 作成
- 12/26 ~ 1/4
    - フロントエンド: ユーザー、編集（全般）、要求物一覧
    - バックエンド : API 作成
- 1/5 ~ 1/8
    - フロントエンド:ランディングページ案持ち込み・決定、組織系（組織一覧除く）
    - バックエンド : API 作成
- 1/9 ~ 1/15
    - フロントエンド: 全画面作成 完成
    - バックエンド : API 作成・完成
    - 全体　:　 アプリケーション動作確認・デモ動画撮影
- 1/16 ~ 1/22 
    - 全体 : スライド作成

## フロント→バックへの依頼

- データベースのサンプルとAPI
    - 要求物一覧（商品一覧よりも優先）
    - 組織一覧（左側に表示するやつ）
    - 商品一覧＝要求物ページ
    - 商品ページ
    - 組織ページ

## gitの操作

### 自分のブランチにmainの変更を適用する

1. `git checkout main`
2. `git pull origin main`
3. `git checkout [branch name]`
4. `git merge main`

### commitするまでもない変更を置いといて別のブランチに行きたい

1. `git stash`
2. `git checkout [branch name]`

### 置いといた変更を取り戻したい

1. `git stash apply`


## リポジトリ規則

:::warning
main pushは緊急時以外禁止します
:::

:::info
issue-basedな開発をします 1-4をたくさん回してください
:::

### 開発の手順

0. 実装/修正/改善すべき事柄をissueにする
    - github
        - https://github.com/cs-sysimpl/sysdes01/issues
        1. 「New Issue」を押す
        2. 事柄を詳細に記載する
        3. 必要に応じてタグを付ける
            - ".frontend", ".backend"は選択必須
1. 自身が作業する対象となるissueの担当を自身に結び付ける {　|　}
    - github
        - https://github.com/cs-sysimpl/sysdes01/issues
        1. 既存のissueで自分がやりたいタスクを開く
        2. 「Assignee」に自身を割り振る
    - 理由:
        - assigneeを明示的に割り振らないと、「同時に同じissueを解決しようとして一方の作業が無駄になってしまった…」が発生しかねない
2. 自身の作業を行うbranchを作成 {　|　}
    - git command
        -  `git checkout -b [branch name]`
            -  OR `git branch [branch name]` -> `git checkout [branch name]`
    - 命名: `[特徴]/(#N_)[作業の内容]`
        - 分かりやすくする程度の効果しかないので、よく分かんなかったら従わなくていいです
        - issue番号を付けると、あとで自分がPullRequestを作る時に役立ちます
        - にほんごでもいいです
    - 命名例
        - `feat/#10_AddUser` issue#10になっているAddUserを実装(feature)する
        - `fix/usericon_not_visible` userのiconが表示されないバグを修正(fix)する
        - `improve/faster_need_searching` needの検索を高速化する機能の改善(improve)を入れる
        - など 特徴は適当でも良いです
3. 自身の作業branchに変更をコミット xN {　|　}
    - git command
        1. `git add .`(変更を全てステージ)
            - OR `git add [ファイル名]`(特定の変更をステージ)
        2. `git commit`(ステージした変更をコミットに)
            - OR `git commit [message]`(コメント入力エディタの表示をスキップ)
        3. `git push origin [branch name]`
    - コミットの頻度
        - コミットはtransitionみたいなものなので、commit単位で変更を打ち消すことが出来ます
        - 「変更の特徴を一つの動詞で表せる程度」で切るとヨシ
    - 命名: `[特徴]: 作業の内容` OR `[git emoji] [作業の内容]`
        - 分かりやすくする程度の効果しかないので、よく分かんなかったら従わなくていいです
        - にほんごでもいいです
    - 命名例
        - `feat: AddUser` AddUserAPIの実装
        - `fix: AddUser wont add column on db` AddUserがdbに列を追加しない問題を直した
        - `refactor: untangle complex code` 複雑化したコードを直し、「機能は変わらないコードへの改善」(refacor)をした
        - `add: app icon` リソースの追加を行った
        - `chore: fix typo` typoの修正みたいな何とも言えないその他の変更
        - gitemojiの使い方はググってください
    - 悪いコミット
        - 「機能追加と一緒に過去に自分が作ったコードの修正もした」=> 1コミットに詰め込み過ぎ
        - 「`fix: problem`」=> 何の修正か分からん
4. 自身のブランチをpull requestにする {　|　}
    - github
        - https://github.com/cs-sysimpl/sysdes01/pulls
        1. 「Create PullRequest」
        2. タイトルと説明文を書く
        3. 解決したissue番号を`resolves #[issue number]`と説明文内に記載する
            - 複数のissueを解決した場合は行を分ける事
        4. Reviewer依頼をする
        5. Reviewerから承認が来る
        6. Merge PullRequestを押す
    - 命名: 日本語でどういう変更をしたのか書く
    - 説明: どういう変更かをいい感じに書く