Good Code,Bad Code 持続可能な開発のためのソフトウェアエンジニア的思考

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

• 販売会社／発売会社: 秀和システム
• 発売年月日: 2023/01/28
• JAN: 9784798068169

商品レビュー

2024/11/10

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

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

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

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

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

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

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

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

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

2024/07/01

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

2024/06/25

オブジェクト指向のリファクタリング
　オブジェクト指向専用。だからJavaScriptとかには無用の本だが、まあ悪くはない。
　かなり具体的に書いてある。nullの戻り値、エラーの伝達など、しっかり考慮しないと、他人が勘違ひしますよ。と当り前のことを自覚させられる。

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

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

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