How to Contribute

1. Issueを自分にアサインする
   • 他の人と作業が被るのを防ぐ
2. 手元に最新のdevelopブランチをpullする
3. ブランチを作る
4. コード書く
5. 見て欲しいタイミングでPRを書く
   • 「この方向であってますか?」
   • 「ここどうすればいいですか?」
   • 「できました!」
6. 見て欲しい人をReviewerにする
   • 急ぎならSlackでメンションする
   • （見て欲しい人というのはもともとそこを実装した人とかの事を指す）

APIを作る上で気をつけること

1. 文字数制限について

問題文・解答・お知らせなどの文字数は全て統一されている 文字数の上限は text_size_limit でUIに伝えてテキストフィールドに表示されるようになっている。 カラム毎にリミットを変えると上記の仕組みがややこしくなるので統一している。

2. アクセス制限について

情報へのアクセス制限を簡素にするため3つの取り組みがされている

1. 基本的に未ログインでは一切の情報にアクセスできない
2. 基本的にデータへのアクセス制限はreadable.rbに集約されている
3. 基本的にデータの追加・更新・削除はacl.rbに集約されている

具体的には

• GraphQLのQueryで値を返す際は Notice.readables(team: self.current_team!)
• Mutationの実行時は適切な位置で Acl.permit!(mutation: self, args: {})
• Mutationの戻り地は notice.readable(team: self.current_team!)
• 削除系のMutationの戻り地は少々特殊で notice.filter_columns(team: self.current_team!)

UIを作る上で気をつけること

1. nilなのか0なのか
   • e.g. 未回答なら'---'と表示し、0点解答なら'0'と表示するべき
2. JSでa.b.cの用にネストした値を扱う時、途中のオブジェクトがnilな可能性は無いか
   • Elvisオペレーターが欲しい...
3. デフォルト値は最適か?
   • e.g. 質問一覧は状態によってフィルタできるようになっている。この場合デフォルトでは未解決と対応中のもののみ表示するべき
4. 表示順序は最適か?
   • 並び順に意味があるなら、APIから取得した順ではなく必ず明示的にソートする
   • IDでソートしない
   • APIから取得したデータの順序は未定義(仕様)
   • e.g. 解答一覧では解答を提出時間が古い順で並べるべき
5. その値は決め打ちでいいのか?
   • e.g. 問題一覧ページの上部には採点遅延が20分と決め打ちでハードコートされていたが、これはAPIから取得できるようにするべき
6. 文章入力中にリロードしても大丈夫か?
   • 解答入力中に誤ってリロードしたらショックで寝込むかもしれない
7. 操作確認UIが無くて大丈夫か?
   • e.g. 削除時に「本当に削除しますか」
   • e.g. 解答送信前にプレビュー表示
8. ユーザーの想定外の動作をしないか
9. ユーザーに誤解を与えないか