【ちゃんなるぶろぐ】社会人1年生が日々の学びをアウトプット!

>>> 読書・遊び・プログラミング・アプリ開発などを通して学んだことを、文章という形で出力 <<<

3分でわかる!「プログラマが知るべき97のこと」その⑦

読み終えるまで約3分

 

 

どうも、ちゃんなるです! 

今回も、"デキる"プログラマを目指し、学んでいきましょう!

 

今回は、次の書籍の一部を要約します。

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

今回選択した3つのテーマ

本書はタイトル通り97のことについて書かれています。

今回は、19~21番目の項目についてまとめます。

  1. 誰にとっての「利便性」か(No. 19)
  2. すばやくデプロイ、こまめにデプロイ(No. 20)
  3. 技術的例外とビジネス例外を明確に区別する(No. 21)

 

①誰にとっての「利便性」か

 

このテーマで述べられていたことは、

「メソッドは実装者側の利便性だけでなく、呼び出し側の利便性を考慮して作成するべきである。」

ということです。

 

以下、要約です。

 

優れたAPIを設計するのは難しいです。

最初から適切な設計をするのが難しく、かつ、後から変更を加えることも難しいからです。

以下の3つは、API設計者が作業時に言いそうなことです。

どの意見も「利便性が高い」と正当化されやすいです。

  • ほとんど同じ目的の呼び出しコードがクラスAにすでに存在するのに、クラスBに新たに呼び出しコードを持たせる必要はないのではないか。
  • 目的がほぼ同じメソッドがすでに存在するのであれば、わざわざ新たなメソッドを作る必要はないのではないか。switch文を追加するくらいでいいのではないか。
  • 2番目の文字列パラメータが".txt"となっていれば、自動的に、第1パラメータはファイル名であるとみなして構わない。したがって、メソッドを2つ作る必要はない。簡単な話だ。

(本書38ページより)

どれも善意から出た意見ですが、こういった意見に従ってAPIを作成すると、APIを使用したコードが読みにくくなってしまう」問題が起こります。

 

例えば、次のようなメソッド呼び出しになります。

parser.processNodes(text, false);

おそらくAPIの内部を知らない人は、理解に苦しむでしょう。

社内Wikiなどが整備されていればかろうじてわかるかもしれませんが…

 

メソッドを実装する側は、自分たち実装者の利便性だけでなく、呼び出す側の利便性も考慮するべきなのです。

 

APIを作成するとき、細かいメソッドを複数書くより大きなメソッドにまとめてしまった方が確かに便利です。

しかし、使う側にとっては便利でしょうか?

 

クラスやメソッドの実装は、呼び出し側のことを考えて実装しましょう!

 

 

②すばやくデプロイ、こまめにデプロイ

このテーマで述べられていたことは、

「インストールやデプロイ作業をして初めて顧客が製品に触れることができる。納期や品質を担保するためにもこまめにデプロイし、常に『顧客の環境で動くか』を意識しよう!」

ということです。

 

以下、要約です。

 インストールやデプロイに関わる作業は後回しにされがちです。

レビューやデモの際にインストールやデプロイができていることは確認するはずです。

しかし、そのときは単に『間に合わせ』になっていませんか?

 

『間に合わせ』というのは、とりあえず動く状態を見せれていることであり、顧客の環境では正常に動かない可能性が残っていることを意味します。 

 

デプロイ関連の作業を後回しにすると、アプリケーションやそのコードが開発環境やテスト環境に依存したものになりやすいです。

 

次のことを覚えておいてください!

ターゲット環境でのデモができるようになってはじめて、ソフトウェアはビジネス上の価値を持ちます。

「開発者のコンピュータで一応動作する」という状態から、「デモが可能である」という状態にするまでには、相当な作業が必要になるのです。

(本書40ページより)

 

余程の理由がない限り、デプロイ作業は早い段階からこまめにやりましょう。

デプロイ作業が複雑であったり不確定要素が多い場合は、デプロイ作業の実験、評価、リファクタリングを必要に応じて行なっていけば良いです。

 

 

③技術的例外とビジネス例外を明確に区別する

このテーマで述べられていたことは、

「例外には『技術的例外』と『ビジネス例外』の2つがあり、それらの例外処理は同じ階層で扱ってはいけない。」

ということです。

 

以下、要約です。

 

プログラムの実行時に起きる問題は、次の2つに分けることができます。

  1. 技術的な原因によるもの:発生するとアプリケーションの実行そのものが続けられなくなる問題
  2. ビジネスロジックによるもの:ユーザがアプリケーションの使い方を誤らないために(わざと)発生させる問題

モダンなプログラミング言語では、この2種類の問題の発生を通知するために、『例外(Exception)』を使用します。

 どちらも例外と一括りにされがちですが、この2種類の問題は混同しないように注意する必要があります。

 

【技術的な問題】

プログラムコード内の誤りのことです。

例えば、『要素が10個しかない配列の11番目の要素にアクセスする』や、『String型の引数にDictionaryの変数を渡した』などがわかりやすいでしょう。

 

この種の例外は自分の手で書くのは良くありません。

自分で捕まえずにトップレベル、アーキテクチャレベルまで通過させてトップレベルの例外処理に任せましょう。

トップレベルの例外処理では、システムを正常な状態に戻す処理をします。

例えば、トランザクションロールバック、ログの作成、管理者への警告、ユーザへの通知です。

 

また、ライブラリ内で問題が発生した場合も同様です。

引数が不適切であることが主な問題として考えられます。

この場合は、呼び出し側で例外を発生させ、対処するべきです。

 

ビジネスロジックの問題】

これは、業務ロジックの判断によりプログラムの実行が中断されるような状況のことです。

例えば、「ユーザが、預金額を超える額のお金を口座から引き出そうとした」のような問題です。 

この問題の例外処理は、あらかじめクライアント側に対処するコードを組み込んでおく必要があります。

発生させる例外は、技術的な問題の例外とは違う構造に属するようにしましょう。

システム全体に影響を与えず、クライアント側だけで対処するのです。

 

 

「技術的例外」「ビジネス例外」を同じ例外階層構造で扱うと、両者の区別が難しくなります。

例外が発生したときに、プログラムのエラーによるものか、ビジネスロジックによるものか分からなくなります。

それゆえ、クライアントのコードで処理するべきか否か判断できなくなるでしょう。

2種類の例外を明確に区別しておけば、このようなことは起きません!

 

まとめ

①メソッドやクラス、モジュールを作成する際は、『自分たちが実装しやすい構成かどうか』ではなく、『呼び出す側が理解しやすいかどうか』を意識しましょう!

『利用者の環境で動くかどうか』が目的であり、『開発者の環境で一応動いている』状態では不完全です。こまめにインストールやデプロイを行い、予期せぬバグをなるべく抑えましょう!

『技術的例外』『ビジネス例外』は明確に区別しよう!特に『ビジネス例外』では、その対処処理をクライアント側で実装しておき、システム全体とは切り離すことが重要です。

 

*より深く知りたい方は、ぜひ本書を手にとってみてください!

書籍情報

プログラマが知るべき97のこと [ ケブリン・ヘニー ]

価格:2,090円
(2021/5/13 11:12時点)
感想(1件)

 

【中古】 プログラマが知るべき97のこと /ケブリンヘニー【編】,和田卓人【監修】,夏目大【訳】 【中古】afb

価格:825円
(2021/5/13 11:12時点)
感想(0件)

【書籍名】プログラマが知るべき97のこと

【著者名】ケブリン・へニー、夏目大(訳)

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ