きのこ本 感想 Part7

プログラマが知るべき97のこと

こと、きのこ本の感想、Part7です。今日は19〜21のエッセイについての感想を書いていきます。

19 誰にとっての「利便性」か (グレゴー・ホーペ, Gregor Hohpe)

これはよくある話ですね。プログラマ ( 作る側 ) にとって便利でも、ユーザ ( 使う側 ) にとっては全く便利ではないものを作らないようにすべきである、という話。

今回のエッセイではAPIについて語られていますが、いろんな場面でいえることですね。

APIはドキュメントを見れば分かるようにするというのは、最低限必要だと思うのですが、できれば使用した場合にも後で一体何をするコードなのか分かりやすいようになっていてほしいですね。

エッセイに書かれているような例でいうと

walk(true)

のようなコードよりは

run

のほうがいいという感じですね。

実際、「歩く」と「止まる」を

walk(true)
walk(false)

とかにされるよりは

walk
stop

のようになっていてほしいですね。

作る側からすると、一種のラッパー関数やラッパークラスなどが増えるのでまったくもって利便性はないと思うのですが、ユーザからすると大量のプロパティを指定させられるより ( 特に考えられた命名のもとでは ) 複数の関数やクラスに分割されている方が楽だったりしますね。

などと他人事のように言っていますが、自分も作る側に回った時にはしっかり注意しないといけませんよね。

20 すばやくデプロイ、こまめにデプロイ (スティーブ・P・バーチャック, Steve Berczuk)

こういうことはあまりやったことがないので詳しくはないのですが、本番の環境と開発環境が異なるというのはよく聞く話です。

そして、そのような場合に後回しにされたデプロイで問題が発生するというのも、よく見かける話です。

こういったことを防ぐために、「すばやくデプロイ、こまめにデプロイ」ということなのでしょう。

テストやリファクタリングと同じように後回しにされたデプロイで問題を起こしたりすることのないように、インストールやデプロイのプロセスも早い段階から進めていくべきみたいですね。

21 技術的例外とビジネス例外を明確に区別する (ダン・バーグ・ヨーンソン, Dan Bergh Johnsson)

例外についての話ですね。

例外は大体の言語で実装されているものですよね。配列の要素数を超えて参照を行おうとした場合などに発生しますね。

技術的例外とはプログラムの間違いによって発生する例外のことで、ビジネス例外というのはロジックにより発生された例外のことのようです。

つまり技術的例外は根本的にコードの誤り、バグによって発生しているもので、ビジネス例外は組み込まれたロジックを担う「正しい」コードの一部であるということでしょうか。

技術的例外は基本的にはクライアントコードで処理することはしないようにします。そのままトップレベル、アーキテクチャレベルまで通過させるのが普通です。 ( Exceptional C++ で出てきた ) 例外中立の立場から考えれば、クライアントコードで処理しなければ、もちろんトップレベルまで通過させますよね。

ビジネス例外はもちろんクライアント側で処理するべきですが、ここでエッセイではこの例外は状況に合わせて新たな例外を定義するか、技術的例外とは異なる階層構造に属する例外にすべきだと書かれています。同じ例外で処理されていると確かに混乱のもとですね。

最後に

今回も2ページのエッセイに意識すべきこと、重要なことが書かれていました。

・「利便性」というのは、基本的に「ユーザ」の利便性であるということを意識すべし。
・デプロイはテストやリファクタリングと同じく、早く素早くこまめに。
・技術的例外とビジネス例外の2つの例外を区別して、それぞれに合わせた処理を行う。

このきのこ本のエッセイを読んでいると、自分が学んだことの中にも色々生かせることがあるということに気づかされます。ただ、それを生かすためにはしっかり意識しないといけない。そんなときにこういう本があると便利だと思います。