「リーダブルコード」を改めて読み直してみた
👀 はじめに
若手エンジニアの頃に読んだリーダブルコードを読み返してみました。
ここ数年は上流工程やマネジメント業務が多く、
業務でソースコードに触れる機会が減っていました😅
数か月前からソースコードを書く機会が増えたので、初心を振り返ってみようと
リーダブルコードを手に取りました。
今後参考にしたいポイントなど、簡単にですがまとめてみます🐣
🍼 変数の名前
ポイント
- 「名前」を見ただけで読み取れるようにする
- （例）値の単位を付加する
- できるだけ汎用的な名前は避ける（
tmpやvalなど） - 新しくプロジェクトに参加した人でも分かるようにする
- プロジェクト固有の省略形にしない
- 誤解を招かない名前をつける
- （例）プログラマに馴染みのある単語を使用し、連想できる内容にする
感想
プロジェクトに参画したばかりで、プロジェクト固有の単語があった時、
省略あり・なしで統一性がなく、命名に困った記憶があったのを思い出しました😓
しかも省略ありだと、何を示すか分からなかったので、（特別ルールがなければ）明確に記載しておいた方が良さそうだと思いました。
反面、String ⇒ Str、document ⇒ doc、などプログラマなら分かる省略形は今後も使っていきたいですね。
また、趣旨と若干異なりますが、文字数制限などで英単語の省略に困ったら、
下記の記事も参考になりそうと思いましたので、メモしておきます。
💍 コードの美しさ
ポイント
- 宣言はブロックにまとめる
- 「段落」に分割し、似ている考え方はまとめる
- コードを書く時には一貫性を持たせる
- 改行位置は適切にする
- コードの縦の線は、流し読みしやすいように揃える
- 見た目をよくすれば、コードの表面だけではなく構造も解決できる
- 重複コードの削除、コードの変数名やエラー文字列など見やすくなる
感想
以前は、「修正するコードの行は増やさないようにする」という考え方を持っていたのですが、
この本を読んで以降は見やすさを重視するようにしました。
ただ、プロジェクトによってはレビュアーに都度説明していたりしてましたね😓
（今回は直さなくていいでしょうと却下されたりなど）
見た目の問題は本に記載の通り、好みのところもあるのですが、
PJ内で一貫性は持たせたいと改めて思います。
ルールが特に決まっていない場合、新しく参画した人が、どちらを参考にしたら良いのか悩んでしまうので😱
巨大なPJの場合は、せめて今回の案件ではこうしておく～～など、他のメンバーとも情報共有しておくことが大切ですね👀
💬 コメント
ポイント
コメントするべきではないこと
- コードを見たらすぐにわかること
- ひどいコードを補足するためのコメント
- ひどい名前の説明なら、その名前を修正する
コメントは正確で簡潔に書く
- あいまいな代名詞は避ける（
この～やそれ） - 文章は詳細ではなく、簡潔に高レベルで記述する
- 関数のコメントには正確な情報を記載する
- 改行文字なら種類（
\nなど） - 空のファイルは、ヘッダーを含むのか？
- 改行文字なら種類（
- コードの意図を説明する
- ブロックに分けた時に、各ブロックの要約コメントを入れる
public static void outputShoinReport(int shoinCd, int num){
// 引数のチェックを実施する
// ファイル出力に必要な情報をDBから読み込む
// 情報をテキストファイルに出力する
}
感想
上記2項目は、設計書やテスト項目書にも通ずるところがありますね👀
普段のビジネス会話においても、こそあど言葉は避け、簡潔に分かりやすくすることは、
やはりコードでも大切だと本を読んで再認識しました。
また、改行文字のコードとかまではコメントに入れてなかったので、
プロジェクトのルールにもよりますが、処理によっては明確にしておくべきだと思います。
🧩 制御フロー文、分割
ポイント
- 基本は
if/elseブロックを使用する- 三項演算子は簡潔になる場合のみ使用する
- 条件式の引数の並び順
- 左：調査対象の式（変化あり）
- 右：比較対象の式（ほとんど変化なし）
if (researchText.equals(compareText)) {
// 左：調査対象の式（変化あり）
// 右：比較対象の式（ほとんど変化なし）
}
- if/elseブロックは否定形よりも肯定系を使用する
- do/whileループは避ける
- ネストは浅くする
- 早めに
returnする（ループ内部のネストを削除する）
- 早めに
- 巨大なコードは、説明変数や要約変数を駆使する
- コードが短く簡潔な内容でも、分かりやすさを優先する
感想
do/whileループは使っているプロジェクトは未だに見たことないですね🙄（Javaのみ）
Javaではないですが、下記の「ネストの深さは闇の深さ」という記事が、
大変参考になります。（私も新人の頃はネスト6～7回以上やってました。。）
🗂️ 変数の読みやすさ
ポイント
- 変数のスコープは小さくする
- グローバル変数は使用しない
- 変数は基本1度だけ書き込む
- 変数の操作が何度も発生すると、コードの理解に時間が掛かる
- 中間結果を保持する一次変数などは削除する
感想
恥ずかしながら、今まで変数の多さは深く意識していなかったなと思います。
ただ、一度しか使用しないなどは、本書で示す「邪魔な変数」となりえますね😱
グローバル変数も、Apexのプロジェクトでは使用してたので、当時は何も考えずによく使っていました。。
今思うと、影響度とか考えると恐ろしい使い方してしまっていたなと思います。。
👨🔬 テストコード
テストコードも読みやすさが大切。
テストが書きやすく、メンバー間でテストを追加しやすくなる。
ポイント
- 他のプログラマがテストの追加や変更ができるように意識する
- テストコードが複雑だと、本物のコード修正やテスト追加を恐れるようになる
- 長くなるなら、ヘルパー関数を作成する
- エラーメッセージは分かりやすくする
- テストの入力値は単純化する
- テスト関数にも意味のある名前をつける
感想
当時読んでいた時は、テストコードを深く書いたことがなく、あまり分からなかったのですが、
今読んでみると、非常に共感できる内容ばかりです。。
確かにテストコードが長く複雑だと、テストケース追加大変だな～と思っていました。
実際に業務でも、「ここを修正すると、テストケース追加が大変だから別の改修で直す」といったことも…💦
テストコードも今後の保守を考えると、リーダブルコードの考えは非常に大切ですね✨
また、今から単体テストをしようとしている新人・若手エンジニアには是非見てもらいたい内容だと思いました😊
若手に教えることがあれば、↑の内容を意識してみます！
🐳「付録 あわせて読みたい」の書籍メモ
個人的に今後読んでみたい書籍をピックアップしました✋（読んでみたい順）
「達人プログラマー(第2版): 熟達に向けたあなたの旅」
書籍の名前は知っていますが、まだ手に取っていない一冊です。
レビューを見ると、「エンジニアなら読むべき本」とありました。
基礎的なプログラミング技法に限らず、
エンジニアとしての姿勢も載っているようで大変気になります👀
「Effective Java 第3版」
Javaは6年ほど触れてますが、この本を読んで初めて知った書籍です。（恥ずかしながら）
こちらも400ページのボリューム。Java9に対応しているので、仕事でも役立ちますね😊
Javaのプログラムを読みやすく、バグの少ない内容にできるとあるので、
こちらも↑を読んだ後に、近いうちに挑戦してみたいです。
「Clean Code アジャイルソフトウェア達人の技 (アスキードワンゴ)」
リーダブルコード読んだ後、中級者～上級者向きの書籍だそうです。
Javaやチーム開発の手法もあるようで、リーダブルコードと合わせて手元に置いたら良さそう😮
目次だけ読みましたが、リーダブルコードと重複している箇所もあり、
オブジェクトやデータの話まで。ドメイン駆動設計とかの考え方にも繋がるのかなと感じます。
合わせて読んでおきたいです🌼
🐾 おわりに
リーダブルコードを最後まで読んでみて、
何年経過してもエンジニアに必要なことが書かれていますね。
また、他の書籍のことも知れたので、次回以降読んでみたいと思います。
今回初めて読了した本の感想を記事にしましたが、
アウトプットとしても良い勉強になりました🐢
エンジニアは文章を書く機会も多いので、
自分の考えや学んだ内容を要約していくことも大切ですね！
今後も技術書を読んだ後は、記事にしていきたいと思います！
Discussion