Flutter 研修課題テンプレート
具体的に適切かという点はそれぞれの実装によってことなるため、リード・テックリードがサポートする必要がある場合があるかと思います。
しかし評価観点に記してあることに注意することでそれらを学ぶことができれば十分であると考えています。
プログラミングには、問題の解答集のように答えが定まっているわけではありません。
そのため、プログラムのレビューにおいては、曖昧な箇所が出てしまうことがあります。
ある程度レビュー観点をリストアップすることで、より良いプログラムを作成するためのヒントを得ることができます。
レビューにおいて曖昧な箇所があった場合は、リードやテックリードに相談することで、より適切な対応を行うことができます。
研修評価項目
Session 毎のレビュー項目
評価項目 | session | レビュータイプ | 補足 |
---|---|---|---|
1 | nits | より意図が分かりやすくなり可読性が向上する | |
1 | nits |
| |
1 | nits | より適切なものを使うことによって、可読性が向上する | |
1 | good | 縦画面固定は必須ではなく、対応していた場合のレビュー項目
| |
1 | nits | ||
1 | imo | ページ内に補足あり📝 | |
1 | nits | const で定義できる SizedBox や Padding で置き換えられないか確認する | |
2 | must | 後々、画像追加する際に都度修正する必要がなくなり、保守性が向上する | |
2 | must | 不要なインスタンス生成を日頃から行っていると、ループ処理などの重たい処理を行う際にも記述してしまってパフォーマンスに影響を及ぼしてしてしまう恐れがあるため、日頃から無駄なことをしないように意識する | |
2 | nits | APIが修正されて不具合が入り込んだ時のことを想定しておくと、より安全性や保守性が向上する | |
2 | nits | 分岐処理で | |
2 | must | API が意図せずに変更されたり、不具合が入り込んだりした時のことを想定して、API の処理時に | |
2 | next | ||
2 | nits | flutter_gen または、独作 | |
3 | must | 予期せぬリビルドが生じる可能性があるため 代わりに、initStateに処理を書いているか | |
3 | must | スレッドをブロックしてしまうから | |
3 | must | 非同期処理で UI を操作しようとするときに mounted のチェックをしていないと、 Widget が Widget Tree に マウントされていない可能性があり、エラーが生じることがある | |
3 | good | ||
3 | good |
| |
4 | must | • | |
5 | good | ||
5 | nits | ネストが深くなるのを防ぎ、可読性・保守性が高まる | |
5 | good | 可読性・再利用性を高める | |
5 | good | ||
6 | imo | ページ内に補足あり📝 | |
6 | must |
| |
7 | must | ページ内に補足あり📝 | |
7 | must | デフォルト値を記述すると、他のデフォルト値も全て記載しないといけなくなりそうで、メンバーに混乱が生じる | |
7 | nits | ページ内に補足あり📝 | |
7 | good | ページ内に補足あり📝 | |
7 | nits | 2つのパッケージは関連が強いので、コミットをまとめておいた方が良い | |
8 | mustimo | ページ内に補足あり📝 | |
8 | nitsmustimo | ページ内に補足あり📝 | |
8 | must | ref: https://docs-v2.riverpod.dev/docs/concepts/reading#dont-use-refread-inside-the-build-method | |
8 | must | ref: https://docs-v2.riverpod.dev/docs/concepts/reading#dont-use-refread-inside-the-build-method | |
8 | must | 特に意図がない限り基本的に状態は保持しつづけるべきではない | |
8 | nits | • アーキテクチャの説明でなく、実装の説明になっていないか ◦ 具体的なクラス名やファイル名を記載すると、リネームのたびに修正が必要になる | |
8 | imo | ページ内に補足あり📝 | |
8 | must | ||
8 | goodFYI | riverpod_graphを使うことでProviderの依存関係図を自動生成できる https://github.com/rrousselGit/riverpod/tree/master/packages/riverpod_graph | |
9 | nits | ||
9 | must | • @visibleForTesting だけの場合、警告の表示で無視することもできてしまうため、analyzer の error に設定した方がより安全 • ref: https://kanta-mori.netlify.app/p/visiblefortestingとは/ | |
9 | nits | ||
9 | must | ||
9 | must | 依存先を明確にしてテストダブルを利用しているか | |
9 | nits | ||
9 | nits | ||
9 | must | ||
910 | nits | ||
910 | nitsmustimo | ページ内に補足あり📝 | |
10 | good | ||
10 | nits | ||
10 | must | ||
10 | good | ||
11 | FYI | ページ内に補足あり📝 | |
11 | must | ||
基礎的なレビュー項目
評価項目 | タグ | 補足 |
---|---|---|
Dart | final = 実行時不変, const = コンパイル時不変(定数) | |
Dart | ||
Dart | 可読性・保守性が低下してしまうため スコープが狭く今後も広くなりづらい場合や、final で書くことによって記述量が増えてしまい可読性が低下する場合は使用してもいいかもしれない ただし、そのような場合はほとんどない | |
Dart | スコープは小さくすると安全性が高まって良い | |
Dart | 目的によるが、print() では不十分な場合がある ref: https://rizumita.medium.com/logging-in-dart-dd9c01eb459a | |
Dart | ||
Dart | ||
Dart | if(条件式) { return … } (早期リターン) などでネストが深くなるのを回避する | |
Dart | 単純に return するだけの場合、わざわざ関数化しない | |
Dart | ||
Dart | 後から enum に要素が追加される場合、if-else で判定すると修正の必要性に気づけない可能性があるため、 switch - case 使う | |
Dart | 意味のある数値を何も説明なく使用しない → 意味のわかる命名で定数を定義して利用するのが良い | |
Dart | ||
Dart | • 通常はコードの変更にも安全に開発できるようにするために、ローカル変数にして型昇格を行ってから利用する • スコープが狭くほとんど変更されない箇所でnullじゃないと確信できるところは、 “!” を使うことを許容する | |
Dart | ||
GitHub | ビルドできる単位で、など | |
GitHub | Prefix がついていると見やすい 「エラー直した」など具体性が低いものは NG | |
GitHub | ||
GitHub | ずっとブランチを残していると、ブランチを切り替える際に徐々にコストがかかるようになってしまう | |
GitHub | アーキテクチャグラフや環境構築の手順が記載されているか | |
GitHub | ||
GitHub | *.freezed.dart・*.g.dart 等 | |
IDE | ||
IDE | ||
IDE | VS Code では、settings.json に Code Spell Checker の設定を行う | |
品質 | ||
品質 | ||
品質 | ||
アーキテクチャ |