概要

これは、自分で書いたソースコードをレビューすることで、次の効能を期待した “お日記” です。

  1. ソフトウェアを変更しやすくする効果
    • ソフトウェアはソフトであるため、なるべく簡単に変更できなければならない。もしくは捨てやすくなければならないと考えます
  2. ソフトウェアが価値を提供し続ける効果

なおプログラミング言語は Ruby を前提としています。

仮説

前述の効能については コードレビューの観点 | google-eng-practices-ja で挙げられている次のレビュー観点が必要と考えます。

出典：コードレビューの観点 | google-eng-practices-ja より抜粋

コードレビューをする際には、次のことを確認してください。

  • コードがうまく設計されている
  • コードが必要以上に複雑でない
  • 開発者は将来必要になるかもしれないものではなく、現在必要だとわかっているものを実装している
  • テストがうまく設計されている
  • 開発者はあらゆるものに明確な名前を使った
  • コメントは明確で有意義なもので、「何」ではなく「なぜ」を説明している
  • コードはスタイルガイドに準拠している

以下に各観点の認識と妥当性の確認方法や外部サイトの参考リンクを示します。

コードがうまく設計されている、テストがうまく設計されている

役割や特徴が巨大ではなく、いい感じの期待感に合った責務へ分解されていることがうまい設計と考えます。言い換えるとテストがしやすい設計と言えるでしょう。

コードはスタイルガイドに準拠している

RuboCop などの静的解析ツールを活用することで、スタイルガイドに準拠したプログラムの書き方や、ある程度の読みやすさ、未使用の変数がないことを確認できます。

基本的には静的解析ツールで検出された内容と次の内容を確認すればよいと考えます。

コードが必要以上に複雑でない

必要以上に複雑ではないとは、ソースコードが明確であると考えます。言い換えると疑問や誤解が生じない、行間を読ませないソースコードであると言えるでしょう。 具体的には次の要素を備えたソースコードではないでしょうか。 なお前述の コードはスタイルガイドに準拠している で挙げた、ある程度の読みやすさとは1メソッドの行数やネスト情報が多くないことと考え、ソースコードの明確さの一部と捉えます。

1. 詳細を読まなくても予測可能なメソッド名や引数、戻り値であること

  • テストコードを読んでメソッド名と振る舞いが腹落ちすること
  • インターフェースとしていろいろな使い方があると混乱する
    • 副作用をおこしていないか
    • 余計なことをしていないか
    • 驚きを与えていないか
    • そのクラスに対する操作で違和感がないか
    • ? がついているのに Boolean 以外を返していないか

2. 必要最小限の可視性を持つメソッドであること

3. 必要以上に引数でデフォルト式や遅延初期化をしていないこと

  • デフォルト式で使い分けを期待しているのであればいいが、そうでないなら混乱する
  • 保守する際に必要な記述の判断に迷うので、万が一なら書かない
    • やるならエラーを投げるなど親切にしよう

4. コールグラフ が簡潔でコードリーディングを阻害していないこと

  • ワンライナーな記述をメソッドにしていないか
  • 再帰的な処理が直感的か

5. 凝ったことをしていないこと

  • 愚直に書いたほうが誤解のしようがないためわかりやすい
  • 使わないブロックは削除しよう
  • 使わないブロックパラメータは削除しよう

開発者は将来必要になるかもしれないものではなく、現在必要だとわかっているものを実装している

悲観的、防御的なプログラミングでなく、なるべくイミュータブルな属性で振る舞うことが最小限の実装であると考えます。言い換えると initialize で初期化された属性がほとんど変わらないオブジェクトが必要最小限の実装と言えるでしょう。

開発者はあらゆるものに明確な名前を使った

明確な名前とは共通認識となる語彙があり、それを適切に名づけることと考えます。正解はないが改善を続けることが重要と言えるでしょう。

コメントは明確で有意義なもので、「何」ではなく「なぜ」を説明している