スライド
感想とメモ
良いソフトウェアの基準とは下記が満たされていること
可読性
見やすいコード、途中から入ってきた人間にも理解できるのが理想。そのため修正がしやすい。
命名規則やコードのインデント、適切なコメントが大事。
全ての変数や関数名を説明的にすればよい訳では無い。
関数内で利用されるスコープの短い変数は1文字で命名してもOK
使用頻度が多い関数は短く命名しても良い
コメントは書かないに越したことはないが、Howを説明するコメントは不要。しかしWhyを説明するコメントは有用である。（なぜそうしたのかを書く
リファクタリングと機能追加を一緒にやらない、リファクタリングのPRを出してから機能追加を行う
リファクタリングのPRからブランチを派生するか、一度マージしてから機能追加をするかが悩みどころ。ササッとレビューしてくれるとリファクタリングのPRの修正があればやるし、なければマージして機能追加ができる。
リファクタリングを行うためにはテストコードが必要不可欠だと思った。
ライブラリコードはドキュメント化する。
自分で作った関数のドキュメントは必要みたいなことかな
保守性
仕様変更や追加があったとき触っても頭を悩ませない。
保守性の高いソフトウェアは時間とコストの節約、エラーの減少、柔軟性（市場や技術の変化に強い）のメリットに繋がる。
モジュール性（プログラムを小さい部品に分ける）の高い設計を行う。
効率性
良い感じに早く動く（レスポンスが早い）し、そこまでマシンが重くならない
信頼性
エラー処理が考慮されており、バグも少ない。
テストがちゃんと書かれている
例外処理、エラーメッセージの適切に使用している
モジュール性の高い設計が必要不可欠。
拡張性
恐らく保守性とそんなに変わらん？
抽象化
コードレビューとは
良いソフトウェアを維持するための活動
チームのスキル向上と知識共有に役立つ。
また複数人が見ることによりコードの一貫性が確保される。
戦略的コードレビュー
システム全体として適切かどうか
戦術的コードレビュー
将来AIに置き換わるかも
レビュイーのベストプラクティス
PRの説明を行う、変更内容と理由、見て欲しい部分を説明する
コード内に適切なコメントを付ける
小規模で理解しやすい変更で提出する
一つのPRには関連性のある変更のみを含める
フィードバックを受け入れる、防御的にならず対応する
レビュアーから質問があれば回答するし、必要であれば追加情報を提供する
レビュアーへの感謝を忘れない
レビュアーのベストプラクティス
提出されたコードの理解を深める
コードの変更が必要となった背景や目的を読み取る
改善点だけではなく良い点も指摘する
指摘する問題点や提案の理由を明確に言語化する
改善例やアイディアを提供する
相手に対して尊重を持って接する、相手の意見を尊重する
なるべく早くレビューしてあげる
レビューが遅れることのよってチームの生産性に影響が無いようにする