リーダブルコード の商品レビュー

ダスティンボズウェル,トレバーフォシェ【著】,角征典【訳】

2022/05/16

プログラミングを始めてから数ヶ月経ち、まだ1人でしか開発経験がないので、将来誰かと一緒に開発するようになった時にどんなコードを書けば良いのかを知りたくて本書を手にとった。

本書を読んだ第一印象は、実務経験がない状態だとほとんど実感が湧かないということだった。ただ、どんなコードが「良いコード」かという部分はとても印象的だった。

自分の解釈では、「良いコード」とは綺麗に整形されていて、他人はもちろん、(書いたことを忘れている)数ヶ月後の自分が読んですんなりと理解できるコードだ。これは個人で開発していても大事な事だと思った。

他にも、関数の命名やコメントの仕方についてなど、プログラマに必要なおそらく超基本的な事柄がまとめられている。

本書を読んで自分がまずやってみようと思ったことは、「一度に一つのことを」というもので、これは関数を作る時もそうだが、一箇所コードを変更したらdiffを付けてこまめにコミットすることだ。これは数ヶ月後とかに修正を見直した時にありがたみを感じるかもしれないので実践しようと思う。

2022/05/08

どういうふうにコーディングすると
理解しやすいコードになるか考えることが多いと思います。

本書の内容を意識し、コーディングすれば
理解しやすいコードになっていくのではないかと感じました。

個人での開発ではなく、チームで開発している場合は
チーム内で認識を合わせる必要はありますが、
本書の内容はエンジニアとして理解しておきたい内容です。

2022/05/04

読みやすい/理解しやすいコードを書く理由とその方法が書かれている本。
コードだけでなく、何かしらの言語でドキュメントを作成する場合にも適用される話だと思った。

【読みやすい/理解しやすいコードを書く理由】
・コーディングはチームで行われるため、他人が読むことが前提となる。他人が読む時に効率よく理解できることは、修正のしやすさにつながる。
・コードは後々運用していくもの。他人＝後の自分になることは十分ありえるので、自分が後に読むときのために理解しやすくしておく。

【方法】
1.表面上の改善
◆変数、メソッドの名前の付け方
　・目的/やりたいことを表す名前にする
　・情報に過不足ない名前にする
　・一意で具体的な名前にする
　・max/min, first/last, begin/end, is/has/can/should
◆コードの美しさ
　・論理的単位にわける
　・改行、整列、順序を一貫する
◆コメント
　・自分の考え、目的/意図、注意事項、サマリを書く

2.ループとロジックの単純化
◆制御フローを読みやすくする
　・if/elseは肯定、単純、目立つものを先にする
　・dowhile,gotoは使わない
　　→do whileは条件が後に来るので読みづらい
　　→gotoは処理が飛ぶので追いづらい
　・ネストはせず、直線的にする
　　・ifを分割して、returnですぐかえす
　　・for内は、continueでループを切る
◆巨大な式を分割する
　　・説明変数、要約変数の定義(何のデータに対して処理するか、先にわからせる)
　　・ド・モルガンの法則で、論理をシンプルに
　　・ifの中身は極力ひとつに
　　・繰り返し使うものは変数定義、メソッド定義する(DRY原則！)

◆変数と読みやすさ
　→変数を減らす、使うとしても短期間にすると頭使わなくてよいので嬉しい
　・変数は極力削除する(中間変数を消す)
　・スコープを短くする
　　　・ローカル変数を使う(グローバルは避ける)
　・変数は一度だけ書き込む

3.コードの再構成
◆下位レベルの処理は分けてメソッド化する
　・コードの抽象度を合わせることで、全体で何をしたいのか見通しを良くする
　・分けたメソッドは、再利用可能だし、別でテストが可能なのが嬉しい

◆一度に一つのことをする
　・一度に色々なことをやろうとすると、読みづらい。
　　→タスクを列挙して順序立てて、それをコードに反映する

◆コードに思いを込める
　・シンプルにしたい場合は、まず簡潔に説明してみる。その後、コードに反映してみる。

◆コードを短くする
　・読みやすくするため。
　　また、開発、テスト、エンハンス工数を短くするため。
　・ライブラリなど、あるものを積極利用する。
　　一般的なAPIを眺める時間を作るのが良い。

4.選抜テーマ
◆テストと読みやすさ
　・テストソースは高レベルなもののみ記載。
　　低レベルなデータセットは外出し。
　・エラーメッセージはわかりやすくする
　　・インプット、アウトプット、想定結果くらいはわかるようにしたい
　・データセットはテストしたい機能を網羅かつ簡潔にするように。(同値分割、境界値分析する)
　・テスト関数名は、何をテストしているかわかるように
　　→Test_テスト対象関数名_状況など

2022/04/30

幾つか分からないこともあったけど、良いコードとは何かがざっくりと分かった。
なぜ良書と言われているのかも分かった。
開発に入ってから読む始めると一気に書いてあることが頭に入ってくる。

2022/03/26

リーダブルコード

Dustin Boswell氏、Trever Foucher氏による、理解しやすいコードを書くポイントをまとめた著書です。
10年前の本です。たしかに書かれているサービスやツールなどは古くなっています。
しかし、本質的な部分は普遍で現在でも十分大事なことを伝えてくれます。

【本書で学べること・考えること】
- 理解しやすいコードとは
- 理解しやすいコードの利点
- 名前の重要度
- 見た目の美しさ
- コメントに書くこと、書かないこと
- 制御フローを読みやすくする
- 巨大な式を分解する
- 変数の注意点
- 下位問題の抽出
- 一度に１つのことをやる
- 短いコードを書く
- テストと読みやすさ

読んでみての感想です。

経験の浅いWeb系のエンジニアにとっては、とても有用な本で良書です。

読みやすいコードを書くために3つ部から論じています。
第1部では、表面上の改善として以下のポイントが書かれています。
- 名前
- 見た目（インデントなど）
- コメント
第2部では、ループやロジックの単純化のために以下のポイントが書かれています。
- 制御フローを自然にする
- 巨大な式を分解する
- 変数のデメリット、定数の使用
第3部ではコードの再構築をするために以下のポイントが書かれています。
- 下位問題を抽出して分割する
- 一度に１つのことをする
- 短いコードを書く
選抜テーマとしてテストと読みやすさについて書かれています。

上記の内容は、色々なオンラインカンファレンス等で著名なエンジニアの方々も言われていた内容で、それが体系的にまとめられているのが良いです。
経験の浅いエンジニアは、是非読んで、読みやすいコード文化を根付かせたいです。

できれば、最近の言語に合わせた改訂版が出ると良いなと思います。

2022/03/18

読みやすいプログラムを書くための知識が詰まった本。
深い技術や難しい論理抜きで語られているので、プログラミング初学者から広く読まれているベストセラー。
プログラマーといっても幅広い種類・職種があるが、どのプログラマーもこの本に書かれているテクニックは必須の知識と言えると思う。

この手の本は、他にもいくつかあるが、日本人が書いた本は見当たらない。
初学者が討論できるレベルのものを作品にするのは文化的に難しいのだろうか。

2022/03/11

たまにこの本をパラパラと見ると、毎回得られるものがある良い本。

守る
・tmpやretvalなどの汎用的な名前を避ける
・スコープが小さければ短い名前でもいい
・行数を短くするより、理解にかかる時間を短く
・コメント書くより、名前を変えてわかるようにする
・変数は一度だけ書き込む

挙げ出したらきりがない。

2022/03/04

そういえば読んだことなかった。いかに鮮やかに一行にまとめられるか努力していた時期もあったが、やはり間違いだったと再認識できた。それからテストのやりすぎ問題にも共感。ほんのちょっと人に親切に書くというポリシーで行くのがいいのかもしれない。
56冊目読了。

2022/01/02

輪読会で改めて読み直した

変数名の付け方
テストコードの書き方

など改めて気づきを与えてくれる本でした。

2021/11/28

言語関係なく綺麗に描けるようになる
書いている時の違和感を言語化してあるため、何でコードが変に感じるのか原因が分かる

今後コードを書く際には必ず横に置いておきたい本