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

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

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

読み終えるまで約5分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

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

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

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

  1. コードは生涯サポートするつもりで書く(No. 88)
  2. 関数の「サイズ」を小さくする(No. 89)
  3. コードを見る人のためにテストを書く(No. 90)
①コードは生涯サポートするつもりで書く

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

「書くコード1行1行が今後の自分のキャリアを決める、という意識を持って日々のコーディングに向き合おう。」

ということです。

 

以下、要約です。

本書『プログラマが知るべき97のこと』では、実にさまざまな情報や知識、ベストプラクティスが語られています。

どれも重要で、身になるものですが、なかなか個別で実践するのは難しいかもしれません。

 

そんな時は次のように考えるといいでしょう。

いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。

(176ページより)

もし本当に生涯サポートしなければならないなら?

以前勤めてた会社、あるいは今の勤務先から真夜中に電話がかかってきて「なぜこのコードを書いたの?理由を説明して!」と言われても文句を言えないとしたら?

 

「そんな問い合わせを受けないようなコードを書きたい」と思うはずです。

そしてそのために、あらゆる情報・知識・ベストプラクティスを駆使して最高のコードを書こうと努力するはずです。

 

コードを書く度に、ユーザのこと、顧客のこと、そして自分のキャリアのことを考え、「このコードは自分の人生を決めるんだ。」と思ってコーディングに臨みましょう。

②関数の「サイズ」を小さくする

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

「問題領域についての知識を基に関数を作成し、その関数で確認するべきパターンの数をどれだけ減らすことができるかを考えることが重要である。」

ということです。

 

以下、要約です。

自分の書いたコードが正しいという証拠の一つに、(数学関数における)「サイズ」という指標があります。

 

例えば、囲碁における「アタリ」の状態を判定するプログラムを書くとします。

アタリ:相手に石を囲まれ、撮られる一歩手前の状態のこと)

そこで次のような関数を書いたとしましょう。

 

boolean atari(int libertyCount)

    libertyCount < 2

 

数学関数は、引数値intと戻り値booleanがとりうる値の組み合わせの部分集合と捉えることができます。

詳細は省きますが、JavaでのInt×Booleanの集合には、8,589,934,592個の要素があります。

関数が完全に正しいと証明するには、これらの要素全てを調べる必要があります。

 

ここで助けになるのが問題領域についての知識です。

囲碁の場合、石の周りの隙間の数は{1, 2, 3, 4}のいずれかなのです。

つまり、上の関数は下記のように書き換えられます。

 

LibertyCount = {1, 2, 3, 4}

boolean atari(LibertyCount libertyCount)

    libertyCount == 1

 

数学関数は、最大で8つの要素を持つだけの集合になりました。

これだとはるかに扱いやすく、8つの例を調べるだけで関数が完全に正しいという証拠が得られます。

 

問題領域固有の型を使うと、関数の「サイズ」を大幅に小さくできる場合が多いです。

関数を書く際はまず、問題領域についての知識を基に確認すべき例の数をどこまで減らせるかを考え、どの型を使うべきかを決定しましょう。

③コードを見る人のためにテストを書く

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

「まずテストを書くことは素晴らしいことである。そして、そのテストが他者がコードを理解しやすいように書いてあるならば、なお素晴らしいことである。」

ということです。

 

以下、要約です。

「製品版コード一つ一つについて、必ず自動化テストを書くようにしている」

「テストは、いつもコードを書き始める前に書くようにしている」

このような人がいれば素晴らしいです。

 

「テストを書くこと」はいいことですが、そのテストが「いいテストである」ことはどうやって判断すればいいのでしょう?

「自分は誰のためにテストを書いているのか?」と自問するのが1つの方法でしょう。

もしその答えが「自分のため。バグ修正の労力を少しでも減らすため。」なら、いいテストがかけてる可能性は高くないでしょう。

 

ではいったい誰のためにテストを書けばいいのでしょう?

それは、「コードを見る人のため」です。

いいテストはドキュメントとなり、「このコードはどう動くのか」を教えてくれます。

 

いいテストの条件

  • コンテキスト、出発点、満たすべき事前条件がわかる
  • ソフトウェアがどのように起動されたかがわかる
  • 期待される結果と、確認すべき事後条件がわかる

実際にテストを書いたら、そのテストを、テストで対象としているコードについて全く知らない人に見てもらうといいでしょう。

もしその人がコードについてよく理解できてないとしたら、そのテストがわかりやすいものになっていないということになります。

まとめ

コード1行1行を書く経験が、自分のキャリアを形成するのです!(と思って生きていくといいよ)

②ある関数を作成するときは、その関数で確認するべきパターンの数をどれだけ減らすことができるかを考えることが重要です!そのためにはまず、その関数で解決する問題領域を適切に理解することが重要となります!

③テストを書くことは重要であり、また、それがいいテストであるとさらに素晴らしいです。テストは、「他者がそのテスト対象のコードに対して容易に理解できる」ように書きましょう。

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

【Privacy Policy】資産運用シミュレータ

Privacy Policy Privacy Policy

Narumi Nogawa built the 資産運用シミュレータ app as an Ad Supported app. This SERVICE is provided by Narumi Nogawa at no cost and is intended for use as is.

This page is used to inform visitors regarding my policies with the collection, use, and disclosure of Personal Information if anyone decided to use my Service.

If you choose to use my Service, then you agree to the collection and use of information in relation to this policy. The Personal Information that I collect is used for providing and improving the Service. I will not use or share your information with anyone except as described in this Privacy Policy.

The terms used in this Privacy Policy have the same meanings as in our Terms and Conditions, which is accessible at 資産運用シミュレータ unless otherwise defined in this Privacy Policy.

Information Collection and Use

For a better experience, while using our Service, I may require you to provide us with certain personally identifiable information. The information that I request will be retained on your device and is not collected by me in any way.

The app does use third party services that may collect information used to identify you.

Link to privacy policy of third party service providers used by the app

Log Data

I want to inform you that whenever you use my Service, in a case of an error in the app I collect data and information (through third party products) on your phone called Log Data. This Log Data may include information such as your device Internet Protocol (“IP”) address, device name, operating system version, the configuration of the app when utilizing my Service, the time and date of your use of the Service, and other statistics.

Cookies

Cookies are files with a small amount of data that are commonly used as anonymous unique identifiers. These are sent to your browser from the websites that you visit and are stored on your device's internal memory.

This Service does not use these “cookies” explicitly. However, the app may use third party code and libraries that use “cookies” to collect information and improve their services. You have the option to either accept or refuse these cookies and know when a cookie is being sent to your device. If you choose to refuse our cookies, you may not be able to use some portions of this Service.

Service Providers

I may employ third-party companies and individuals due to the following reasons:

  • To facilitate our Service;
  • To provide the Service on our behalf;
  • To perform Service-related services; or
  • To assist us in analyzing how our Service is used.

I want to inform users of this Service that these third parties have access to your Personal Information. The reason is to perform the tasks assigned to them on our behalf. However, they are obligated not to disclose or use the information for any other purpose.

Security

I value your trust in providing us your Personal Information, thus we are striving to use commercially acceptable means of protecting it. But remember that no method of transmission over the internet, or method of electronic storage is 100% secure and reliable, and I cannot guarantee its absolute security.

Links to Other Sites

This Service may contain links to other sites. If you click on a third-party link, you will be directed to that site. Note that these external sites are not operated by me. Therefore, I strongly advise you to review the Privacy Policy of these websites. I have no control over and assume no responsibility for the content, privacy policies, or practices of any third-party sites or services.

Children’s Privacy

These Services do not address anyone under the age of 13. I do not knowingly collect personally identifiable information from children under 13 years of age. In the case I discover that a child under 13 has provided me with personal information, I immediately delete this from our servers. If you are a parent or guardian and you are aware that your child has provided us with personal information, please contact me so that I will be able to do necessary actions.

Changes to This Privacy Policy

I may update our Privacy Policy from time to time. Thus, you are advised to review this page periodically for any changes. I will notify you of any changes by posting the new Privacy Policy on this page.

This policy is effective as of 2021-11-20

Contact Us

If you have any questions or suggestions about my Privacy Policy, do not hesitate to contact me at narutyan0711@gmail.com.

This privacy policy page was created at privacypolicytemplate.net and modified/generated by App Privacy Policy Generator

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ページ

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

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

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

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

  1. 他人への思いやりを意識したコーディング(No. 82)
  2. UNIXツールを友にする(No. 83)
  3. 正しいアルゴリズムとデータ構造を選ぶ(No. 84)

 

①他人への思いやりを意識したコーディング

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

「他者への思いやりの気持ちを持った上で、良質なコードを追求しよう!」

ということです。

 

以下、要約です。

プログラマは1人で作業することが多いので、ついつい自分だけの解釈でコードを書きがちです。

しかし、他人がコードを拡張することもあるし、自分の書いたコードに依存して誰かがコードを書くこともあるという『ソフトウェア開発の社会的側面』を忘れてはいけません。

ソフトウェアを作るには技術が必要ですが、人との関わりも重要です。

 

人との関わりにおいてコミュニケーション能力が重要なのは言うまでもないでしょう。

そしてプログラマ同士のコミュニケーションの一つはプログラムコードです。

自分のコードが良質であると思っても、他のプログラマの存在を意識することでさらに改善できる余地が見つかるかもしれません。

 

プログラマ他者への思いやりを持たずにコードを書くことはありえない、ということを忘れてはいけませんよ!

 

 

UNIXツールを友にする

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

UNIXツールはIDEに比べ、できることの幅がとっても広い。UNIXツールを身につけることで、自分の表現できる技術の幅が格段に広がる!」

ということです。

 

以下、要約です。

もし無人島にIDEUNIXツールのどちらかしか持っていけないとしたら、迷わずUNIXツールを選びます。

なぜなら、UNIXツールは自分の発想次第でなんでもできるからです。

IDEはその開発者の考えたコマンドしか使えませんが、UNIXツールはそうではないのです。

 

UNIXツールの処理はシェルスクリプトにまとめることができ、シェルスクリプトならパイプを使ってコマンドの処理結果をループや条件分に渡すことができて非常に便利です。

さらに素敵なことに、UNIXコマンドはパイプライン処理として動作するので、現在のマルチコアCPUの場合は、複数のコアに負荷が自然に分散されるのです。

 

UNIXツールを学んでみてはいかがでしょうか?

 

 

③正しいアルゴリズムとデータ構造を選ぶ

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

「「動けば良い」ではなく適切なデータ構造・アルゴリズムを選択肢して「このデータ構造・アルゴリズムはこのように機能する」と深く思考しながらコーディングをできるのが理想。」

ということです。

 

以下、要約です。

「まずは動かすこと。早くするのはその後でいい」という格言があります。

局所的な最適化の落とし穴を避けるためには、この格言を心に留めておくことが大切でしょう。

しかし、「遅くてもいいから動かせ」という発想でコードを書いてはならず、たとえば下記のようなコードが生成されるでしょう。

 

for (i = 0; i < strlen(s); ++i) {

    if (... s[i] ...) ...

}

*文字のsは平均で数千文字の長さになる

 

このコードでは、strlenが呼び出されるたびに終端のnull文字に到達するまで、文字列sの中の一文字一文字が調べられることになります。

もしループ内でsに変更を加える必要がないならば、下記のようにするべきです。

 

n = strlen(s);

for (i = 0; i < n; ++i) {

    if (... s[i] ...) ...

}

 

先のような浅はかなコードを書かないためには、既存のアルゴリズムについて、またそのスケール特性について学ぶ必要があります。

プログラミングでは度々、「再利用」の重要性が説かれます。

しかし、いつ、何を、どのように「再利用」するかを理解しないと、いい結果は得られません。

それを理解するために、問題領域について、またアルゴリズムとデータ構造についての十分な知識が必要なのです。

 

 

まとめ

①いわゆるコーディングにおけるベストプラクティスを実践することは大事であるが、それだけでなく他者への思いやりを込めてコーディングすることが大切!

UNIXツールを使うことは、大袈裟にいって「所望の処理がなんでもできる」ということです!ぜひ学んでみましょう。

アルゴリズムとデータ構造の知識は、ソフトウェアのパフォーマンスというところに直結する。いいものを追求するというより、ダメなものを避けるという考えがいいでしょう。

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

 

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

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

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

  1. テストのないソフトウェア開発はあり得ない(No. 79)
  2. 1人より2人(No. 80)
  3. エラーがエラーを相殺してしまう(No. 81)
①テストのないソフトウェア開発はあり得ない

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

「テストをすることは、作るものに責任を持つことである!」

ということです。

 

以下、要約です。

建築・土木作業で建設する橋のような形のあるものを「テスト」するのは大変です。

「テスト」をするにはまず作る必要があり、しかし作るにはコストがかかり、一旦作ったものを壊したり作り直したりできないからです。

 

一方ソフトウェアの場合、「とりあえず作る」が橋に比べて圧倒的低コストで行えます。

また、「テスト」を容易に進める手法・ツールが数多く生み出されており、ユニットテスト、モックオブジェクト、テストハーネスなどはその例です。

他の分野では、まず実際のものを作って現実の環境下で「テスト」をしますが、ソフトウェアの場合は作りながら「テスト」する、「テスト」しながら作るということをします。

テストが品質保証のための第一手段なのです。

 

こう考えると、「テストなんてしている時間はない!」と言い放つマネージャは非常に困った存在ですね。

橋の建設をする技術者が、上司から「今回は構造解析しなくていいよ!なにしろ工期が迫っているからね」と言われることがあるでしょうか?笑

こう考えると「テストなんてしてられない」という人はとても無責任であることになります。

 

「テスト」をすることは、作るものに責任を持つということです。

「テスト」をすれば十分というわけでは決してありませんが、まず「テスト」をしないと話にならないというくらい「テスト」は重要なのです。

②1人より2人

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

プログラマは一匹狼の仕事ではなく、他者と協力して行う仕事である。」

ということです。

 

以下、要約です。

プログラミングには、1人でじっくり考えることが必要…プログラミングは1人で作業するというステレオタイプはそこから生まれたのでしょう。

そこから、プログラマは技術力が高ければOKである、と考えるひとも出るのでしょう。

しかし、実際は複数人で協力して何かを作り出すということが仕事であり、プログラマ同士の連携だけでなくプログラマでない人たち(例えばビジネスアナリスト、システムアナリスト、QA担当者、ユーザなど)との関係も密にするべきです。

 

つまり、プログラマはもはや、技術が優れてるだけでは十分でないのです。

 

プログラマをしていると、どうしても技術力を高めることに目が行きがちになります。

しかし、それだけではなく「どうやったら他者と協力して問題解決できるか」と考えるべきです。

 

プログラマとして他者と協力するアプローチの一つに、「ペアプログラミング」があります。

ぜひやってみてはいかがでしょうか?

お互いの学びになるし、何より1人では出せない解決策が出せる可能性があります。

③エラーがエラーを相殺してしまう

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

「複数のエラーがお互いを隠蔽してしまい、改修が非常に困難になる。このような状況があることを認識しよう。」

ということです。

 

以下、要約です。

コードは必ず書いた通りに動きます。

しかし、別の箇所で書いたことが矛盾している場合に思わぬ動きをする場合があります。

 

表面上起きてる問題は1つなのに、それに関わっているコードが2箇所ある場合、一つ一つ不具合を修正していくという方法で対処していくと問題が解決しない恐れがあります。

バグの報告を受けると、プログラマは原因となる箇所を見つけ出して修復し、テストをします。

バグの原因となっていたコードが元々2箇所だったとしたら、それでは問題は解決しないでしょう。

2つ目の不具合は修正されていないからです。

その場合は、最初の修正は一旦元に戻し、またコードを調べて別の不具合を探すことになるでしょう。

それで2つ目の不具合を見つけ出し、修正をしたとします。

しかし、1つ目の不具合の修正は元に戻っていますから、やはり問題は解決しません。

問題が解決しなければ、修正は元に戻されることになります。

これが何度か繰り返されることも多いですが、やがて人によっては、どちらの不具合も問題には関係ないとみなし、第3の不具合を探し始めることもあります。

しかし、それが見つかることは決してないのです。

(163ページより)

 

カオスです。

表面上1つに見える問題が2つのコードの相互作用で生じている場合は、原因箇所の特定が難しく袋小路に入ってしまうことが珍しくありません。

このような問題に「こうすればOK」という解決策はありません。

大切なのは、このような問題が起きうると認識した上でバグ修正作業に入るということでしょう。

 

まとめ

「テスト」超重要

プログラマは孤高の戦士ではなく、他者と協力して問題解決を行う仕事である!

③複数のエラーが重なってエラーが起きてるように見えなくなってしまう。エラーがエラーを相殺してしまう。それによってエラーの改修が困難になる状況があるのです。

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

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

読み終えるまで約3分

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

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

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

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

  1. コード分析ツールを利用する(No. 76)
  2. 偶然の仕様ではなく本物の仕様のためのテストを書く(No. 77)
  3. テストは夜間と週末に(No. 78)
①コード分析ツールを利用する

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

「テストは重要だが、コード分析ツール(いわゆるlint)も積極的に活用しよう!」

ということです。

 

以下、要約です。

近年では、ユニットテストやTDD(テスト駆動開発)、アジャイル開発などが広く行われるようになり、開発サイクルのあらゆるフェーズでテストを最大限活用するという考え方を受け入れる人も増えました。

しかし、テストがいかに重要といえど、それがコードの品質を高める唯一の方法というわけではないのです。

 

昔に比べ現在は、コンパイラ自身がチェックできるエラーも増え、ほぼ全ての言語でスタイルガイド違反やバグ検出をするためのツール(いわゆるlint)が用意されています。

中には設定をいじれるものもあり、検出するエラーや警告の種類を選ぶことができるのです。

 

コードの品質向上にあたっては、テストだけに頼るのではなく、解析ツールも積極的に利用すべきです!

②偶然の仕様ではなく本物の仕様のためのテストを書く

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

「現状のコードを正しいと思ってテストコードを書くのは危険。テスト対象のコードの中身ではなく、外から見た動きに注目してテストを書こう!」

ということです。

 

以下、要約です。

テストをする際の典型的な落とし穴は、現状の実装コードのあまりに細部に至るまで厳密にテストしてしまうことです。

実装コードには、「実装の都合でたまたまそうしている」という箇所が多々あり、そこをテスト対象としても意味がないのです。

また、そのようなコードの偶然の仕様がテスト対象となっていると、本来の仕様に沿うよう改良を加えることがテストを失敗させる可能性があります。

テストを修正するにしても、本物の仕様にあっているかを確認するよう修正すればいいが、コードの改良より新たに生じた偶然の仕様に合わせて修正しては意味がありません。

「本当にテストすべきことは何か」をよく考え、的確なものにする必要があるのです。

 

細かすぎる仕様に囚われてテストを書いてしまう傾向は、ホワイトボックスアプローチのユニットテストでよく見られます。

ホワイトボックステストでは、どのようなテストケースが必要か判断する際、コードの構造を手がかりにします。

それゆえ、現状のコードが正しいと判断しやすいのです。

この対策にはブラックボックステストが有効です。

テスト対象のコードの中身ではなく、外から見た動きに注目してテストを書きましょう。

③テストは夜間と週末に

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

「夜間や週末に自動でテストすることで、効率的にソフトウェアのテストが実行できるのです!」

ということです。

 

以下、要約です。

夜間や週末にはテストサーバを動かしてないところは多いでしょう。

ぜひ動かして、日々の業務中にテストをする時間を削減してはどうでしょうか。

 

日々の業務時間中ではテストに割いている時間がないと思って下記のような状況を経験したことがある人もいるのではないでしょうか?

  • 罪悪感を感じながらも、テストを全て実行する前に変更をコミットしてしまった
  • 製品の安定性をテストする機会がそもそも十分でない
  • パフォーマンステストもなかなか実施する時間が確保できず、やってない
  • 順列組み合わせをさまざまに変えてテストする必要がある場合は手作業では対応が困難で、それゆえやっていない

 

スクリプトの知識が少しあれば、自動テストの仕組みを作ることができます。

基本はcronを使ったスケジューリングです。

数多のテスティングツールも提供されています。

リソースを効率よく利用できるように、グリッドコンピューティングによってサーバを分散させている企業もあります。

まとめ

①コード分析ツール(lint)はさまざまな言語向けのものがリリースされています!あなたが使う言語でも、lintを設定してみてはどうでしょうか?

②より良いテストを書くために、テスト対象のコードの中身ではなく外から見た動きに注目してテストを書こう!

③夜間や週末に自動でテストすることで、効率的にソフトウェアのテストが実行できるのです!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

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

読み終えるまで約5分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

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

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

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

  1. 単一責任原則(No. 73)
  2. 「イエス」から始める(No. 74)
  3. 面倒でも自動化できることは自動化する(No. 75)
①単一責任原則

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

「単一責任原則(SRP)は、『1つのサブシステムやモジュール、クラス、関数などに、変更する理由を2つ以上持たせてはいけない』ということである。これは各コンポーネントを独立してデプロイできる設計をする上で非常に重要な要素である。」

ということです。

 

以下、要約です。

単一責任原則(Single Responsibility Principle : SRP)は、いいデザイン設計の基本原則の一つで、「変更理由が同じものは一箇所に集め、違うもの同士は分ける」ということです。

1つのサブシステムやモジュール、クラス、関数などに、変更する理由が2つ以上あってはいけないということです。

 

下記は、ビジネスルール、レポート、データベースに関わるメソッドを持つJavaのクラス例です。

public class Employee {

    public Money calculatePay() ...

    public String reportHours() ...

    public void save() ...

}

このクラスは、3つのメソッドが全く違った理由によって変更される可能性があるため問題があります。

給与計算にかかわるビジネスルールに変更が入ればcalculatePayメソッドに変更が必要となり、レポートのフォーマットが変わるたびにreportHoursメソッドに変更が必要になり、DBA*がデータベーススキーマを変更するたびにsaveメソッドに変更が必要になります。

 

いいシステムデザインは、システムのコンポーネントがそれぞれ独立してデプロイできるようになっているデザインのことです。

独立してデプロイできるとは、あるコンポーネントに変更を加えたからといって、別のコンポーネントの再デプロイが不要であるということです。

 

先程のJavaクラスは、下記のようにコンポーネント分けしてはどうでしょう。

public class Employee {

    public Money calculatePay() ...

}

public class EmployeeReporter {

    public String reportHours(Employee e) ...

}

public class EmployeeRepository {

    public void save(Employee e) ...

}

 

*DBA:Database Administrator(データベース管理者)

データベース管理システム(DBMS)の導入や運用、記録されたデータの管理を行う人や職種のこと

②「イエス」から始める

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

「「ノー」ではなく「イエス」という返答から始めるだけで、物の見方が大きく変わり、仕事の進め方も変わってくる!」

ということです。

 

以下、要約です。

顧客に何かを要求された時、「ノー」前提で話を進める人がいます。

なんでもかんでも「イエスと言って顧客の言いなりになるわけにはいかないからです。

 

しかし、「イエスという返事の仕方にも多くの種類があるのはご存知ですか?

たとえば、誰かが「このアプリケーションのウィンドウを全部、円形で半透明にしてくれたら嬉しいんだけど」と言ってきたとします。こういう要望は、「バカバカしい」と即座に拒否することもできます。そうはせずに「どうしてですか」と尋ねるようにすると、その方がいい結果になることが多いのです。

(149ページより)

要望が出されたコンテキストがわかれば、新たな可能性に広がることがあります。

「ノー」から始めてしまうと、顧客の要望のコンテキストを理解できないでしょう。

「イエスというのは、何も顧客のいう通りに動くことではなく、顧客の要望にしっかり寄り添うということです。

要望を理解し、寄り添った結果「ノー」と言わざるを得ない場合もあるでしょう。

それでもいいのです。

 

「イエスから始めれば、人との対立は生まれず、協力関係が生まれるのです。

③面倒でも自動化できることは自動化する

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

「自動化できることは自動化すべし!」

ということです。

 

以下、要約です。

自動化できそうな作業があっても、わざわざ何度も同じ手作業を繰り返す人は少なくありません。

なぜでしょうか?

 

よくある誤解5つ:

  1. 自動化はテストだけのもの:なぜテストだけだと決める必要があるのでしょう?同じことの繰り返し作業はプロジェクトのあちこちに見つかるはずです。自動化をすれば、面倒な作業から解放されるだけでなく、作業時間が短縮され、正確さも増すのです。
  2. IDEを使っていれば自動化の必要はない:最近のIDEでは数多の設定パターンがあり得るので、完全に他者と同じ環境で開発してると言えない状況になります。しかし、「自分のマシンでは動いた、ビルドできた、テストを通った…」云々という言葉をよく聞きます。それではダメです。常に同じビルドを繰り返せるように、また全員のビルドを統一するために、AntやAutotoolsといった自動化システムを採用すべきです。
  3. 自動化のためには特殊なツールについて学ぶ必要がある:よく知られたシェル言語(bashPowerShellなど)が使えれば、自動化システム作成は可能です。
  4. 扱うファイルの形式によっては自動化できないこともある:Wordやスプレッドシート、画像ファイルなどは、確かに自動化が困難です。しかし、プレーンテキストやCSVXMLに変換することができ、これによって自動化が可能です。ほんの少し工夫するだけで作業を自動化できて効率が向上するのです。
  5. 忙しくて自動化のことまで勉強している時間はない:自動化は、bashやAntなどを十分に学んでからでないと不可能、というものではありません。自動化できる、自動化すべし、という作業が見つかるたびに都度知識を身につければ良いのです。

同じ作業を繰り返しているなら、それがいくら小さい単位でも自動化を検討してみてはどうでしょうか?

まとめ

①他のコンポーネントたちと独立させるメリットは大きい。そのためにSRPを徹底しましょう!

「イエスから始めることで、自分にはなかった考え方や物の見方を知ることができます!顧客のためだけでなく、自分やチームのためにも、「イエスから始めてみてはどうでしょう!

③自動化はしたほうが長い目で見て得です。同じ繰り返し作業は全て自動化しましょう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

 

***参考サイト***

DBA(Database Administrator)とは - IT用語辞典 e-Words