テスト駆動開発

昔、自分がどのようにプログラミングをしているか、を文章に書き起こせるか、という話を同僚としたことがある。それで書いてみようとしたのだが、すぐに行き詰った。最大の壁は自分の思考を文章にすることで、文章は基本的に上から順に読む線形の構造になるが、プログラミング時の脳内の思考は（おそらく）そんな単純ではない。他にも、あまり簡単な例にすると一般化されないし、かといって理論に寄り過ぎると実用性が無い……などなど。考え始めると、何をどれだけ書けば良く分からなかったので適当なところで諦めた過去がある。

そこで本書だが、テスト駆動に関する本ではあるものの、実質的には、どのようにプログラミングをすると良いのか、を解説している。数個程度のクラスから構成される機能を作るとき、いかに取り組めば良いのか。あるいは、おおむね一日単位のプログラミングにどのように取り組めば最適なパフォーマンスを発揮できるのか。

正直なところ俺はかなり感動した。自分が感じた文章化の壁をアッサリ乗り越えていたからである。どうやってこんなに読みやすい上にこんなにコンパクトな分量で済んでいるのかずっと考えながら読んでいた。最終的に、テストコードを書いてから実装する、という極めてシンプルなコンセプトに立脚しているから、という結論になった。どのページを切り取ってもこのシンプルなコンセプトに基づいた解説になっている。金太郎飴のように。この統一感は本当に素晴らしい。

テスト駆動の有用性だが、本書を読んで改めて学んだのは、見える化と不安への対処だった。見える化については言うまでもないが、本書はプログラマの心理状態への言及がとても多い。不安が不安を呼び、それが個人のパフォーマンスに壊滅的な影響を及ぼす。これを本書ではかなり重視しており、それを飼いならすためにテスト駆動を上手く使おう、としている。

不安の対処に関する箇所も十分実用的だが、他のテクニック的な箇所も実用的なアドバイスが多い。例えばTODOリストの活用だが、これは自分もマッタク同じことをしていたので驚いた。

テスト駆動が万能かというと勿論そうではない。これは、あるスタイルが合う人合わない人がいるという程度の話ではない。本書 p.274「TDDは誰のためのものか　TDDは『より良いコードを書けば、よりうまくいく』という素朴で奇妙な仮説によって成り立っている」とある。これの前段にはTDDはコピペプログラマには向かんよね、とサラリと書いてある*1。

そんなに分厚い本ではないが、サンプルコードは一部Pythonなものの大半はJavaなので正味の文章量はそうでもない。たかだが300ページちょいの本でこれだけの密度の本が書けるものなのか、と感動した一冊でした。

テスト駆動開発

*1:良いコードが良いビジネス上の成功に繋がるのか的な議論もあるだろうが、さすがに本書の内容からはズレるだろう

SQL実践入門──高速でわかりやすいクエリの書き方

俺は実務経験をある程度こなしたあと、RDBの知識不足を認識したクチである。改めてRDBを勉強し始めて困ったことの一つは、実行計画の読み方がよくわからないことだった。もちろん、ぐぐればNESTED LOOP JOINが何かとかは出てくるし、公式のマニュアルも参考になる。ただ、webの文献は体系だって解説があるとは限らないし、個人のブログなどは粒度がバラバラで、まとまった量の知識を得るには向いていない。マニュアルも膨大な量があるので慣れていないと目的の文書が書いてあるかどうかすら分からないし、あったとしても必要なレベルの解説があるかどうは分からない。

そこで本書の出番である。既存の書籍にもSQLとパフォーマンスを論じたものはあるにはあるのだが、それに特化した本の存在は、少なくとも俺は知らない。一冊だけ、データベースパフォーマンスアップの教科書 基本原理編 - kagamihogeの日記という極めて体系的に解説した書籍を知っているが、いかんせん500ページ近くあり読むのは気合がいる。

実行計画は、実はただそこに書いてある要素が理解できれば読めるわけではない。テーブルやインデックス等オブジェクトの性質、それらへのアクセスパス、ジョインの方式、どういうSQLがどういう実行計画になりえるか、SQLには現れないが実行計画を左右する統計やCPUやメモリなど物理レベルの要素、そして、それらが組み合わされたときの動作。多様な要素とその相互作用の基本的な性質を理解するのが、実行計画の理解の出発点となる。これを解説しようとすると、個々の要素だけでなく、要素間の関連とそれがSQLとどう繋がるのかもセットで記述しなければならない。しかし、そこはさすがのミック氏で、うまいことコンパクトにまとめるのに成功している（といってもソレナリにはページ数はあるけども）。

本書の他の本にはあまり見られない特徴としては、SQLを集合の世界の住人らしく上手く扱うことが性能の良さに繋がる、という視点にある。すでに同氏の著作達人に学ぶ SQL徹底指南書 - kagamihogeの日記で、SQLを手続でなく集合で扱う解説の手腕の見事さは知られている。本書では、SQLと実行計画の観点から前述のSQL本のエッセンスを凝縮したような形になっている。CASEやGROUP BYに慣れていないと最初の方でも読み進めるのは苦戦するかもしれない。ただし、手続でなく集合で宣言的にSQLを書き、手続的に処理手順を書くのでなくRDBMSに任せる、という事を覚えるにつれ、RDBMSをブラックボックス的に扱う恐怖感が次第に薄れていく。これは結構な快感である。

しかし、柔軟で表現力に富むSQLにも例外や限界はある。このあたりに対するミック氏のスタンスも見所で、問題の解き方は一つだけではない、という姿勢がそれに当たる。本書の後半では、この問題はあなたならどう解きますか？　という問いかけがなされる。当然本書でSQL力をつけたモノとしてはSQLで解きにかかるわけだが、実際には気合でSQLを書く以外の方法もあるよ、と示される。SQLに習熟するのも必要だが、場合によってはSQLでない方法も選ぶべし、とSQLの解説本で主張するのが面白い。他にも、SQL一発でなくループでぐるぐる回すのも完全に否定はせず、そのメリット・デメリットを解説している点などからも氏の柔軟さが伺えて興味深い。

RDBMSがいつの日か完全なものとなり、エンジニアは実行計画など物理レベルのことは全く気にせずとも良い日が来るかもしれない。元々リレーショナルデータベースの理想はそれを目指したわけだが、現実と折り合いをつけるためにやむなく実行計画を見せるようになり、エンジニアもやむなく日々チューニングという名の泥臭い作業に追われることとなった。前述のSQL本でも本書でも、ミック氏は理想を念頭に置きつつ現実に対処する、それがエンジニアの仕事である、と述べている。RDBの分野においては、集合論など理論的な面からSQLを見つつ、個々のベンダーのRDBMSの物理的な特性まで、幅広くしかし自分が必要とする深さまで、学ぶのが良いだろう、と言っている。

本書はその一歩、SQLがどのように実行されるのか、を学ぶ入門書として極めて良く出来ています。

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

コーディングを支える技術 成り立ちから学ぶプログラミング作法

本書を読んだからといって何か具体的な技術が身につく訳ではないが、自分自身がどのような言語をどういう風に身につけているか、を抽象的に振り返るのに適している。例えば、この本を起点にして学びたいことができたらそれを掘り下げていく、など。色々な言語を幅広く取り上げているのでそれぞれ個別の要素技術を学ぶ本ではないが、それらの言語を比較したり、どこからその言語が来たのかをたぐることで見えてくることもある。

元来コンピュータの役割は原始的な計算のみだった。そこで要求される機能はごく単純なものでよかったが、時とともにコンピュータの利用範囲は拡大し、自然とプログラミングに要求される機能も拡大の一途をたどることとなった。こうなると「楽に」プログラミングできるようにするニーズが出てくることとなる。しかし、ある問題を人間がどのように定義するのか、はバラつきがある。よって、問題を解決するやり方もまたバラつきが出てくる。世の中にいろんな言語があって、いろんな解き方が存在するのは、カンタンに言えばそういうことになる。

本書で繰り返し発せられるメッセージに、ある問題を解決するやり方が一つとは限らない、というものがある。本書で触れるトピックを幾つか挙げると、各言語の例外のスタンスの違い、型はそもそも必要なのかという議論や、オブジェクト指向をどう解釈しているか、などなど。ある言語では当然のように存在するものが、他の言語では存在しなかったり別の手段でなら実現できるものだったりする。同じ名称のものであってもマッタク別物だったりもする。ややこしいけれども、問題を解くやり方が一つとは限らない、という柔軟性の必要性を本書は説いている。そうするメリットは、多様な解決策からより適しているものを選べるようになる。さらには文字コードの章で書かれているが技術的な解決策だけでなく政治的な解決策もまたアリなのだと気付くことも出来るようになる。

そんなわけで世の中には多種多様で大小様々なやり方があふれている。それを後から追いかける立場からすると莫大な情報を泳がねばならず面倒なこと甚だしいが、逆に言えばその解決策にたどり着くまでの苦労をしょいこまずにいられるメリットがある。本書でも、いまとなっては当たり前に使う技術や構文が、実際には長い時間をかけて淘汰の果てに残ったものがあることを紹介している。forやwhileといったものが代表格。スコープもそうで、動的と静的とで揺れ動いた歴史を紹介している。あらゆるものは変化し続ける、いま現在もまた変化の途上にある、といった著者の主張がそこかしこに見受けられて興味深い。

もう一つ本書が興味深いのは、個々のプログラミング言語の学び方ではなくプログラミングをどう学べばよいのか、についての視点を与えようと試みている点にある。第一章での「比較から学ぶ」「歴史から学ぶ」がその要点にあり、それの具体例が本書全体ということになる。加えて、ところどころにあるコラムの内容がまた秀逸である。「理解を確認するためにはまずアウトプット」「何を学べばよいかがわからない理由」「必要なところからかじる」「おおまかにつかんで徐々に詳細化する」あたりは深い共感があった。それは俺がOracleを勉強するに当たって感じていたことどのようにOracleを勉強してきたか - kagamihogeの日記と被る点がちょくちょくあったからである。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)