読者です 読者をやめる 読者になる 読者になる

こすげのブログ

金髪エンジニアのブログ

【読書】「Code Complete 第2版 上 完全なプログラミングを目指して」の感想 その5

はじめに

今回は第2部 高品質なコードの作成第8章 防御的プログラミングから第9章 疑似コードによるプログラミングまでを読みました。

1時間半ほどかけて読みました。

これで第2部 高品質なコードの作成まで無事読了しました。

ただ第2部 高品質なコードの作成ソースコードを高品質に書くため、保守性を高めるためには再度読む必要があるなって思っています。

現在読了率は53%です。

半分突破しました。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

ということでいつも通りハイライトしたところの紹介を...。

ハイライト

結構しました。

覚えておきたいなっていうやつをしているので、あんまり強い意味は持ってません。

第8章 防御的プログラミング

無効なデータや「決して」発生しないはずのイベントや他のプログラマのミスが渦巻く冷酷で無慈悲な世界から自分の身を守る方法について説明する。

第8章 防御的プログラミング

第8章 防御的プログラミングの章の意味を紹介する一文でした。

とにかく、エラーに対する話でした。

使う側のせいなのか、システムのせいなのか、そういうのをひっくるめて対応しましょうって話でした。


通常、製品版のコードでは、アサーションメッセージをユーザーに表示しない方がよいだろう。

アサーションは主に開発と保守で使用するためのものであり、通常は、開発中のコードではコンパイルし、製品版のコードではコンパイルしない。

8.2 | アサーション

恥ずかしい話、アサーションを積極的に使用したことがありません...。

だいたいJavaを使用したあたりでtry catchを学び、throwsという技を学び...。

Objective-Cでは引数にNSErrorポインターを渡したりとありましたが、メソッドを自分で作ったところでは使用しませんでした。

最近、いろいろなライブラリのソースコードを読む機会がありますが(主にSwift)きっちりアサーションthrowsの処理を分けていてわかりやすいなと思っています。


外部ソースから取得したものである場合、無効な値の確認と処理は、アサーションではなくエラー処理コードで行うべきである。

ただし、これらの変数が信頼のある内部ソースから取得したもので、これらの値が有効範囲に含まれているという前提でルーチンが設計されている場合は、アサーションを使用するのがふさわしい。

8.2.2 | アサーションを使用するためのガイドライン

上の話と被りますが、うまく分けて作られているソースコードはわかりやすいです。


エラー処理が一般に正当性や堅牢性よりも優先されることも示している。

開発者はこれらの用語をあまり深く考えずに使用するが、厳密に言えば、この2つの用語は両極に位置するものだ。

正当性とは、不正確な結果を決して返さないことを意味する。

不正確な結果を返すくらいなら、何も返さない方がましである。

堅牢性とは、ソフトウェアの実行を継続できるように手を尽くすことである。

それによって不正確な結果がもたらされることがあってもかまわない。

8.3.1 | 堅牢性と正当性

エラー処理の話です。

アプリを作っていると様々なエラーに遭遇しますが、そのエラーの対処をどういう風にとるのかを語られていた章でした。


例外には継承と共通する属性がある。

それは、使いようによっては複雑さを軽減できることだ。

逆に、軽率な使い方をすると、コードを理解することはほぼ不可能になってしまう。

ここでは、例外の利点を理解し、例外につきものの問題を避けるためのアドバイスを紹介しよう。

例外が正常な処理の一部として使われているプログラムは、スパゲッティコードが持つ可読性や保守性の問題から逃れられない。

─ Andy Hunt、Dave Thomas

8.4 | 例外

ここでいう例外とははみ出し者って意味ではなくて、JavaSwiftにもあるthrowsの話です。

あるメソッドで例外が起きた時に処理しきれず、例外に対する処理を放り投げることができるよって話です。

これはある程度ドキュメントなりを見ていると覚えることではありますが、使い分けの方法が書かれていて、わかりやすかったです。

第9章 疑似コードによるプログラミング

「擬似プログラミングプロセス」(Pseudocode Programming Process:PPP)

第9章 疑似コードによるプログラミング

最初は全く意味がわかりませんでしたが、読んでいてわかりました。

難しいことはなく、疑似プログラミングとは自然言語でまずは書いてみようというやつです。

PPPという単語がいっぱい出てくるので、メモりました。


擬似コード」という用語は、アルゴリズム、ルーチン、クラス、またはプログラムのしくみを説明するための略式の表記法を指す。

PPPは、擬似コードを使ってルーチンを効率よくコーディングするための方法を定義する。

9.2 | 疑似コードプログラミングプロセス

PPPとはこんなのです。

コーディングに取りかかる前に、擬似コードで思い付く限りのアイデアを試してみよう。

いったんコーディングを開始したら、コードへの愛着が湧いてしまい、悪い設計を捨てて最初からやり直すことが難しくなる。

9.3 | PPPを使ったルーチンの作成

このコードへの愛着が湧いてしまい、悪い設計を捨てて最初からやり直すことが難しくなる。というのにすごく共感しました。

時間かけたやつほど手を付けづらくなるんですよね。

なのに次の日とかに見たら「このクソコードはなんなんだ」ってなります...。


コンパイルを後回しにする最大の理由は、新しいコードをコンパイルすると、心のストップウォッチが作動し始めることだ。

最初のコンパイルの後、だんだん気持ちが焦ってくる。

「あともう1回コンパイルすれば、きっと決着がつくだろう」という「あともう1回だけコンパイル」症候群は、エラーの原因となる軽率な変更を促し、長い目で見れば余計に時間がかかる。

ルーチンが正しいことを確認するまでコンパイルするのを我慢し、すぐに決着をつけたいという気持ちを抑えよう。

9.3.3 | コードの検査

コンパイルXcodeではBuild or Run)は大事なことなのに、warningを消すためにとかで乱発してしまうことがありました。

手を付けたソースコードの確認ではなく、違うことに目がいってしまうことですね...。

時間が迫っているときほど、こういうことがあるので、意識したいと思います。

感想

第2部ソースコードの書き方(クラス作成からメソッドまで)について書かれていました。

こういう文章を読んだことがなかったので、とても勉強になりました。

読むきっかけをくれたAmazon KindleさんとKindle paperwhiteをプレゼントしてくれた彼女さんに感謝してます。

常に読み続けた方がいいなと思うほど、シンプルで力強い文章でした。

つくづく読了してから感想文書かなくてよかったって思いました。

今は値段戻っちゃいましたが、また安くなった時に購入を勧めます。

僕はkindle のセールで購入した口なので、軽々しく6,000円以上の価値が有るなんて言いませんが、絶対にエンジニアさんは読む価値が(多かれ少なかれ)有ると思います。

なかった人は本を出してもいいと思います。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

終わりに

kindle良すぎて、本買っちゃいます。

次は「Scala関数型デザイン & プログラミング」を読もうと思っています。

関数型に興味あり。

以上です。