Skip to content
This repository has been archived by the owner on Dec 21, 2024. It is now read-only.

Latest commit

 

History

History
151 lines (116 loc) · 8.52 KB

CONTRIBUTING.md

File metadata and controls

151 lines (116 loc) · 8.52 KB

Let's contributing!

これからいろいろ書いていきますが、一番大事なのは気軽にやってみることです。 皆さんのチャレンジを、首を長くしてお待ちしております:bow:

開発環境について

下記のツールをセットアップ後に、 このプロジェクトのルートディレクトリーを Android Studio で開くことで開発作業をする環境が整います。

もし何か分からないことが出てきたら、声をかけてください。

任意

下記のツールは無くても開発できますが、あると便利なので、興味に応じて試してみてください。

  • JetBrains Toolbox App
    • Android Studio の複数バージョンの併用
    • プロジェクトと起動IDE の紐付け
  • Visual Studio Code
    • .gitignore の記述
    • GitHub Actions の構築
    • Git クライアント + Pull Request 等の確認
    • Markdown の記述
    • OpenAPI の記述
    • PlantUML の記述

開発作業の流れ

基本

  1. タスクはGitHub Issue で管理されているので、その中からやってみたいものを探す
  2. やりたいものが見つかったらIssue のAssignees に自分を設定する
  3. 最新のdevelop ブランチからGit ブランチを切る
    • 名前はfeature/??? という形式で、??? の部分を良い感じに設定してください
  4. 開発する
  5. 1日の終わりに出来たところまでをDraft Pull Request として作成する
    • 特に理由が無ければdevelop ブランチに対してPull Request を作ってください
    • 進捗管理の都合上、どこまで出来ているかを見たいので、対応してくれるととても助かります
  6. 作成したPull Request のDevelopment に関連のGitHub Issue を紐づける
    • Pull Request のマージ + 条件を満たすとIssue もクローズしてくれるようになります
  7. 作業が完了したら、Draft 状態を解除し、レビュー担当者に連絡してください

緊急対応すべきと宣言されたバグフィックス

「緊急」とあるように、綿密な進捗管理が必要となるものなので、適宜状況共有してくれると助かります。

  1. 最新のreleased ブランチからGit ブランチを切る
    • 名前はhotfix/??? という形式で、??? の部分を良い感じに設定してください
  2. バグ修正をする
  3. レビュー担当者に連絡してください

レビュー方針

  • レビューする際、PR 単位で確認します
    • コミット毎ではないので、ある程度は雑で大丈夫です
    • (Revert するケースを考えるとコミットが綺麗だと嬉しいですが、開発スピードを優先したいので、ここは後回しにします)
  • API の誤用と思われる場合は差し戻します
  • マージコンフリクトした場合は、下記の順で判定します
    1. 実装の都合
    2. アルファベット順

リリース作業の流れ

通常

  1. リリース対象Pull Request がdevelop ブランチに全てマージされていることを確認する
  2. https://github.com/tshion/yumemi-inc_android-engineer-codecheck/actions/workflows/140-create-version-pr.yml のGitHub Actions を実行し、アプリバージョンの更新Pull Request を作成する
  3. 前の手順で作成したPull Request に問題がなければマージする
  4. released ブランチへのマージPull Request が作成されるはずなので、しばらく待つ
  5. 前の手順で作成したPull Request に問題がなければマージする
  6. GitHub Releases が自動生成されるので、様子を見る

hotfix

  1. hotfix のPull Request に問題ないことを確認する
  2. 上記のブランチを指定して、https://github.com/tshion/yumemi-inc_android-engineer-codecheck/actions/workflows/140-create-version-pr.yml を実行し、アプリバージョンの更新Pull Request を作成する
  3. 前の手順で作成したPull Request に問題がなければマージする
  4. 作業が完了したら下記ブランチそれぞれに対してPull Request を作成する
  5. 前の手順で作成したPull Request に問題がなければマージする
  6. GitHub Releases が自動生成されるので、様子を見る

備考

Git ブランチの役割について

ブランチ名 役割
develop 開発作業のメインブランチ
feature/??? 各Issue の作業ブランチ
hotfix/??? 緊急で対応しないといけないバグフィックスの作業ブランチ
released リリースの記録ブランチ

GitHub のLabels について

どのLabel にするかは各自で判断が別れやすいところなので、下記以外は何もつけなくて大丈夫です。

  • bug -> hotfix なものに付与する
    • 作業進行で慎重に扱わないといけないため
  • duplicate -> 重複しているものに付与し、他のところで取り扱うことを宣言する
  • github -> GitHub 機能を利用しているものに付与する
    • 利用サービスによって変動するので、別プロジェクトとの差分を視覚化するためにマーキングする

GitHub のMilestones について

  • 基本的にはGitHub のIssue を紐づけます
  • もしGitHub のPull Request のみしか存在しない場合は、それを紐づけます
    • 例: ドキュメント更新のPull Request

開発の心得

  • クラスやメソッドは、なるべく統治しやすい単位で切ること
    • ユニットテストを書きやすいかどうかが一つの目安になります
    • 今後の保守で機能が無くなったり、実装の書き方が古すぎる場合、この単位で削除や差し替えのための再実装が容易であるとサイコーです:laughing:
  • 参考にした資料などの記録を、Issue やPR に忘れずに記載してください
  • 変更はなるべく小さくすること
  • メソッド名は基本的に(動詞) + (名詞) で付けていくこと
    • 何をどうしたいかがパッと見でわかると超クールw

メモを残したくなったら

本リポジトリでは下記を用意しているので、よさげなところがあればそこに追記してください。

  • 開発にまつわることを書きたい
  • 仕様にまつわることを書きたい → 仕様メモ

それ以外に何かあれば、docs/ 配下で作業し、Pull Request を出してください。

ルールオブスリー(３度目の法則)

作業を進めていくと似たようなコードを見つけてしまい、ついつい共通化とか考えたくなるとは思いますが、一旦心を落ち着けて、下記を意識してもらえると嬉しいです。

最初は、単純に作業を行います。 ２度目は以前と似たようなことをしていると気づいた場合には、重複や無駄を意識しつつも、とにかく作業を続けてかまいません。 そして３度目に同じようなことをしていると気づいたならば、そこでリファクタリングをするのです。

引用: Martin Fowler (2014) 「新装版　リファクタリング　既存のコードを安全に改善する」　児玉公信・友野晶夫・平澤章・梅澤真史訳、オーム社

参考文献