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

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

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

読み終えるまで約5分

 

 

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

今日も”デキる”プログラマになるべく勉強していきましょう!

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

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

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

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

  1. 冗長なログは眠りを妨げる(No. 85)
  2. WETなシステムはボトルネックが見つかりにくい(No. 86)
  3. プログラマとテスターが協力してできること(No. 87)
①冗長なログは眠りを妨げる

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

「本当に重要な問題が起きたことのみを知らせてくれる情報だけを、ログに含めるのが理想である。」

ということです。

 

以下、要約です。

開発中、または製品として稼働中のシステムがあるとします。

この時、すぐに目につく問題があるとすれば、まず「ログが汚い」ことではないでしょうか?

たとえば、Webページのリンクをクリックしただけなのに大量のログが出力される、というようなことです。

 

ログの情報が膨大だと、ログがないのと同じくらい役に立ちません。

 

私たちプログラマは、開発したシステムが「長生きしてほしい」「ずっとユーザの役立つ存在であってほしい」と望みます。

しかし、システムが稼働すれば問題が起きることもあり、私たちはそれをどうやって察知し対処すればいいのでしょうか。

ここで役立つのがログで、システムになんらかの問題が生じた場合はログに残ったメッセージでその問題の発生を知ることになります。

 

ログが、不要情報を含んでいたり、あまりに多くの情報を記録していたりすると、システムの監視には役立たなくなってしまいます。

本当に重大な問題が起きた場合以外、基本的にエラーログには何も記録されない、というくらいの方がいいでしょう。

その場合、エラーログにメッセージがあることがシステムに重大な問題があると判断することになるからです。

②WETなシステムはボトルネックが見つかりにくい

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

DRY原則を守ことで、パフォーマンスのボトルネックの発見とその解消が容易になる。ぜひDRY原則を徹底しよう!」

ということです。

 

以下、要約です。

DRY(Don't Repeat Yourself:同じことを繰り返すな)原則は、『1つのシステムの中で同じものが重複することがあってはならない』という原則で、非常に重要な原則の一つです。

DRY原則に反しているシステムを、『WET :(Write Every Time:必要なものを都度書く)』なシステムと呼ぶことがあります。

 

たとえば、あるシステムに、CPUボトルネックになっている機能があるとします。その機能を仮に、「機能X」と呼ぶことにします。そして、機能XがCPUの30%を消費しているとしましょう。

もし機能Xに10種類の実装があるとしたら、ここの実装は、平均してCPU3%を消費しているということになります。この場合は、じっくり見なければ、機能Xがボトルネックになっていることに気づきにくいでしょう。3%のCPU消費自体は多くないからです。

また、仮に機能Xがボトルネックであると認識できたとしても、10種類の実装をすべて見つけ、ここに修正を施さなくてはならないという問題があります。

1つの機能の実装が10種類存在するのは、WETなシステムであると言えます。もしDRY原則に従ってシステムが作られていれば、機能XがCPUを30%消費している事実にすぐに発見できる上、修正するコードも1/10で済むでしょう。そもそも、10の実装をすべて見つけ出すための時間も手間も必要ありません。

(172ページより)

 

DRY原則を守ことで、パフォーマンスのボトルネックの発見とその解消が、WETな場合に比べて容易になります。

 

DRY原則については本書でも触れられており、下記の記事に要約しています!

chan-naru.hatenablog.com

chan-naru.hatenablog.com

プログラマとテスターが協力してできること

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

プログラマとテスターは、「システムを通じて顧客に最高の体験を提供する」という同じ目的を持つ。協力し合おう!」

ということです。

 

以下、要約です。

プログラマとテスターが協力し合えば、まず問題管理すてむを使ってバグ情報をやり取りする時間、そして「バグなのか、それとも新機能なのか」を見極める時間が減らせます。

そうして浮いた時間を、ソフトウェアの機能拡充や顧客の要望に応えることに使えます。

 

両者の協調の機会は数多くあり、またそれはコーディング開始前から始めることも可能です。

 

例えばテスターは、顧客と協力して顧客ドメインの言葉で受け入れテストを書き、それを自動化します。

そしてそれを開発着手前のプログラマに共有することができ、プログラマATDD*を実践できます。

共有された時点で、プログラマが何かフィードバックを返すこともできます。

*Acceptance Test-Driven Development:受け入れテスト駆動開発

 

 

テスターに技術的な知識がないと、独立性の低いテスト項目ができることが多いです。

設計が悪いテストとは、不要なテスト項目が多すぎるものや、テスト項目の独立性が低いものなどです。

ぜひテスターはプログラマと協力して良質なテストを作成しましょう。

 

テスターは、自分の仕事はプログラマの書いたコードからバグを見つけ出すことである、という考え方は捨てるべきです。

そしてプログラマは、テスターは自分たちの邪魔をする敵だ、などと考えるてはいけません。

一緒に、顧客に最高の体験を届けるにはどうすればいいか、を考えるのです。

まとめ

①本当に重要な問題が起きたことのみを知らせてくれる情報だけを、ログに含めるのが理想です!あなたの開発するシステムのログは、とんでもないことになっていませんか?

WET、ダメ、絶対

プログラマとテスターは、「システムを通じて顧客に最高の体験を提供する」という同じ目的を共有しています!お互いがお互いを高めてくれると認識しましょう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ