「リファクタリング」第2版

この版について強調したいことの1つは、既存の書籍よりも範囲を広げていないということです。純粋にクラスベースの構造からわずかにシフトしていますが、私の目標は、書籍の範囲をあまり変更しないことでした。探求できる魅力的な領域がたくさんありますが、私には限られた時間とエネルギーしかありません。そのため、第2版が新しいトピック領域に進出させないというルールに従いました。初版にあるものを複製することだけを試みても、2年間の着実な作業になります。この作業に費やす時間を増やしたくありませんでした。結局のところ、初版は非常に成功しているので、私の目標は、その有用性を維持し、新しいものを作成しようとしないことです。

私の一般的な計画は、初版の各リファクタリングを取り上げ、このわずかに変更されたコンテキストで関連性を保つために何をする必要があるかを尋ねることでした。いくつかの（幸運な）ケースでは、リファクタリングをほぼそのまま使用し、例をJavaScriptに単純に書き換えて、完了することができました。しかし、通常は、メカニズムと例を大幅に再考する必要がありました。元のリファクタリングが同様のものに置き換えられることもありました。

将来的には、いくつかの新しいトピックを探求し、Webサイトのリファクタリングの集積に追加する可能性が十分にあります。もちろん、初版でもそう思っていましたが、ほとんどそうしなかったので、その考えを適切な量の塩で受け止めてください。しかし、私は2015年と2016年初頭に、リファクタリングを使用してさまざまなアーキテクチャの問題を調査するエッセイをいくつか探求しました。それらを書くのは楽しかったし、将来もっと簡単に使える手段を示してくれました。

私は過去数日間（週末を含めて）書籍のレビューコメントを検討していました。2月初旬に、ピアソンの編集者が書籍の現状を技術レビューのためにさまざまな人々に送りました。これは書籍を書く上で不可欠な部分です。どの著者も間違いを犯し、私はたくさん間違いを犯します。レビューアはそれらをキャッチするのに役立ち、明確に説明されていないことを強調するのにも役立ちます。

この本の資料に対するレビューは、今回が初めてではありません。私がこの本を書き始めたとき、継続的なレビューを行うために人々のパネルを集めました。章を終えるたび、またはいくつかのリファクタリングを終えるたびに、コメントを送ってもらいました。彼らのフィードバックは非常に役立ちました。しかし、どこかの時点で、誰かに立ち止まって本全体を新鮮な目で見ていただく必要があり、そこで最近のレビュー担当者の方々にご協力いただくことになりました。現在、私はウィリアム・チャーギン、マイケル・ハンガー、ボブ・マーティン、そして（私の継続的なレビューグループにも参加していた）ビル・ウェイクという4人のレビュー担当者からのコメントを精査しています。

私は章ごとにこれを行うのが好きで、まず最初の章を取り上げ、全員のコメントを見て、その章に関するすべてのコメントを処理します。「処理」とは、各コメントを読み、それについてどうするかを決定することを意味します。各コメントはレビュー担当者の視点であり、変更を提案するもの、何かが明確でないという表現、またはコードのエラーを示すものがあるかもしれません。多くの場合、コメントに対して何も反応しないことがあります。誰かの提案に同意しないこともあります。それは、その提案が本の範囲外だと感じることがあるからです。（以前に私の本をレビューしてくれた）マイケルは、フォローアップに何年もかかるような追加資料に関する良い提案をたくさん送ってくれますが、それらのほとんどは無視しなければなりません。しかし、私は気にしません。なぜなら、時にはそれらの提案が本当に必要なものであり、それらを含めるように誰かが私を促してくれたことを嬉しく思うからです。

エラーは修正すべき明らかなものであり、レビュー担当者が微妙なコードのエラーを見つけるたびに、私はいつも驚かされます。私は自動コードインポートシステムによってこれらの多くを回避していますが、自動インポートには穴があり、それらはすでに私をいくつかの恥ずかしい間違いから救ってくれました。マイケルは特にこれが得意で、彼は自分のウェットウェアにいくつかのコンパイラをインストールしているに違いありません。それが私が彼を非常に優れたレビュー担当者だと感じている理由の一つです。ウィリアム・チャーギンは彼に挑戦しているので、私は二重に恵まれていると感じています。

明確化は、しばしば最も理解するのが難しいものです。レビュー担当者が単に「これが理解できない」と言うこともあれば、もっと間接的な場合もあります。つまり、彼らが私が言っていることを理解していないことを暗示するような提案をすることがあります。これらに対処するのは困難です。なぜなら、それが単に一回限りのことなのか、それとももっと深いものなのかを判断する必要があるからです。人は常に本の一部に困難を感じるでしょう。個々の困難をすべて修正しようとすると、治療が病気よりも悪くなるでしょう。本はもっと大きくなる必要があり、文章は非常にぎこちなくなり、読むのが退屈になるでしょう。複数のレビュー担当者が同じ困難を抱えている場合、それは私が修正する必要があるものだと確信できます。この例としては、冒頭の例で入れ子になった関数を配置した方法が、パネルの3人を混乱させたため、私は異なるアプローチを試す必要がありました。

私はいつもレビューコメントを検討する作業を楽しんでいます。自分のやっていることが理にかなっているかどうかについてフィードバックを得るのは良いことです。この段階は、私が立ち止まって考えることを強制してくれるので、特に良いです。ほぼ2年間、私は章ごとに詳細に追われてきました。今では、資料全体を全体として見ることができるだけでなく、重要な詳細を整理するために深く掘り下げることもできます。

私がリファクタリングの初版を書いたとき、それはアディソン・ウェスリーのオブジェクトテクノロジーシリーズに入りました。私は本シリーズをあまり真剣に考えていなかったので、編集者の提案に従っただけでした。それ以来、私は独自のシリーズ（「シグネチャーシリーズ」）を立ち上げ、私が自信を持って推薦できる本のみが含まれるように、そのキュレーションにかなりの努力を払ってきました。そのため、この本が私のシリーズに移動するのは自然なことです。

しかし、それは必然的な決定ではありません。このシリーズは単なる受け皿ではなく、私がプログラミングの技術的な側面に関する基礎的な本だと考える本を扱うものです。私は最近出版した「NoSQL Distilled」をシリーズに提出しましたが、それがシリーズの雰囲気に合わないと考えたため、却下しました。それはやや複雑に聞こえますが、ここにはプロセスがあります。シリーズに提出されたすべての候補本は、シリーズのすべての著者に送られ、私は彼らの意見を求めます。その場合、彼らは私が自分自身を却下することを決定するのを手伝ってくれました。今回は、彼らはそれが簡単に含めることができると感じ、それは良い適合であるという私の気持ちを強めました。

以前のメモで述べたように、私はレビューコメントを精査することを楽しんでいます。しかし、私はこの作業をしばらく中断する予定です。私は今後の旅行の予定があり、今日が私が5週間机に向かえる最後の日になります。技術的には外出中にいくつかの執筆作業を行うことはできますが、ほとんどの場合、他のことで忙しく、本格的なエネルギーを注ぐことはできません。（そして、その中には休暇も含まれており、それが私を少し若返らせることを願っています。）これは、本のテキストを確定させて、他のことに集中できるようにしたいので、フラストレーションのたまる中断です。レビューコメントをすべて処理して対応を済ませたいと思っていましたが、執筆計画はソフトウェア開発の計画とほとんど変わりません（ほぼ同じ理由で）。

今週は、5週間の外出からようやくニューイングランドの机に戻ってきた週でした。長い間離れていましたが、最後の数週間はクロアチアでの素晴らしい休暇だったので、あまり文句は言えません。ハイライトはスプリト、ドゥブロヴニク、パクレニツァ国立公園、そして特にプリトヴィツェ湖群でした。

出かける前にテキストを終わらせたかったのですが、まだ作業が必要なレビューコメントがいくつかありました。出発直前に最後のコメントも受け取りました。そこで今週は、その最後のコメントを最初に確認し、レビューからの未処理のToDoが残っているだけになりました。悪いニュースは、これらのすべてのToDoを修正するには少し手間がかかることです。コメントを確認しているときにすぐに修正できなかったため、ToDoになったからです。良いニュースは、それらが14個しかないことです。今後2週間でそれらを終わらせ、また外出する必要があるでしょう。

今週のこの本に関するもう一つのトピックは、表紙について考え始めたことです。コアとなる表紙のデザインは、私のシグネチャーシリーズの一部になるため、すでに確定していますが、それは橋の写真を選ぶ必要があることを意味します。現在、それを整理している最中です。うまくいけば、来週それを共有できるでしょう。

先週と同様に、今週はレビューコメントに取り組んでおり、制作プロセスを開始する前に本の技術的な内容を確定できるようにしています。先週はすべてのコメントを検討し、1時間程度で対応できる簡単なものはすべて処理しました。それによって、複雑なものが残り、ゲームのこの終盤で、やや自己都合の締め切りに直面しているため、取り組むのがかなりストレスになります。

今週の私の仕事の中心は、2つの例の見直しです。どちらも、数人のレビュー担当者が理解するのが難しいと感じたものであり、もっと簡単になると思われるものを考え出す必要がありました。これは単に散文的なテキストを変更するだけでなく、コードを見直すことも含まれます。私はコード例を執筆の最も難しい側面の1つだと感じています。私は、主なポイントを示すのに十分な複雑さであり、それ以上の複雑さではない例を作成しようとします。それらはまだ人為的に単純化されています。現実的な例は、ほとんどの読者が頭を悩ませるには多すぎます。しかし、私はそれらが読者の日々の経験と共鳴することを望んでいます。今日、私はコードが50行程度の例を作成するのにほとんどの時間を費やしました。私はそれが私が言いたいことを捉えていると思いますが、このコードで例示するリファクタリングを実行し、私の散文がどのように機能するかを学ぶにつれて、より多くのことがわかるでしょう。それがうまくいくと楽観的に考えていますが、まだかなりの不確実性があります。

以前の例は、特に大規模なリファクタリング例の一部であり、この本の冒頭の例となる予定であったため、特にトリッキーでした。この例は3つのフェーズに分かれており、レビュー担当者は真ん中のフェーズで問題点を示しました。リファクタリングの順序を見直し、うまくいけば、物事は今でははるかに明確になっているでしょう。興味深いことに、このリファクタリングは、私が最初の冒頭例の草稿を書く前に書いたことのないリファクタリング（分割フェーズ）を中心にしています。変更の本質は、この新しく書かれたリファクタリングの仕組みに従うことでしたが、これらの仕組みに従うことで、実行と理解がかなり簡単になったように思えたので嬉しかったです。私の本のリファクタリングの仕組みは唯一のメカニズムではなく、すべてのコンテキストで最適であることはできません。私の目標は、それらがほとんどの場合、かなりうまく機能するはずだということです。ですから、それらに従うことで、この例をやり遂げるのに役立ったことを嬉しく思いました。

このようにリファクタリング例を見直すことで、gitに非常に慣れるようになりました。私はすべてのコード例を「ライブ」に保ち、コードを変更し、テストを実行してそれがまだ機能することを確認し、自動的に本のテキストに流れるようにそのセクションをマークします。私は長年コード例でこれを行っており、それが生活をはるかに楽にしました。しかし、リファクタリングの場合、コードの変更のシーケンスがあるため、これはトリッキーです。これに対処するために、リファクタリングシーケンスをgitリポジトリ（必然的に本のテキストを保存するリポジトリとは別のリポジトリ）に保存し、リファクタリングをコミットのシーケンスとしてキャプチャします。次に、コミットのリファレンスとコードフラグメントの名前を示すタグを使用して、コードを本のテキストにインポートします。このようなリファクタリングのシーケンスを見直す場合、私は多くのチェリーピックを行います。コミットマスター〜7を変更し、変更したコミットに、それ以降に行ったすべてのリファクタリング変更をチェリーピックします。それがうまく機能するときは素晴らしいですし、そうでないときでも、本の初版でやらなければならなかったことよりもはるかに優れています。

「完了」を宣言するまでに、あと1週間机に向かいたいと思っています。目標はまだ実現可能に見えますが、今日書いた50行が、それに付随するリファクタリングステップについて書くときに、どのように機能するかに大きく左右されるでしょう。

5月が終わる頃、私は出版社が「製品リリース」と呼ぶ重要なマイルストーンに到達しました。伝統的な出版の世界では、これは著者が原稿を制作チームに引き渡すことを意味します。この時点で、書籍の中核となる内容に大きな変更はないと予想されます。コピー編集や索引作成など、変更はありますが、書籍の本質に関わる大きな変更はありません。

初期の頃の本では、電子ファイルをPearsonに送り、後日、コピーエディターが修正した箇所が大きく印刷されたものが送られてきました。それらの変更を確認し、同意するかどうかをチェックする以外は、本が店頭に並ぶまで、あまり関与することはなかったでしょう。最近では、プロセスはよりインタラクティブになり、コピーエディターと私はgitリポジトリを共有し、彼の提案した変更をdiffで確認します。しかし、重要な橋を渡る感覚は今でもあります。もう例をやり直したり、重要な内容を追加したりすることはありません。ある意味、この本は完成したのです。（ただし、これはウェブファーストの本なので、ウェブでの表現は進化させ続けるつもりです）。

安堵の気持ちはありますが、まだこの本でやるべきことはたくさんあります。それでも、これは大きなマイルストーンであり、この本への集中が薄れ始める兆候です。来週、マドリッドで2つの講演をしなければならないので、それほど安心はできません。講演旅行は私にとって、歯医者に行くよりも気が進まないことなのです。しかし、精神的な重荷が少し軽くなったことは確かです。

シグネチャーシリーズを始めたとき、表紙デザイナーは各書籍で異なる写真を使用するスペースを含む基本的なデザインをレイアウトしました。私は、これらの写真をシリーズのすべての書籍でテーマを統一することにしました。当時、構造エンジニアである私の妻は橋の設計をしていましたが、その後、水平方向（橋やトンネル）から垂直方向（建物）に移りました。彼女の橋への関与に触発され、橋を本全体の共通テーマとして使用することにしました。そのため、私のシグネチャーシリーズで本を書く著者には、表紙を飾る橋を選ぶようにお願いしています。理想的には、その橋が著者と個人的なつながりを持っているべきです。

シリーズの最初の本（エンタープライズアプリケーションアーキテクチャパターン）では、ボストンのザキム橋を選びました。そのつながりは非常に明確でした。私が本を書いたのと同じ時期に、彼らが橋をすぐ近くに建設したからです。シリーズの2冊目（ドメイン固有言語）では、アイアンブリッジを選びました。これは、私が育ったブラックカントリーとのつながりであり、歴史的に重要な橋でもありました。

では、リファクタリングの本には何を選ぶべきでしょうか？頭に浮かんだのは、リファクタリングと橋のエンジニアリングの間に何らかの類推を描くことができないかということでした。しかし、私が知っている橋のエンジニアと議論した結果、橋のエンジニアリングにはリファクタリングに匹敵するものはないことが明らかになりました。そこで、私の心はプロフェッショナルではない連想へと移りました。この場合、私がニューイングランドに住んで20年以上、何度も訪れたお気に入りの場所の1つであるアカディア国立公園について考え始めました。これにより、キャリッジロードにある数多くの魅力的な橋の1つを選ぶことがすぐに示唆されました。

しかし、私はアカディアに縁のある別の可能性についても考えました。アカディアへ向かう途中、私たちはペノブスコット川を渡ります。私が最初のリファクタリングの本を書いた当時、道路はウォルドーハンコック橋を通ってペノブスコット川を渡っていました。これは著名な橋梁技師であるデビッド・スタインマンが設計した吊り橋です。しかし、21世紀初頭、70年前の橋を交換する必要があることがわかり、2007年までに道路は新しいペノブスコットナローズ橋を通るようになりました。

アカディアへの旅行の際、私たちは2つの橋の写真を撮るために立ち寄りました。1年後にウォルドーハンコック橋が取り壊されたので、ようやくそうして良かったと思っています。（曇りの日に写真を撮ったのが残念です）。

橋のエンジニアリングとリファクタリングの間に引き出せる類推はないものの、リファクタリングの本の2つの版とこれらの2つの橋との間に、創造的な類推を呼び起こすことはできます。

一部のツイッターユーザーは、リファクタリング本の第2版が第1版を「リファクタリング」しているとコメントしていますが、それは事実ではありません。（実際、橋のエンジニアリングと同様に、リファクタリングから書籍執筆への類推はないと思います）。この第2版は、ペノブスコットナローズ橋がウォルドーハンコック橋を置き換えるのと同じように、古い版を置き換えるものです。ウォルドーハンコック橋は、橋の建設コストを削減する革新的な技術を実証しました。これは、リファクタリングの本が、ソフトウェアシステムの構築コストを削減する新しい技術を説明したのと同じです。本の初版は、私のシグネチャーシリーズ内の新版に置き換えられ、新しいペノブスコットナローズ橋は、そのシグネチャーシリーズの最初の本の表紙となったザキム橋と似たデザインです。

ソフトウェアを構築する際、ユーザーの視点からソフトウェアを考えることが重要です。そのため、ペルソナを作成し、これらのペルソナをソフトウェアシステムの機能とユーザーエクスペリエンスを導くのに役立てるという概念があります。同様に、書籍についても、読者のことを考え、執筆を導くペルソナの概念を持つことが重要です。

執筆物にとって最も明白なペルソナは、学生読者です。この読者は、本のトピックについてほとんどまたはまったく知識がなく、教材を学ぶために本を読んでいます。これが私の主要なペルソナであり、私はこの読者の心の中にあるものと、彼に情報を伝える最適な方法を理解するために最善を尽くしています。

しかし、もう1つ重要なペルソナがあります。それは教師です。このペルソナは、本の内容のほとんど、またはすべてをすでに知っています。彼女は、より若い開発者を指導するために本を使用します。本質的に、この本は彼女のチームのスキルを向上させるというタスクを助けるためのツールです。

彼女は、たとえば、ジュニアに特定クラスを値オブジェクトに変更する必要があると伝え、参照から値への変更のリファクタリングを使用するなど、本を直接使用する場合があります。より高いレベルでは、彼女は匂いに焦点を当てるかもしれません。私が聞いた1つのテクニックは、チームリーダーが「今週の匂い」を指定し、チームにその匂いの例を特定して修正させるというものです。これにより、コードが改善され、開発者は将来的に同様の問題を見つけて修正する方法を学ぶことができます。

たとえ本が直接使用されなくても、間接的な形で役に立てばと思っています。シニア開発者はリファクタリングの知識を持っているかもしれませんが、それがリファクタリングを教える方法を知っていることを意味するわけではありません。トピックを教えることは、トピックの知識やタスクを実行するスキルとはやや独立した、それ自体がスキルです。私は、自分がやっていることを他の人に教えるのがあまり得意ではない才能のある実務家によく出会ってきました。優れた本は、そのようなリーダーがトピックを説明する方法を示すのに役立つ可能性があります。「参照から値への変更」のメカニズムセクションは、リファクタリングを実行する唯一の方法ではありませんが、これらの手順に従うことで、熟練した同僚が新しい人にその方法を教えやすくなります。

このような第2版の興味深い結果は、この本に興奮している人のほとんどが、学生読者ではなく教師読者であるということです。教師は、何年も前の初版の学生読者であった可能性が十分にあります。もしあなたがそのような読者であるなら、この本はリファクタリングについて新しいことを何も教えてくれないことを忘れないでください。もし何かを教えるとすれば、それはあなたが指導している人にそれを教える方法です。この本があなたにとって役に立つかどうかを評価するとき、それはあなたがそこから学べるものではなく、あなたの周りの人々の学習をどのように加速できるかによって評価されます。

私が知っているすべての技術書の著者は、技術レビュー担当者に多大な借りがあると言っています。私たちは皆、レビュー担当者として活躍する同僚によって発見された大きな欠陥のある作品を書いてきました。私は技術レビューの仕事をあまりしていません。私がそれがあまり得意ではないと思うからです。したがって、それに取り組む人々に多くの感銘を受けています。誰かの本をレビューすることでお金が稼げるわけではないので、それは寛大な行為です。

私がこの本に関する本格的な作業を開始したとき、私はフィードバックを提供してくれるアドバイザーのメーリングリストを作成しました。進捗状況に合わせて、新しい資料の草稿をこのグループに送り、フィードバックを求めました。メーリングリストにそのようなフィードバックを投稿してくれた次の人々に感謝します：Arlo Belshee、Avdi Grimm、Beth Anders-Beck、Bill Wake、Brian Guthrie、Brian Marick、Chad Wathington、Dave Farley、David Rice、Don Roberts、Fred George、Giles Alexander、Greg Doench、Hugo Corbucci、Ivan Moore、James Shore、Jay Fields、Jessica Kerr、Joshua Kerievsky、Kevlin Henney、Luciano Ramalho、Marcos Brizeno、Michael Feathers、Patrick Kua、Pete Hodgson、Rebecca Parsons、およびTrisha Gee。

このグループの中で、特にJavaScriptで特別な助けをしてくれたBeth Anders-Beck、James Shore、およびPete Hodgsonに感謝したいと思います。

かなり完全な初稿ができた時点で、さらにレビューするために送信しました。全体として草稿を見てくれる新しい目を求めたかったからです。William CharginとMichael Hungerは、信じられないほど詳細なレビューコメントをくれました。また、Bob MartinとScott Davisからも多くの有用なコメントを得ました。Bill Wakeは、メーリングリストでの貢献に加えて、初稿の完全なレビューも行ってくれました。

メーリングリストでの段階的なレビューと、最終的な全体レビューの組み合わせは非常にうまく機能したと実感しています。以前の書籍（初版を含む）のように、すべてのレビューを最後にまとめて行った場合、有益なコメントを得るのが遅すぎました。初期のコメントを受け入れ、書籍の執筆を続けながら対応することができました。最終レビューも役に立ちました。なぜなら、段階的なレビュー担当者は書籍全体の文脈を見失いがちだからです。実際、私自身も執筆に没頭していると文脈を見失うことがあります。新鮮な目で全体を見ることは大きな違いを生みます。

ちょうど「リファクタリング」のコピー編集のレビューを終えたところです。これは、私の完璧な文章が、私が想像するほど素晴らしいかどうかを確認する人に送られ、修正点のリストが返送される段階です。私の場合は、かなり大きなリストでした。

著者は、コピー編集プロセスに対してさまざまな反応を示します。自分の完璧な文章の1文字でも変更されたら激怒する著者もいます。また、原稿にうんざりして、すべての変更をそのまま受け入れる著者もいます。私は後者に近いですが、すべての変更をレビューしています。主に、コピーエディターが、このような技術書ではよくあることですが、テキストの意味をうっかり変更していないことを確認するためです。

このレビューは、興味深いと同時にイライラもします。この時点ではテキストに本当に飽きてしまい、もう一度読みたくないからです。コピー編集の多くは、私にはかなり恣意的に思えます。句読点や語句が変更されていますが、私には大きな違いがあるとは思えません。例えば、セミコロンの意義がよくわからず、ほとんど使いません。しかし、このようなコピー編集は、私のためではなく読者のためのものです。ドミトリー・キルサノフ（現在のコピーエディター）は、「コピー編集（単なる文法修正ではない場合）は、イントネーションの問題だ。著者は自分のイントネーションを常に聞いているわけではない。録音された自分の声を聞いて、驚く（大抵は不快に）ことが多いのと同じだ」と言います。

著者のコピーエディターに対する反応はさまざまですが、コピーエディターによって仕事の質も異なります。私が初めて一緒に仕事をしたまともなコピーエディターは、可能な限り著者の声を維持することが重要だと考えていたので、感謝しています。彼女との仕事で私が主に覚えているのは、大量のコンマを追加したことです。当然のことながら、私は本当に必要だと感じない限り、コンマを入れない傾向があります。残念ながら、彼女はイギリス人だったため、アメリカの出版社は、イギリス人がアメリカの基準でコピー編集できるとは考えなかったため、彼女を私の本で使うことはできませんでした。ドミトリーは、私の過去2冊の本のコピーエディターを務めており、彼の仕事も楽しんでいます。彼の変更の多くは私を肩をすくめさせますが、その多くは私の文章を明確に改善しています（この文の中の変更も含めて）。そして時々、彼が行う変更は、私よりも私らしいと思えることもあります。それは、ぞっとすると同時に素晴らしいことです。

私が会ったことのあるコピーエディターの中には、テキストを正しくするために変更しているということを強調する人もいますが、その態度は私をうんざりさせます。結局、「正しい英語」のルールの多くは、19世紀に、教養のある上流階級の人々と、私のような平民を区別するために発明された慣習にすぎません。（例えば、分離不定詞のルールは、ラテン語を真似るためにのみ存在します。）

2件ほど、すでに別のコピーエディターによってコピー編集されたテキストをコピー編集し、未編集のテキストに行ったのと同数の変更を加えているのを見たことがあります。（私は自己満足に浸っています。）

このサイトはコピー編集されていません。私の生のテキストが表示されます。それについて多くの苦情は出ていないので、コピー編集の段階をスキップするという利便性に満足しています。

第2版のために行っている変更の中で、おそらく最も重要なのは、Webファーストの書籍として執筆していることです。これは、書籍の標準表現がWebサイト上に存在し、紙に印刷されたものなどの他の表現よりも優先されるという意味です。ピアソンは、物理的な書籍を入手したときに、それをピアソンに登録して、その書籍のWeb版にアクセスできるようにする仕組みを構築しています。書籍の二次的な表現として、紙版のコンテンツは少なくなります。さらに、将来的には書籍のWeb版にさらに多くの資料を追加したいと考えており、紙版は更新できません。

数週間前、私は紙の本に何が含まれ、Web版にのみ何が含まれるかを決定する必要がありました。私が自分自身に課した制約の1つは、書籍の第2版が以前の版よりも大きくならないようにすることでした。（これは「UML Distilled」でも自分に課したルールです。）私がこのようにしたのは、第2版には肥大化する危険性があると感じたからです。なぜそうなるのかはわかります。結局、著者は主題についてさらに学び、新しいものをすべて含めたいと思うからです。しかし、大きな本は通常、良い本とは限りません。「リファクタリング」は二重形式であり、ほとんどが参照カタログであるため、サイズを大きくすることはそれほど大きな問題ではないはずですが、私はやはり、大きな物理的な本を信用していないため、制約を守りました。

初版は412ページ（参考文献と索引を除く）で終わったので、それを目標に設定しました。最初のページ校正を行ったところ、新しい本は440ページになったため、自己設定した制限を満たすためには少なくとも28ページを削除する必要がありました。どこをカットするかを考え始めたときは、選択を非常に心配していましたが、思ったより簡単だったことに安心しています。

新しい本には63のリファクタリングがあり、それらを2つの優先順位レベルに分けました。次に、優先順位の低いリファクタリングのうち、本の他の場所から参照されていないものを探しました。これにより、19ページを構成する5つのリファクタリングが特定されました。これらは印刷版から簡単に削除できました。もちろん、あと9ページを削除する必要がありました。さらにいくつかのリファクタリングを削除することもできましたが、代わりに10ページを占めていた例に目をつけました。これは、「分割フェーズ」のリファクタリングの2番目の例で、良い例ですが、すでに1つの例があったため、厳密には必須ではありませんでした。さらに、この2番目の例は、私が初期にJavaで行ったものであり、JavaScriptで書き直す気にはなりませんでした。印刷版では唯一のJavaの例になるため、削除すると、とにかくかなり奇妙に見えるものが取り除かれることになります。

これらのカットで本を再構築したところ、410ページになりました。したがって、計算は完全に正確ではありませんでしたが、自分で設定した制限内でした。（また繰り返しますが、これらの5つのリファクタリングは、すべての書籍所有者が利用できます。紙で見る代わりにWebサイトにアクセスする必要があります。）

数人の読者が、その5つのリファクタリングの犠牲者は何だろうかと思っているかもしれません。名前は後で発表します。これまでは、第2版に含まれるリファクタリングや、初版のリファクタリングの運命について話していません。それらについては、後のメモで説明します。

この2週間は、書籍制作のためにいくつかのタスクを急いでこなす必要があったため、非常に忙しかったです。この本の作業を間もなく終えることを期待していましたが、Web版の準備を含め、まだ多くの作業が残っていることを受け入れています。それについては、後のメモでもっと詳しく説明します。

過去数週間、リファクタリングの本に関する私の作業は、印刷版に関するさまざまな未解決の問題の整理に集中していました。現在、制作作業は、本の構成と校正を担当するアリナ・キルサノヴァの手に委ねられています。本を構成するということは、各ページの見た目に注意を払い、ページネーションに関するさまざまな問題が発生することを意味します。

私が書いているときは、改ページについてあまり気にしません。最近の私の出版物のほとんどはWebに掲載されているため、物理的なページについて考える必要はありません。しかし、本の場合、物理的なページは重要です。問題となる領域の例としては、コード例があります。コード例の不適切な位置で改ページしたくありません。理想的には、慎重に書いた小さな関数が改ページをまたがないようにしたいです。したがって、アリナは各ページを見て、適切な場所に改ページが行われていることを確認します。それをサポートするために、彼女が必要なときに改ページを挿入できるように、コード例の自動インポートを微調整する必要があります。

行の長さも彼女が注意を払っていることの1つです。ソースファイルを見ると、<dk:nobr>clarity</dk:no-br> のような新しいXMLタグが表示されるようになりました。これは、2行に分割したくないテキストを示すものです。これは、ソーステキストとしてマークダウンではなくXMLを使用する利点の1つです。私のツールチェーンが彼女のツールチェーンに渡せるように、アリナがテキストに新しいマークアップを簡単に追加できることです。

また、参考文献を埋めたり、内側のカバーにリファクタリングとスメルの表のリストを作成したりして、参照ページを作成しました。次に、ページの最終校正を行い、アリナからの構成に関する質問に対処する必要があります。多くの著者は、原稿を提出してそれで終わりにするのを好みます。そのアプローチには、今の私は確かに共感できます。しかし、このプロセスに参加する利点の1つは、本の構成における細心の注意を払った作業を理解できることです。

Safariオンライン書籍サービスのサブスクリプションをお持ちの方は、第2版のラフカット版を入手できるようになりました。これはコピー編集は済んでいますが、校正や最終構成は済んでいません。

新しい本をリリースする間際になると、私の気持ちは通常、興奮と恐怖が入り混じったものになります。興奮しているのは、何ヶ月、何年も費やして取り組んだものを世に送り出すので、人々がそれにどう反応するかを見たいからです。恐怖を感じるのは、何ヶ月、何年も費やして取り組んだものを世に送り出すので、人々がそれにどう反応するかを心配するからです。人々はそれを気に入るだろうか？そのすべての作業は価値があるだろうか？

今回の第2版については、ほとんどの人が失望するだろうという受容感が強いです。

ここで良い仕事ができたと思っていないわけではありません。私の他の執筆プロジェクトと同様に、このプロジェクトにも多くの努力とエネルギーを注ぎました。その結果、私が最も誇りに思っている本の価値ある改訂版ができたと思います。しかし、たとえそうだとしても、この本に対する否定的な反応を予想しています。それは、初版をよく知っている人は自然に初版と比較するでしょうし、ほとんどの人は、私が改善したと思っているにもかかわらず、新版に不満を抱くからです。

読者は初版に慣れており、その欠点にも慣れ親しんでおり、私が変更することにしたオリジナルの要素を気に入っています。損失回避の法則により、人は何かを失うことを、同等のものを得ることを喜ぶよりも2倍強く感じることがわかっています。したがって、新版での改善は、私が損益分岐点に達するためには、認識される欠点の2倍良くなければなりません。それは達成するのが難しい目標です。

さらに、多くの人はこの第2版を初版と比較するのではなく、第2版に望むものを想像して比較するでしょう。多くの場合、その想像は現実的ではありません。頭の中では良さそうに聞こえたが、書き下ろしてみるとうまくいかなかったアイデアはたくさんあります。現実的なアイデアに固執しても、非常に多くのアイデアがあります。最終的には1つの道を選ばなければならず、たとえ最も人気のある道を選んだとしても、意見が大きく異なるため、ごく少数派の意見にしか合致しないでしょう。

(私のこの感情は他の著者も共有していると思います。それが、多くの著者が改訂版やシリーズものの続編で苦労する理由かもしれません。)

このような避けられない失望があるにもかかわらず、なぜ私は第2版を作成しようと思ったのでしょうか？（ここ数年、この疑問を何度も自問自答してきました。）その答えは、この新版に対する真の評価は、発売後数ヶ月の間の即時的な反応ではないということです。そうではなく、5年、10年、20年後にリファクタリングについて学ぶ上で役立つかどうかです。この版の対象読者のほとんどは、まだこの本のことを知らず、多くの人はまだプログラムを書いたことがなく、ほとんどの人は初版のことを気にしないでしょう。これらの読者への影響が、この努力が価値があったかどうかを判断するテストとなります。残念ながら、私がこの数年の労力の価値を評価できるようになるまでには、何年もかかるでしょう。

本日、第2版のファイルが印刷所に送られました。これにより、印刷版の制作に必要なすべての作業が完了しました。書籍の構成、校正（特に恥ずかしいエラーを発見）、および索引作成を行ったAlina Kirsanovaさんに改めて感謝いたします。ピアソンのJulie Nahilさんは、この本の制作編集者として、すべての制作作業を調整してくださいました。

印刷された本は、10月末または11月初めにピアソンの倉庫に到着する見込みです。その後まもなく小売チャネルに出荷されるはずです。

しかし、1つの問題はWeb版です。Web版が完成する前に印刷版をリリースしたくありませんが、Web版の準備には十分な時間を割くことができませんでした。私は2週間の休暇を取り（コーンウォールでハイキング、ロンドンで演劇鑑賞、友人とゲーム、そして少し贅沢な食事を楽しみました）、その後2週間は出張があります。Web版のパイプラインのほとんどの要素は整理できましたが、10月中旬になるまで本格的に作業を開始することはできません。うまくいけば、それほど時間はかからないはずですが、これまでこのようなことをしたことがないので、何が起こるかわかりません。それがソフトウェアであり、それがどれほど予測しやすいかは誰もが知っていることを除けば！

数週間前の最後の更新で、本が印刷所に送られたことを述べました。おそらく彼らは忙しく印刷していることでしょう。それ以来、私の本の最優先事項はWeb版を完成させることです。すべての執筆は完了しましたが、まだファイルを準備してレイアウトを行う必要があります。アトランタでの次のレーダーを決定するための会議や、北京でのグローバルマネジメント会議など、いくつかThoughtworksの会議に出席する必要があったため、すぐに開始することはできませんでした。

しかし今週、私はデスクに戻って再び本の作業をすることができました。最初のタスクは、Web版がどのように公開されるかを理解することでした。ピアソンはWeb書籍ビューアを持っており、基本的にはepubフォルダーを取得し、それを単純なWebアプリケーションを通じて表示します。これの良い点は、本のほとんどがWebページであることで、私はそれを生成することに慣れています（そして実際、私が本を執筆していたほとんどの間、このようにして本を見ていました）。ただし、適切なepubマニフェストファイルの生成や、Webコンテキストでは有効なhtmlだがepubコンテキストでは有効ではないものを修正するなど、必要なさまざまなものを整理する必要がありました。

基本が整ったら、適切なcssを適用して、削除されたコードに打ち消し線が正しくマークされていること、目次とリファクタリングのリストを生成することなどを確実にする必要がありました。コードを強調するために使用するspanクラス名が、ビューアによって別のものに使用されていることが判明するなど、興味深い問題がありました。

しかし、今ではほぼ完了しており（私のorgモードのチェックリストでは13タスクのうち9タスクが完了しています）、トロントで開催される「パラダイムシフト」カンファレンスから戻ってきてすぐに、来週にはWeb版が完了するだろうと、とても嬉しく思っています。つまり、印刷所から本が戻ってきたらすぐに、実物の本の販売を開始できるでしょう。

しかし、まだ終わりではありません。次のタスクはrefactoring.com、特にカタログを再構築し、新しいリファクタリングで更新することです。また、Web版にあって印刷版にはないもののリストもまとめたいと考えています。

(私は通常「ほぼ完了」のようなことは言いたくありませんが、しばらく進捗状況を書いていなかったので、皆さんに最新情報をお伝えする義務があると感じました。)

本の最新状況に関する簡単なアップデートです。本は印刷され、ピアソンの倉庫に向かっています。Web版のファイルは完成しましたが、ピアソンのインフラストラクチャでテストする必要があります。それが完了したら、人々が購入できるように本をリリースできます。来週初めにInformIT（ピアソンのWebサイト）でスイッチを入れることを期待しています。Amazonもまもなくそれに続くはずです。感謝祭が遅延を引き起こす可能性があり、すべての七面鳥がサプライチェーンを詰まらせます。しかし、詳細がわかり次第、皆さんにお知らせします。

感謝祭中に、リファクタリングがinformitでリリースされました。実物の書籍と電子書籍を直接注文できるようになりました。実物の書籍はAmazonに輸送中で、今後1週間ほどで配達を開始するはずです。AmazonのKindle版もほぼその時期に登場するはずです。他の書店もまもなくコピーを受け取るはずです。本は徐々に海外の販売店にも行き渡るはずですが、それまでにどれくらい時間がかかるかはわかりません。