以下にAndroid（Kotlin）/iOS(Swift)それぞれのコードレビューで気を付けるべき点について記載していく。
Android(Kotlin)
・参考１：翻訳: Kotlinベストプラクティス『Idiomatic Kotlin. Best Practices』
https://qiita.com/takahirom/items/87d46150088aadccb481
・スコープ関数を適切に使用しているか？（またはスコープ関数を使うことで可読性を高めているか）
参考２：KotlinのRun, Let, Apply, Alsoを使い分け
https://qiita.com/JohnSmithWithHaruhi/items/e8f411c379483d4902aa
・LiveDataを使用する場合、Observeは意図したタイミングで実行しているか？
例えば、onViewCreatedで一度だけObserveするのではなく、
ユーザー操作で何度も通るパスで何度もObserveすると、
PostValueされて通知が飛んだ時にOvserveされた回数分だけ通知が動くことに。。
iOS(Swift)
・参考１：【Swift・iOS】コードレビューからコーディングする際の注意点をまとめてみた。
https://qiita.com/shogunzozo/items/7432a2881e8b37e2f45c
・参考２：Swiftのコードレビューの時に確認しているポイント24選
https://qiita.com/tsuta0856/items/4545bf8c2ffbfb05bb1f
・参考３：循環参照の理解から対策まで
https://qiita.com/yoshidasss/items/d263823d2786b567df02
・layoutSubviews
カスタムViewのinit()でself.frameに依存したsubviewのレイアウト処理は書くべきではありません。
画面の回転などによって変化していないため。
Viewのframeが変化した時に自動的に呼び出されるlayoutSubviews()でself.frameに依存したsubviewのレイアウト処理を書くべき
・適切な位置にMARKが記載されているか？
ちなみにSwiftで区切り線を引きたいときは、「//MARK:- *****」でOK
i/A共通
・コーディング規約を満たしているか？
・ヘッダーコメント、クラスやメソッドのDocコメントは適切か？
・レイアウトで完結するのに、コードで処理していないか？
・複雑な処理、後から見た人が分からないコードになっていないか？
こういう場合はメソッド分けを検討する、もしくはコメントを手厚く書く
・テストコード
修正、または新規に作成したコードは、XCTestやUIテストを通っているか？
またはカバレッジ率は問題ないか？（これは案件ごとに異なるかも）
・誤字脱字は無いか？
・デザインパターンに則って修正されているか？
UI操作、ロジック、APIリクエスト、DBアクセスなど、デザインパターンに則って適切に振り分けられているか？
・余計な（不要な）修正は入っていないか？
Podを使っている場合はPodの変更が不要にもかかわらず変更してるとか、
あるファイルの変更点が無駄な改行１行のみの変更点がある、とか
TODO、FIXMEコメントやデバッグ用のコードが残っていないか？
・ライフサイクルを意識した修正となっているか？
・適切なスコープになっているか？
変数、メソッドのスコープは適切か？
不要なアクセスになっていないか？
・関数型プログラミングしているか？
副作用を避け、純粋関数を使用することで、テストが容易になり、スレッドセーフなコードを書くことができます
参考：https://qiita.com/nemo-855/items/92b37ef2e9083c0d6c16
※純粋関数は以下２つを満たす関数のこと
参照透過性がある
外部に対する副作用がない
・汎用コードを作成する
プロジェクト固有のコードから汎用コードを分離することを考える。
これは、プロジェクトの他の部分から分離された、境界線の明確な小さな問題に集中できるからだ。こうした会問題に対する解決策は、より綿密で正確なものになる。それに、あとでコードを再利用できるかもしれない
・一度に一つのタスクを行う
読みにくいコードがあれば、そこで行われているタスクを全て列挙する。そこに別の関数やクラスに分割できるタスクがあるだろう。
それ以外は、関数の論理的な段落になる。タスクをどのように分割するかよりも、分割するということが大切なのだ。
※タスクを分割する際にうまく言葉で説明できないのあれば、何かを見落としているか、問題点や設計、または仕様に関する詳細が明確になっていないということだ。プログラム、あるいは自分の考えを言語化することで、明確に問題や設計を把握することにつながる。