【感想】Code Complete 第2版 下 完全なプログラミングを目指して

下巻へ

　諸々や師走のばたばたでしばらく更新ができず間が空いてしまいました。こちらの記事の続きです。

iwasiman.hatenablog.com

コードにしても設計クラスからメソッド、データ型の変数名のステートメントへ...と微細にコンプリートしながら今度は下巻。今度は出来上がったコードのテストや改良、リファクタリングなど、応用編的に続いていきます。

CODE COMPLETE 第2版 下 完全なプログラミングを目指して

第5部　コードの改良

第20章　ソフトウェアの品質

　まずは練習でコードを書いていると出てこないけど仕事で開発していると必ず出てくる品質の話。本書での品質特性とは

• 外部特性：正当性、使用性、効率性、信頼性、完全性、適応性、正確性、堅牢性
• 内部特性：保守性、柔軟性、移植性、再利用性、可読性、テスト性、理解性

と若干差があるにせよテスト関連の文献や情報処理試験の資料と同じようなもの。それぞれの特性が他の特性に影響するという表が面白いです。
　実際の改善技術としては目標を定める、品質のための作業を明示的に定める、テストの戦略を練る、ガイドラインを定める、非公式/公式のレビューや外部監査などなど、このへんは特に目新しくはない話。
　面白いのは目標を適切に定めるとプログラマは達成できる、様々な欠陥排除の手法での検出率など具体的なデータがいろいろ載っていること。一般的な単体テストや結合テストの検出率は実は30-35%程度で、設計インスペクションやコードレビュー、個人的にコードチェックするだけでもそちらの方が高いとなっています。エクストリーム・プログラミング(XP)で使われるペアプロでの設計レビューやコードレビュー、コードチェックを入れた方式の方が検出率が高いとなっています。
　欠陥の修正には時間がかかり、欠陥の発生率の低いプロジェクトの方が結局は生産性が高い。単なる力業のテスト以外の手法も入れた方がよく、そして上流のアクティビティに時間をかけて品質を確保すると下流で得をする……というあたりも、2010年代の今ではよく言われるもの。
　ちなみに本書によると、業界の平均的な生産性は１人1日当たりコード10～50行となっていました。僕の会社も１時間あたりの基準値とかいろいろ全社の集計データを公開していますが、だいたいこの範囲内でしたね。

第21章　コラボレーティブコンストラクション

　「コラボレーティブコンストラクション」とは日本語ではあまり使わない表現ですが、ペアプログラミングやインスペクション、レビューなど、複数人が協力して行う作業のこと。
　ここでもペアプロすると結局コードの品質が上がるので、2人でやることのコスト上昇よりもお得になるとあります。そして現在の日本でもちゃんとやってるプロジェクトではもう常識ですが、コードレビューやインスペクションを事前にするとシステム全体の劇的に品質が上がるという各種報告。
　インスペクションは準備して集まって欠陥の検出をメイン目的にやるものですが、具体的なやり方もしっかり載せています。
　その他の手法としては、2人以上で軽く話し合う感じの「ウォークスルー」、集まらずに机の前でコードを深く調べる「コードリーディング」、そしてお客さんにソフトの動きをデモするのを「ドッグアンドポニーショー」と定義ししています。
　日本語だとペアプロ以外「レビュー」にひとまとめにされそうな話ですが、それぞれの違いがまとめられた表なんかが参考になりそうです。参考資料にはかの『エクストリーム・プログラミング』などが載っています。

エクストリームプログラミング

第22章　デベロッパーテスト

　メソッド単位の単体テスト、もう少し大きな単位がコンポーネントテスト、統合もしくは結合テスト、回帰テスト、システムテスト...と、各種テストの話。
　どんなテストをしたらいいのか、開発者はコードの不備でなくコードが動く方に楽観的に考えがちである、すべてのテストパターンの組み合わせを満たすのはほぼ不可能である、同値分割や境界値分析……などなど、実務でテストしている人は無意識にでも実行していても未経験の人は知らないようなところを一通りカバーしています。わざとエラーを入れたJavaコードを実際にテストしていく例なんかは具体的でよいですね。
　調査によるとエラーの80％はシステムを構成するクラス群の20%の中で起こる、エラーの範囲は限定的である、プログラミングのミスでなく設計漏れやコミュニケーション不足も意外と多い、入力ミスのtypoが原因のものも意外と多い……など、四方山話もいろいろあります。
ちなみに90年代のMicrosoftでは、コード1000行あたり10～20個のエラーがテストで発覚、製品リリース後は1000行あたりエラー0.5個が検出されているそうです。
　テストはテストで奥が深いのでこの先を極めるなら専門書籍をという所ですが、参考資料には『基礎から学ぶソフトウェアテスト』や、最近新版が出たあの名著『テスト駆動開発』などが載っています。

基本から学ぶソフトウェアテスト

テスト駆動開発

第23章　デバッグ

　バグの語源はむかーしの大型コンピュータの誤動作の原因を調べたら回路に入り込んで焼け死んでた大きな蛾が原因だった……というあの有名な話から始まり、今度はデバッグの話。
　デバッグというのはプログラムの文法と違ってなかなか本や学校では学べず、実地で経験を積むのが必須な面がありますが本書でもこれを認めており、自己流のデバッグや憶測で探すこと、原因を理解せずに真っ先に思いついた方法で適当に直したりするのは迷信に基づいたデバッグだと一刀両断しています。
　本書で推奨している科学的なデバッグ手法は……

1. エラーを再現させて安定させる
2. エラーの原因を特定する
   　a.欠陥を再現するデータを集める
   　b.集めたデータを分析して欠陥に対する仮説を立てる
   　c.欠陥を立証/反証する方法として、テスト/コード調査のどちらにするか判断
   　d.それに従って仮説を立証/反証する
3. 欠陥を修正する
4. 修正をテストする
5. 同様のエラーを探す

　とし、従業員データベースのバグを例にしてひとつひとつ筋道立てて論理的に解説しているのが素晴らしい。ほかにもバグ検出のヒントとして、

• できるだけ多くのデータで仮説を立てる
• エラーを再現させるテストケースを改良して原因を探る
• 複数の単体テストでコードを分離して確かめる
• ツールを駆使する
• 何種類かの方法でエラーを再現させて原因を突き止める
• さらに新しいデータでテストして仮説を増やす
• 新しいテストケースが仮説を反証したら、そこからそこは原因の範囲でないことを知る
• 新しい仮説をひねり出す
• メモ帳に試してみることをリストアップする
• 疑わしいコードの範囲を絞り込む
• 以前にもバグが出た場所を疑う
• 最近修正された新しめのコードをチェックする
• 原因が違うところにないか、調査範囲を広げる
• コードを追加して新しいエラーが出たら分離してそこをテストする
• 誰かと話してみる（告白デバッグ）
• 問題から離れて一休みしてコーヒーや散歩に出る（笑）
• 時間はかかるが、総当たりのブルートフォースデバッグで攻める
• コンパイラーのメッセージや行番号はあてにしない
• 分割して攻略する
• コメント記号や引用符の閉じ忘れを探す

などなど、実践的な手法がしっかり解説されています。告白デバッグというのはいわゆるアヒルに話しかけるラバーダッキングなんですが、お堅い本かと思いきやこれも載ってるのが流石ですね。
　バグの修正時も問題を理解せよ、プログラムを理解せよ、エラー結果の診断を確認せよ、リラックスして行え、元のコードを保存せよ、症状でなく問題を解決せよ、変更はひとつづつ、修正後は確認、同様のエラーがないか確認……と、堅実にバグ退治のコツを述べています。
　また「デバッグの心理学的考察」として人間が見間違いやすいコードや変数、コードへの愛着や自尊心をデバッグ時は批判的な考え方に切り替えることの重要さ、人間は新しい現象が以前に見たものと似ていることを期待する...などの、コードから離れた人間の頭の中の話も解説しています。
　この章は地味ではありますが、プログラム言語の入門本などでもあまり出てこないところなので、バグ修正のスキルアップと時間短縮を図りたい人にはとてもオススメです。

　ちなみに「ラバーダッキング」でぐぐったら検索候補に電撃コミックスの社畜ちゃんが出てきましたｗ　３巻にそういうシーンがありますね。

いきのこれ！ 社畜ちゃん(3) (電撃コミックスNEXT)

第24章　リファクタリング

　この章はかのマーチン・ファウラー大先生の『リファクタリング』のサマリ的な内容であることが本文中でも述べられています。
　詳しくは本家を読めという話ですが、要約だけでもかなりの量がまとまっており、C++のリファクタリング実例も載っているので全体を把握するにも良いのではないでしょうか。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

第25章　コードチューニング戦略

　だんだん高度になってパフォーマンスを上げるためにコードをチューニングする話。ここもあまり本やネットの資料でも出てこない所です。
　チューニングの過去の定説は嘘が多いこと、高品質な設計や正しいコードが先で、最適化チューニングは最後の最後でやるべきであること、主にC++とC#、Javaでファイル入出力やコンパイラーや一般的な処理コスト比較など、次章26章の前段として様々なことが述べられています。
　例にC++が入っているあたりが時代を感じますし、マシン性能やメモリが潤沢になった21世紀では重要度が下がるところですが、読んでおいて損はないでしょう。

第26章　コードチューニングテクニック

　ハードウェア増強や設計改良が先でその後にコードレベルの修正をやること、リファクタリングとは逆の変更になり、速度のために内部構造が悪くなることもあることを断った上で、様々なコードチューニングのテクニックが述べられています。改善結果の例はC++、C#、Java、VBがメイン、時々PHPとPythonも出てきて改善後に速度が何％になったかが一例として載っています。(そういえばRubyは出てこないですね。)
　この章の内容もめったに他の本やWebの資料では出てこないところなので、2010年代の現在で実際に使うかはともかくとして、貴重性がかなり高いと思います。
　実際のチューニングテクニックは様々で、一般的により良いコードはこうすべきというのもあれば、普通やらなかったり知らなければ絶対わからないようなハック的な高度な技まで様々です。

• if文は答えが分かったらそこで評価を終了
• case文やif-else文は真になる可能性が高いものを先に
• 複雑なロジックはテーブル参照方式に
• 評価はループの外でやる
• 2つのループをひとつにまとめる（ジャミング）
• 読みにくくなるが、ループの中の処理を展開する
• ループ内の複雑なポインタ式を変数に代入する
• ループでの評価をsentinel（番兵）値を使って単純にする
• 実行回数の多いループを内側に
• 強度の削減（掛け算→足し算、指数→乗算、浮動小数点→固定小数点...）
• 浮動小数点をやめて整数にする
• 配列の次元数を減らす
• 配列へのアクセス回数を減らす
• 文字列の長さなど補助的なインデックスを使う
• 評価で何回も使う値はキャッシュ化する
• 高価な演算を安価な演算に変える（平方根など）
• 複雑な計算結果（対数など）を定数にしてコンパイル時に初期化
• プログラム言語側の精度が高く重い組込みメソッドを簡易化
• 事前の計算結果を活用
• 何度も使う式の結果を変数に入れて代用
• 低水準言語を使う（アセンブラ）

　などなど、数学が本格的に入ってきたり、なんというか簡単なWebアプリ開発とかだと出てこなさそうな達人の領域に踏み込んできています。参考文献もJavaのパフォーマンスの本など、やや古めの本が並んでいますね。
　面白いのはこれらのテクニックを実施した各言語での速度改善結果で、大幅改善したりある言語では逆に悪化していたり、言語ごとにかなり差があること。コンパイラの内部の動きとか高等な世界の話になりますが、けっこう違うものなんですね。概観としては、Visual Basicが特にテクニックによって全然速くならなかったり猛烈に速くなったり、他の言語と傾向が違って独特なことが多い感じがあります。

第6部　システムの考察

第27章　プログラムサイズが及ぼす影響

　一旦マイクロなコードの深奥から離れてマクロな人間系の世界へ、システムのサイズが大きくなるとプロジェクト全体の作業はもっともっとサイズが大きくなるよという話。
　2002年ごろの調査ではプロジェクトのチーム人数は4-10人がトップ、次が1-3人、あとは大人数は下がっていくだけとなっています。プロジェクト規模が大きくなると要求や設計のミスも増え、生産性も劇的に下がり、本書の概念のコンストラクションが占める割合も下がっていくよ……と、大規模プロジェクトに従事したことのある人ならうんうんという話が述べられています。
　結局のところ、少数精鋭のチームで開発するのが小回りも効いて一番速い……というのはアジャイル系の考えや先進的な企業、ふつうの企業でも受け入れられつつあり、かのAmazonでもジェフ・ベゾズがピザ２枚ルールを語っています。この考え方、調査結果自体はかなり昔からあるんですね。そして開発手法は大きなものを小さく押し込めるより、簡単な手法をプロジェクトの大きさに合わせて拡張する方が良い、正しい分量を探すのが大切だ……と述べています。
　本章では参考文献にあの伝説的な『人月の神話』が登場、他に『アジャイルソフトウェア開発の奥義』などが出てきます。

人月の神話【新装版】

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

第28章　コンストラクションの管理

　今度はソフトウェア開発を管理するマネジメントの話。プログラムを勉強中の人や個人開発や少人数チームの人にはちょっと縁が遠い話になってきます。
　良いコーディングの奨励ではまず標準を定義すること、標準を定義するのはプロジェクトの権威層に位置するマネージャでなく知識層に位置するアーキテクトがやるべき、そして本当に一目置かれているアーキテクトでないとダメだと述べています。実際に良いコードを奨励していくのはペアプロやレビュー、良いサンプルコードを用意する、コードを上級エンジニアが承認するようにする、コードが共有財産である意識を持たせる、良いコードは表彰するなど。
　構成管理の話ではお馴染みバージョン管理システムの他に、設計については変更管理手順を定めたり変更管理委員会を設けたり、変更を監視したりする方法が紹介されています。以前読んだ『闘うプログラマー』にもこの辺の話が出てきますが、規模が大きくなると勝手な変更を防ぐのも大事になってくるんですね。
　そして見積もりの話でも各種方法や初期の見積もりは不正確で徐々に精度が上がること、工数に影響する要因と影響度の図、そもそも見積もりはとても難しい難題であることなど、どちらかいうとマネージャ向けの話が続きます。
　面白いのは「プログラマは人間である」の節。プログラマの時間の使い方や生産性は個人差、チーム差があること、オフィスの環境も大事なこと、能力的に上位の人も下位の人も群れる傾向があること……など人間系の話がしっかり書いてあります。
　プログラマのこだわりである言語や方法論の好み、コードスタイルなどを「信仰の問題」としてまとめ、デリケートなのでマネージャは注意して扱わないと逆鱗に触れるぞ……など、プログラマを獰猛な珍獣のように書いてあるあたりはニヤリとしますね。
　参考文献ではかの『ピープルウェア』や、カーネギーのベストセラー『人を動かす』などが登場します。

ピープルウエア　第3版

人を動かす　新装版

第29章　統合

　ここでの統合とは、サブシステムやコンポーネントごとに分けて開発してきたものをいよいよひとつにまとめて結合テストなりシステムテストなりをしてくこと。規模が小さな開発だとあまり意識しないところかもしれません。方法として解説されているのは、

• フェーズ型の統合：すべて一度にまとめる。別名ビッグバン統合、順序の計画立てが不要だが基本避けた方がよい
• インクリメンタル型の統合：最小部分を開発して骨組みにし、そこに新しいクラスを順次追加していく

　インクリメンタル型統合の戦略としては、

• トップダウン統合：最上位から統合。欠点が多いので非推奨
• ボトムアップ統合：最下位から統合。こちらも純粋にやると欠点が多い
• サンドイッチ統合：最上位を最初に統合、次に最下位とユーティリティ系を統合、真ん中を適宜統合
• リスク指向統合：危険なクラスから先に繋げていく
• 機能指向統合：上位下位関係なく、機能の部分ごとに繋げていく
• T字型統合：縦方向にひとかたまりを抜き出して繋げてアーキテクチャをの前提を調査、これを繰り返して横に進む

　と、なかなか他の本では見ないところが紹介されています。その後は毎日デイリービルドして軽いテスト（スモークテスト）をして品質を保っていくコツの話。
　Microsoft社内の開発の話が出てきたりして、ああWindowsNT開発を描いた『闘うプログラマー』でもこのへんの話が出てきたなあと個人的には思い出します。
　本書によるとその後のWindows2000ではコードが5,000万行、フルビルドに19時間かかっていましたが、最後までデイリービルドを続けたそうです。参考文献には『XPエクストリーム・プログラミング入門』などが出てきます。

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

XPエクストリーム・プログラミング入門―変化を受け入れる

第30章　プログラミングツール

　Web系企業だと拘る人は徹底的に拘ったりするんでしょうか、ツール類の話。ここでは本書執筆時の話として、設計のツール、コードのツールとしてIDEやdiff、品質、リファクタリング、コンパイルやリファクタリングのツールなど、主にツール名のキーワードよりどんな目的のものがあるかを概説として紹介しています。
　最後の「ツールの理想郷」では、このツールさえ使えばプログラミングの必要がなくなる...という謳い文句は数十年前からずっと続いてきたが結局のところ実現できていない。それはプログラミングが本質的に難しいものであり、この世にコンピュータがある限り、解決すべき現実世界の問題とそれを解決できそうなコンピュータのギャップを埋める人間はプログラマと呼ばれ、コンピュータに命令を伝える活動は常にプログラミングと呼ばれるだろう……と締めくくっています。
　ここは同感ですね。日本でもよくプログラミング不要を謳う製品は現れては消えて行ったりするし、どーもSI系の会社は実装を軽視してそういうのが好きな傾向がありますが、言語やツールや進化しても本質的なところは変わらないよなあと思います。

第7部　ソフトウェア職人気質とは

第31章　レイアウトとスタイル

　コードの話は上巻で終わったかと見せかけて、ここで視覚的に優れたレイアウトはプログラムの論理構造を明らかにし、人間の頭で解釈しやすくなるという話。
　しょっぱなからCODING HORRORで絶望的にレイアウトが酷いコード例をいくつか挙げながら、美しく整ったレイアウトの重要さを論じています。レイアウトの話はプログラマの信仰とも結びついているという話もちゃんと書いてあるあたり、よくわかっていますね。
　2010年代の今の日本なら『リーダブル・コード』でも見れという話になりそうですが、例はC++、Java、VBを使い、制御構造やステートメント、コメントやメソッドやクラスそれぞれについて分析して深く論じ、ガイドラインを提示しています。題材がC++やVBなのには若干古さを感じますが、本書の方も一読の価値ありです。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

第32章　読めばわかるコード

　レイアウトとは別の切り口から、コードが何をしているのか他人に理解させやすいコード、コメントの話。
　コメントを入れるか入れないかについては、もしソクラテスの弟子たちがプログラマだったらという体で半分冗談で劇の台本まで書いてあり、アメリカでも昔から宗教論争になってきたんだろうなあと偲ばせます。
　本書ではコメントの種類はコードの繰り返し、コードの説明、コード内の目印、コードの概要、コードの意図の説明、コード自体では表せない情報の６種類に分類し、後ろの３つだけが価値のあるものだとして、効率的なコメントの作成方法を詳細に述べています。行末のコメント、コードの段落のコメント、データ宣言や制御構造、メソッド、クラスやファイルまで……。
　例にC++が多く、今はもうあまり使われないコメントスタイルも参考に載っていたりして歴史を感じさせますが、コメントについて一通り網羅しているのでこちらも一読の価値ありです。
　参考文献には本書が出たころの本として日本語で読めるのは2004年の『Code Reading―オープンソースから学ぶソフトウェア開発技法』が載っていますが、2017年の現在だともう手に入りにくい本ですね。

Code Reading―オープンソースから学ぶソフトウェア開発技法

第33章　個人の資質

　他のエンジニアリングと違う所のあるソフトウェア・エンジニアリングにおいて、基本の建築資材は人間の知性であり、一番主要なツールはあなた自身である。実はプログラミングだけでなく人間も大事なのだ……という、人間系の話。開発の啓発本などとも若干被る内容です。

• プログラミングは集中の仕事なので基本的にムラがある。一日中集中はできない。
• 自分の知性は変えられなくても、資質については十分に向上できる。
• 高い知性が必要なのではない。優秀なプログラマは謙虚で、自分の知性が不十分なのを自覚しており、だからこそ複雑さを分割して対応していく。
• 好奇心はいつでも重要である。開発プロセスを知り、成功したプロジェクトから学ぶ。言語を学んだら実験してみる。問題解決の本を読む。闇雲に行動する前に分析と計画をする。マニュアルもちゃんと読む。本を読む。他の専門家と交流を持ち、専門能力を養い続ける。能力が足りないのは罪ではなく、能力向上に必要なことを知った後でも初級者や中級者レベルに留まり続けるのが罪である……。
• 知的な誠実さを持つ。自分の過ちは認める。プログラムやエラーの理解に努める。進捗は正確に報告する。納期を短くさせようとする上の人に対し、見積もりで交渉に応じてはいけない。
• 他のプログラマとのコミュニケーションを考え、人に読みやすいコードを書く。
• 創造性の発揮には規律も必要である。
• 効果的なプログラミングで最も重要な作業は考えること。忙しそうにしているプログラマが優秀とは限らない。
• 粘り強さは頑固さはプログラミングでは価値があるとは限らない。長時間エラーと戦い続けるより一休みした方が成果が出る。
• ソフトウェア開発の世界は変化が速いので、現場の実体験の価値は他の分野ほど大きくはない。経験の量より質、学ぶ意欲を持ち続けるのが大事。
• 古い習慣を新しい習慣に置き換え、良い習慣を身に付けるのも大事。優秀なプログラマになれるかは最初の数年が重要。

……などなど、他の本やネット上の記事やSlideShareなんかの発表資料、著名人や有識者のインタビューなどでどこかで見かけたことのあるかもしれない話も含め、プログラマとしての心構えが並んでいます。参考文献には載っていませんが、私的には『達人プログラマー』なんかとだいぶ共通しているなと思いました。

第34章　ソフトウェア職人気質とは

　今までの具体的で詳細な話題をまとめる意味も含め、全体を振り返って抽象的に語っている章。

• すべては複雑さを克服するためにある。
• プロセスの選択は大事である。
• 未来の自分や他人に読めるコードは重要である。言語の概念に制限されずに「言語の"中への"プログラミング」をしよう。
• 規約は重要であり集中力を助ける。
• 階層構造の上位になるほど抽象化レベルを上げることで複雑さに対処できる。
• 開発アクティビティやは反復でより良くなる。
• 凝ったコードやエラーの多いクラス、複雑なクラスは危険信号である。
• ソフトウェアと信仰と結びつけてはいけない。新しい技術や流行もうのみにはできない。複数の方法を結びつける折衷主義でうまくいくこともある。実験も役に立つ。

　信仰の話なんかは面白いですね。

第35章　さらに情報を得るには

　ここは最後に業界の有名な本や雑誌、専門団体のことが載っています。 日本語訳がある本を挙げてみると……

新装版 達人プログラマー 職人から名匠への道

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

XPエクストリーム・プログラミング入門―変化を受け入れる

ソフトウエア開発 55の真実と10のウソ

ソフトウエア開発プロフェッショナル

プログラミングの心理学　【25周年記念版】

実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識-

　さらに作者さんの会社のConstrux Software社で社員の教育に勧めている本も上がっています。

初級レベル：

メンタル・ブロックバスター―知覚、感情、文化、環境、知性、表現…、あなたの発想を邪魔する6つの壁

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

ソフトウエア開発 55の真実と10のウソ

新訳 ソフトウェアプロジェクトサバイバルガイド

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

実践レベル：

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

基本から学ぶソフトウェアテスト

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)

ソフトウェア要求　第3版

プロフェッショナルレベル：

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

オブジェクト指向における再利用のためのデザインパターン

ライティングソリッドコード―バグのないプログラミングを目指して (マイクロソフトプレスシリーズ)

オブジェクト指向入門 (ASCII SOFTWARE SCIENCE Programming Paradigm)

　あ…ありのまま 今　起こった事を話すぜ！　「『コード・コンプリート』を読んでいると思ったらいつのまにか　この本自体が初級レベルのオススメ本に載っていた」　な…何を言ってるのかわからねーと（ｒｙ 　なカンジですが、まあ2010年代の現在の日本の状況からすると古めの本も多いのですが、このへんの本を読んでみるのもよいでしょう。

　そして最後はこの『コード・コンプリート』自体の参考文献がずらっと並び、上下巻に及ぶ本書も幕を閉じます。（この文献の量が凄い！） 英語の本や論文も多いのですが、うーんこれだけの量世界中からよく集めてきたものです。

気になったところ

　評判通りの名著だったのでマイナス面は別にないのですが、なかば無理やり上げてみると...

【電子合本版】Code Complete 第2版　完全なプログラミングを目指して

• お値段がけっこうします。いま時点で紙の本が約6600円、Kindle版が6100円、これが上下２冊なので合計1万円を超えます。その価値は十分にあるのですが、学生さんや新社会人だと懐へのダメージがけっこう大きいかもしれません。
  　僕はKindleの電子合本版をセールの時に半額ぐらいで買ったのですが、こういう値段の下がるタイミングを待つのもいいかもしれません。
• 合計1000ページ以上、読むのに根気がいります。
• 紙で買うと分厚いので立って読むと筋力トレーニングになります。
• 読破にもそれなりに時間がかかるでしょう。僕は主に平日の移動時間や出張の新幹線の中などで読んでいたのですが上巻13日、下巻が10日ぐらい、やっぱり合計1ヶ月コースでした。
• 電子版のみなのですが、Kindleだと目次で飛べるのが「部」だけでその下の「章」がないんですね。微妙に不便かも。
• ぱっと見一番の欠点に見えるのは……やはり2010年代からすると内容に古さがあること。

　プログラムのアルゴリズム、ステートメント系の話ではGOTO文のまずさについてもアツく語られていますが、21世紀の今からするとさすがにもう絶滅しているでしょう。処理のまとまり、具体的には関数やメソッドを指す際にも「ルーチン」という用語を統一して使っているのですが、これも最近は滅多に聞かなくなりましたね。
　サンプルコードやテクニックでもVBやC++が登場しますが、もはやC#がVBの完全上位互換になった今、レガシーだったりアレだったりする既存システムの保守でもなければVBもほとんど出てこないですし、組込み系なんかを除けば若い人がこれから学んだり仕事をしていく上ではCやC++も昔ほどは出てこないでしょう。

　しかし古いから役に立たない、手っ取り早くコーディング作法だけ学ぶならネットの記事で超頻出の『リーダブルコード』だけでいいや……というのは早計だと思います。
　本書で述べられている知識やテクニック、コンプリートなコードを完成させんとする達人プログラマーのスピリッツ的なものの多くは、プログラム言語やフレームワークやミドルウェアやツールの枠に縛られずに通用するもの、それらの枠を超え、時代を超えて役に立つ匠の技です。20世紀の現場の話や20世紀の資料が出典の事柄もちょくちょく出てきますが、人類が歴史から学べるように、開発者もソフトウェア開発の歴史から学べることもあると思います。
　というように、古さ自体も本書の価値の中に含め、読んでいくと得るものがあるのではと思います。

まとめ　評判に偽りなしのソフトウェア開発のバイブル

　という訳で、なんかRPG風の世界だったら王立図書館に聖典コード・エンサイクロペディアうんたらとかして恭しく祭られてそうな本ですが、実際ほとんどその通りなのでははーっとひれ伏さざるを得ません。

　なんとなくですが、分野的にはちょろちょろっとJavaScriptやHTMLを書いて小さめのWebサービスの画面を作ったりするフロントエンドよりも、本書のコード例に出てくる言語で画面より先のレイヤーも含めてがっつりプログラミング自体に取り組んでいるエンジニア向けに見えます。
　プログラミング自体が初めての人には少々手強い本ですが、初級者にも、さらなるレベルアップを目指したい中級者にも、その上のもう人に教える立場の人にも、それぞれの段階でそれぞれ得るものがある本、何年か経って再読しても得るものがある本です。

　本書ではプログラマのレベルを初級者/中級者/上級者/指導者の４段階で語っています。
　自分のことを振り返ってみると、僕は社会人からだったのでスタートが遅かったのですが、最初の頃は惨憺たる有様、しばらくしてJavaが流行りだした頃に運よくその流れに乗ることができてスキルアップ開始、コードレビューしたり人に教えたりいっぱしのことができるようになったのはその4-5年後ぐらいだったでしょうか。あの頃はあの頃で忙しかったんですが、こういう本をもっと早く読んでおけばまた違ったかなあと思い返しました。
（この本分厚いからか、あまり本屋で見かけないんですよね。あと私的には会社で今までこの本を読んだことのある人には巡り合わなかった気がします。）

　という訳で、長くて根気がいりますが時間のある時に読んでおくと必ず実りのある本でした。『達人プログラマー』や『情熱プログラマー』、『リファクタリング』やデザパタ本、日本なら『リーダブルコード』や『プリンシプルオブプログラミング』などなどと一緒に仕事場の机の横の本棚に並べておきたいような本です。（まあ、実際には並べるには分厚いんですが！笑）