Skip to content
This repository was archived by the owner on Dec 2, 2022. It is now read-only.

How to Contribute

Jump to bottom
uplus edited this page Mar 16, 2020 · 17 revisions

開発の流れ

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

リポジトリ運用

試験的にgit-flowで運用する。
あくまでコアコミッターがこの運用をするだけなので、他のコミッターはdevelopから適当にブランチを切ってPRを送れば良い。
また、この運用はコスパが悪ければ止める。

git-flowを選んだ大まかな理由としては以下

  • スコアサーバは年一次予選・二次予選・本戦・予備校数回で利用する
  • リハーサル後は機能追加を止めたいけど開発は続けたいので、本番ブランチと開発ブランチを分けたい
  • リハーサル後もバグフィックはマージしたい

git-flowはサポートツールがあるので使うと少し運用が楽。

ツールインストール後にリポジトリのディレクトリに移動して以下を実行

git flow init -d
git config gitflow.prefix.versiontag v

参考ドキュメント

全体を通して気をつけること。

  • エラーハンドリングは完璧に行う
    • 黙って失敗するのは最悪、対処不可能
  • その機能でトラブルが発生した際に対処が困難な物は作らない
    • 無いほうがマシ 参加者も運営も実行委員も等しくミスオペする

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

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

情報へのアクセス制限を簡素にするため以下を考慮して開発すべき

  1. 基本的に未ログインでは一切の情報にアクセスできない
  2. 基本的にGraphQLからのみデータが取得可能
  3. 基本的にデータ取得制限はreadable.rbに集約されている
  4. 基本的にデータの追加・更新・削除は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!)

2. デフォルト値について

原則としてデフォルト値は設定してはいけない。
デフォルト値が設定されていると、開発時にどこでデフォルト値が設定されるかを考える必要がある。 デフォルト値が設定される可能性がある箇所はDBスキーマ・モデル・APIのインターフェース・UIなど複数あり中途半端にデフォルト値を作ると複雑になる。 デフォルト値を作るのはUIのみにするべき。

3. エラーハンドリングについて

意図しない挙動は必ずエラーハンドリングを行う。 e.g. case文のelseや一部のif文など

例外を発生させるときはRubyに元からある例外クラスを使わずに自作する。 UnhandledClassなどの汎用的なものが既に自前で用意されているなら、それを使っても良い。

例外を投げるときは原因が分かるような作りにする。 e.g. invalid value ではなく invalid value ("hoge hoge") など

その他

  • レスポンスで配列を返した場合、原則として順序は未定義
    • 必要ならUI側で明示する

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

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