Good Code,Bad Code の商品レビュー

Tom Long(著者),秋勇紀(訳者),高田新山(訳者),山本大祐(監修)

2024/11/10

よりよい高品質なコードを書くための思考法について体系だてて書かれた本。

最初のほうで、「おそらく、警官豊富なエンジニアは、本書に書いてあることの多くはすでに知っているでしょう」とのことで、確かに聞いたことあるというのは多かったけど、これを実践できるようになるための考え方というのはなかなか身についていけてないのでためになった。本当、このようなコードが普段から書けるようになりたいと思う。
本当、気づいたら悪いコードになってたりするので…。

コードのモジュール化を玩具に例えた例が非常に分かりやすかった。ぬいぐるみと、パーツごとに分かれたロボットの玩具だと、確かにロボットのほうが組み立てやすいのだろうなと。
業務でコードを書いていると、モジュール化より無理やりな共通化をしてしまうことがあるので、このあたりちゃんと意識して書けるようになりたい。

なお、著者によると、高品質なコードは、中長期的には開発スピードを上げるはずとのこと。一見すると、モジュール化して関数やクラスが増えたり、テストコードを書かないといけなかったりと量が増えるから時間かかりそうな気がするけど、修正に強いのはやっぱり高品質なコードだろうしね。
戸棚で例えた例も、すごい分かりやすかった(例えがうまい)

最近のC#には、null安全をサポートしてると知って驚いた。今後、C#を利用する機会があればnull安全にしていこうと思う。

ビルダーパターンというのは、面倒とは思ったけど、品質をあげるという意味では確かにありなのかもしれないとは思った。
最近は、オブジェクトは不変にしたほうがいいという考え方が主流になってきているようだし、こういうチェーンメソッドで記載できる書き方もありなのかな。
ただこの書き方は、無駄なインスタンス化が増えてコストが増えるので、それだけが心配だったりする。そういう考えって、古いのだろうか…。

ユニットテストの話の中で、モックとスタブと似た機能でフェイクというのを紹介されてたけど、ようはテスト用のクラスを、モックの代わりに作るということらしい。
かなりシンプルな考え方だなと思ったけど、こういう考え方はモック派にたいして古典派といわれてるらしく、著者としてはフェイクを使ったほうがいいのではないかとのこと。フェイクなら、モック用のライブラリも必要ないだろうし、コードもわかりやすくなるのだろうなと思う。
ただ、基本インタフェースを使ったクラスを実装しないといけないので、ちょっと面倒かもとは思った(これぐらいなら、継承という形にするのも、悪くないような気はするけど)

なお、著者はGoogleで働いているそうだけど、TDD(テスト駆動開発)について、実践しているエンジニアはそれほど会ったことが無いということで意外に感じた。Googleなんかは、てっきりTDDで開発してるものかと。やっぱり、TDDって難しいのだろうなぁ(それだけじゃないかもしれないけど)。

そういえば、本書のコードは、静的に型付けを行える言語が対象とのことで、その例の一つに「JavaScript(ECMAScript2015以降の静的型検査があるもの)」と書いてあったけど、JavaScriptにそんな機能あるのか？　調べてもよく分からなかったのだけど。
※TypeScriptは分けて書かれてたので、TypeScriptで型検査するという意味ではないよう。

2024/07/01

どれも実践的で説得力のあるものだった。内容はすごく良かったけど、一つだけ気がかりなところがあった。というのは、コードを書く主体の名称をプログラマーではなくエンジニアと呼んでいることに違和感を覚えた。

2024/07/07

直訳？　翻訳が下手
　翻訳の質はそこまで良くないが、読める。しかし、翻訳が下手。これなら原文で読んだ方がいい。

読みづらい例：
《ソフトウェアについて考えるとき、特定のシナリオから回復するための現実的な方法があるかを考えることが必要な場合は多くあります。》

直すとすれば：
《特定のシナリオからソフトウェアが回復する具体的な方法を考えねばならない機会が多い。》

2024/01/08

3年目までの若手エンジニアに向けた、悪い例とその対策について多くまとめられている。具体的に類似の場面に遭遇した際に読み返すのが良い。

達人プログラマーにもある契約プログラミングやら何やらの話が出てくる。教養として本書と達人プログラマー、プリンシプルオブプログラミングは読んでおくべきかも。

なお、MANNINGの電子版は固定レイアウトなので、ハイライトやメモができない。PDFやEPUBで欲しい。

【ポイント】
・コメントやドキュメントは目を通される保証がない。関数の名称や引数、戻り値の型などで内容を明確にすること。
・問題発生個所の近くでエラーを出すことで早く、可能なら目立つ（ログ送信やクラッシュなど）失敗をさせ、早期対策をする。
・Null返却やログ出力などでエラーを隠すのではなく、問題に応じた暗黙的・明示的エラー通知を用いることが望ましい。
・読みにくいコードは時間×人数で悪影響する。読みやすくすることで冗長になることがあるが、大抵の場合はメリットが上回る。
・単体テストは重要な機能を一つずつテストする。パブリックAPIに注目して行う。

2023/12/26

著者、監訳者、訳者のまえがきを読むと、本書を読むと良いことが起きそうだという気がしてワクワクさせられる。そして重要なことだけれど、本書に書かれたことがどんな場合でも当てはまるとは言えないし、そのまま当てはめられる場面も稀であることが書かれていて好印象。各章のまとめはときどき読み返すと役に立ちそう。HOW（どのように）よりもWHY（なぜ）が重要。どのように書くかではなくて、なぜそう書いた方が良さそうかに思いを巡らせながらコーディングをするのが大事。第2章実践編、第3章ユニットテスト編で顕著だけれど、チーム開発で他の人と一緒に開発を行うがゆえに、いろいろと気をつけたほうが良い点が出てくる（未来の自分も他人だと考えれば一人開発の場合も当てはまる）。他の人（未来の自分も含む）からそのコードがどんなふうに見られるかを想像することが重要。

2023/11/05

悪いコードはなぜ悪く、良いコードはなぜ良いのか、理由を丁寧に述べながら実際のコード例を示している点が分かりやすい。
自分が似たような書籍を色々読んでいることもあって同じようなことを言ってるな〜と感じる部分は多いが、実践した方が良いプラクティスはあまり変わらないということなのだと思う。
エラーを通知するテクニックについて、例外とnull許容型の扱い方は勉強になった。「ない」ことを示すのに明示的にnullを返すの、近年は良しとする感じなんですかね。