📖
リーダブルコードを読んで気づいた「理解しやすいコード」の本質
はじめに
エンジニア歴2年半、これまで参考書をあまり読んでこなかった私が、今更ながら基礎固めのために『リーダブルコード』を読み始めました。読み進めながら気づいたことを記録していきます。
第1章で学んだ「コードの本質」
一番大切な原則は何か？
読んでいて最も印象に残ったのは、コードは理解しやすくなければいけないという基本原則でした。
当たり前のようでいて、実務では意外と見落としがちなポイントだと感じています。
「簡潔」vs「わかりやすさ」
書籍では2つのコードスタイルの比較がありましたが、これまでの自分を振り返ってみると…
以前の私の価値観：
- 1行で書けるものは1行で
- ライブラリの高度な機能を使ってスマートに
- 短いコード = 良いコード
今回の気づき：
- 短いコードより、安心して読めるコードの方が価値がある
- 「後から見返したときに困らない」ことの方が重要
実際、過去に自分が書いた短縮記法だらけのコードを見返して「何してたっけ？」となった経験が何度もありました。
効率性との両立は可能？
以前は「わかりやすくするとパフォーマンスが下がる」「設計が複雑になる」と思い込んでいました。
でも書籍を読んで、理解しやすさと他の要素は競合しないということを学びました。
具体例（自分の経験から）：
// ❌ 改善前: 効率を重視したつもりだが、理解しにくい
const result = data.filter(x => x.status === 'active' && x.role !== 'guest').map(x => ({ ...x, processed: true }));
// ✅ 改善後: わかりやすく、かつ効率も良い
const activeNonGuestUsers = data
.filter(user => user.status === 'active')
.filter(user => user.role !== 'guest');
const processedUsers = activeNonGuestUsers.map(user => ({
...user,
processed: true
}));
実務で意識したい3つのポイント
-
「未来の自分」を読み手として想定する
3ヶ月後の自分が見てもすぐ理解できるか？ -
コードレビューの観点を変える
「動くかどうか」より「理解しやすいかどうか」を重視 -
短時間での理解を最優先に
複雑な処理ほど、丁寧にコメントと命名を
まとめ
第1章では、コード品質における理解しやすさの絶対的な重要性を学びました。
最短時間で理解できるコードという基準を持つことで、今後のコーディングが変わりそうです。
最後まで読んでいただきありがとうございました。
Discussion