タイトルまんまです。
SE二年目、AIコーディングが主流になりつつある私が、綺麗なコードへの理解を深めるために『良いコード/悪いコードで学ぶ設計入門』を読み始めました！
職場の先輩方から「最初は気になるところから読めばいい」とアドバイスをもらったので、今回は読んだ章の所感をまとめていきたいと思います。
読んだ章
- 第2章「設計の初歩」
- 第9章「設計の健全性を損なうさまざまな悪魔たち」
- 第14章「リファクタリング」
技術的に深掘りするというより、読んでいて「なるほど！」と思ったところや、自分に刺さったところの感想です。
第2章「設計の初歩」
まずは「設計の初歩」から。
私は大学では情報系の学部だったものの、そこまでちゃんとコーディングを勉強してきたわけではないので、正直この段階で目から鱗の考え方が多かったです。
- 省略せずに、意図が伝わる名前をつける
- 変数を使い回さず、目的ごとの変数を用意する
- ベタ書きせず、意味のあるまとまりでメソッド化する
- 関係し合うデータとロジックをクラスにまとめる
…当たり前で、なんとなくはそうなんだろうとは思っていたものたちが、きちんと言語化されて、改めて手順として紹介されていくのを見ると、不思議と感動しました。
こんなに初歩的な内容でも、コードは見違えるほど綺麗になるんだな…！と。
実際のところ普段はAIさんにコードを書いてもらうことも多いのですが、コードレビューをする上でも最低限必要な観点だなと思いました。
AIさんに書いてもらうからこそ、「これは良いコードなのか？」を判断できる目は必要なんだなと感じました。
第9章「設計の健全性を損なうさまざまな悪魔たち」
次に、「設計の健全性を損なうさまざまな悪魔たち」。
ここは、マジックナンバーとかグローバル変数とか、先輩方のコードレビューを受けて初めて知った言葉だったよなあ……というノリで読み始めました。
デッドコードもよく見逃してしまうし、型に関しても最近はAIさんにかなり任せてる…。
そんな中で特に気になったのは、YAGNI原則でした。
YAGNI原則
この言葉自体、初めて知りました。
ヤンギ……？
なんか覚えにくそうだなあ……とか考えつつ。
YAGNI は、
You Aren't Going to Need It.
の略で、意味は「実際に必要になったときのみ実装せよ」。
かっこいいですね。
そして心に刺さりました。
将来性を考えて拡張の準備をしておいたり、
「こういうのがあったら便利じゃないか……！？」と枠を用意しておいたりするのは、正直ワクワクするんですけど。
でも、気がつけばTODOだらけ、デッドコードだらけ…。
「いつか使うかも」で用意したものほど、気づいたら誰にも触られないコードになっていることがあるなと思いました。
こういうのは、やっぱり思い切りよく消すべきなんですね。
先人たちの言葉はいつも正しい。
その他にもさまざまな例が紹介されていました。
例えば例外の握りつぶし、これまであまり意識したことがなかったです。
ただ私の場合は、まず「どこで例外処理を入れるべきか」のセンサーを研ぎ澄ますところからなので、覚えておきます。
あとは正直、メタプログラミングの部分がいまいち理解しきれなかったので、ここはもっと勉強ですね……。
第14章「リファクタリング」
そして最後に、「リファクタリング」。
すでに章としては終盤に差し掛かっていて、集大成感がありました。
作者の仙塲大也さんは、リファクタリングを生業にしている方なんですね。
道理で、わかりやすいコードの実例が多いわけです。
そもそもリファクタリングとは？
外から見た挙動を変えずに、内部の構造を整理すること
この定義からあやふやだったので、読んでいてちょっと恥ずかしくなりました。
この章では、
- 早期returnでネストを解消する
- 内容の似ているものをまとめる
- 処理を直書きせず、メソッドにして名前でわかりやすくする
といった技から始まり、大半ではテストコードを活用したリファクタリングの方法について述べられていました。
実は私はまだテストコードをしっかり使えていないので、そんな使い方もあるのか…と感心しました。
割と一般常識なんですかね。
わかんないですけど。
テストコードは、バグを見つけるためだけではなく、リファクタリングを安心して進めるためにも使えるんだなと思いました。
しかし、コードの例を見ているだけでも、どんどん読みやすく綺麗になっていくので感動しました！
特に、最終的にこうあってほしいという雛形から始めるという考え方が好きでした。
最初にごちゃごちゃ書くのではなく、まず最終的な役割がわかりやすい仮コードを書く。
そして、そこを目指してごちゃごちゃしたコードを丁寧に配置していく。
この考え方がかなり腑に落ちました。
まあ、その綺麗なコードの形を思い浮かべられるくらいに、綺麗なコードを意識して慣れていかないとなんですけどね。
まとめ
ということで今回は、第2章、第9章、第14章の全3章分を読んでいきました！
AIコーディングが主流になってきて、自分で一からコードを書く機会は以前より減ってきたかもしれません。
それでも、この知識は人の目によるコードレビューや、設計段階、コードを書いていくときの方針などに、必ず影響すると感じました。
AIがコードを書いてくれる時代でも、「良いコードかどうか」を判断する力は人間側に必要なんだなと思いました。
また続きを読んだら、2回目を投稿するかもしれないです。
それでは！