04/01/2022 チャーリー・グアリノ
チャーリー・グアリノ（以下、チャーリーと略します）：皆さん、こんにちは。チャーリー・グアリノです。TechTalk SMBの別エディションにようこそ。今月お迎えするのは、私達の業界でお馴染みの伝説の人、テッド・ホルト氏です。彼は長年私達のコミュニティにいます。テッドは、40年以上IT業界、主にIBMミッドレンジ・システムズ、で働いてきましたが、読者の皆さんはIT Jungle誌のシニア・テクニカルエディターおよびライターを務めていたときの彼を知っているかも知れません。それに加えて、テッドは大学、コミュニティカレッジ、そして職業技術学校レベルでも教えてきました。彼はまた、6冊の本の著者および共著者であり、様々な出版物に何百もの記事や技術的な助言を発表しています。現在、彼はミシシッピー州にあるLane Home Furnishings社のシニア・ソフトウェア開発者として働いています。テッド、今日ここにあなたをお迎えできてとても嬉しく思います。
テッド・ホルト（以下、テッドと略します）：こちらこそ、チャーリー。お招きいただきありがとうございます。
チャーリー：ありがとう、テッド。あなたとの関係はかなり昔に遡ります。今日は、あなたが大事に思っているトピックに焦点を当てたいと思います。それはソースコードのリファクタリングです。リファクタリングについて議論しましょう。なぜなら、これが、私が本当にあなたと話をしたかった理由だからです。これは私にとって非常に魅力的な話題です。殊に今日、非常に多くの様々な企業が現在手持ちのコード、特に古いプログラムと苦闘しているという話を聞きます。彼らは、どんな場合であれ内部リソースまたは外部から得ているあらゆるプレッシャーで、これらのプログラムをモダナイズするのに苦労しています。また、コード自体がモダナイゼーションを制限しているので、必ずしも新機能を十分迅速に提供できるとは限りません。それではこのことについて議論しましょう、テッド。まず質問したいのは、リファクタリングとは何ですか？それについて幾つか情報をください。
テッド：リファクタリングとは、その振る舞いを変えずにソースコードの一部を書き直すことです。言い換えれば、ソースコードのやり直しに時間を掛けて終了しても、それが以前やっていた事と何ら違う事はしません。ですから、内部は変わりますが、振る舞いは変わりません。それは雑誌の記事を編集するようなものだと思います。私は多くの雑誌記事を書きましたが、最初の草稿はかなり雑です。そこには私が望む私の考えがありますが、それから私は立ち戻ってそれをもっと理解しやすくするために磨きをかけます。そして私達はソースコードについても同じことをしています。
チャーリー：その要点は何ですか？なぜそうしているのですか？
テッド：この古いコードの多くが持っている問題は、作業するのが難しいことです。私が大学で教えていたとき、私達は良いプログラムと悪いプログラムがあると学生達に語ったものです。どちらも正しい結果をもたらすかもしれませんが、それでもプログラムは悪い可能性があります。優れたプログラムを知る方法は、それが簡単に読み、理解し、変更し、そしてデバッグできることです。ですから、私達がやりたいのは、その基準を満たしていないプログラムを選び、それをビジネスニーズに応じて拡張または変更できるように、その基準に持って行くことです。
チャーリー：テッド、私達がこのリファクタリングの議論に足を踏み入れたのはお分かりでしょう。そしてその一部は、リファクタリングするプログラムをどうやって特定するかということかもしれません。しかしそれに入る前に、あなたに質問があります。ご存知のように私達の業界ではさまざまな用語を使用していますが、リファクタリングと同じ意味で使用されているのはモダナイゼーションだと思います。これらの2つの用語の間に違いはありますか？どんな時にも一方の用語の代わりに他方の用語を使用する必要がありますか？
テッド：リファクタリングとモダナイゼーションは必ずしも同じではありません。リファクタリングは、内部を変える形でソースコードを書き直すことですが、外面的な振る舞いは変化しません。それはモダナイゼーションの一部である可能性があります。リファクタリングはモダナイゼーション・プロセスで使用するツールである可能性がありますが、この2つは厳密には関連していないか、または間違いなく同義ではありません。
チャーリー：しかし、誰かがこれらの用語を同じ意味で使用していても、彼らは完全に間違っているわけではないのではないでしょうか。なぜなら、多くの人がこれら2つの用語のどちらかに焦点を合わせる傾向があることを私は知っていますから。
テッド：私は、その流行の最先端を行く人を知りません—リファクタリングは必然的にモダナイゼーション・プロセスの一部でなければなりません。モダナイゼーションを行っていない場合でさえ、コードをリファクタリングするかも知れません。
チャーリー：確かに。
テッド：実際、リファクタリングはコードに対して作業できるということにもっと関係があります。私は、何千もの行があるモノリシック・プログラムが嫌いです。チャック E. チーズにあるモグラ叩きのようなものです。１つを修正すると他の何かが壊れるので、それは良いコードではありません。ですから、こうしたことが起こらないようにリファクタリングするかも知れないのです。
チャーリー：それはその通りです。それでは、この事についてもう少し詳しく見ていきましょう。私が先に述べた別の用語についてです。私はコードの臭いと呼ばれるものについて喋り始めようとしました、そしてあなたはこの用語を聞いています—私達はリファクタリングに関する話をしており、コードの臭いという用語が必ず出てきます。コードの臭いとは何ですか？
テッド：いいでしょう。コードの臭い—私には分かりません。私は、自動詞として「最悪だ」という言葉は使いません。その代わりに「悪臭がする」という言葉を使います。私はそのコードが悪臭を放つと言います。他の人はコードが最悪だと言うかもしれませんが、どのみちコードの臭いは、あなたが見て「これは酷い」と言うに過ぎないコードです。それは多くの危険信号を灯します。「ちょっと、ここにはもっと深い問題があるかもしれない」と言っているコードです。リファクタリングについて書いている人の一人はケント・ベックという名前の男で、彼は「それが悪臭を放つなら、それを変えなさい」という祖母の子育て哲学を使ったと言いました（笑）。
チャーリー：いやあ、それは良い助言のようですね。
テッド：でも、それについて考えてみてください。あなたが、これまでに見たことの無いプログラムを見ると仮定しましょう。それを開いてソースから始め、GOTO文、GOTO文、そしてまたGOTO文を目にします。あなたは明らかにそれにうんざりしますね、違いますか？なぜなら、私達はGOTO文が悪いことを50年前から知っているからです。私達はそれを使うことを想定されていません。とにかく、GOTO文はコードの臭いです。私にとってもう1つのコードの臭いは、同じソースメンバー内で複製される可能性のある重複コードです。それは１つのソースメンバーから別のソースメンバーに複製される可能性がありますが、重複するコードはコードの臭いの源です。それは悪臭を放ちます。深い入れ子も臭いコードです。私は随分昔にあるプログラムの改善に取り組みました。私は、そのプログラムが12レベルのif-then-elseとdo-whileとそれら全部からなり、12レベル下にまで入れ子にされていたのを覚えています。それは馬鹿げています。それはコードの臭いです。
チャーリー：そして、間違いなく、デバッグしたり単に分析や検証を行ったりするだけでも非常に難しいですね。
テッド：もちろんです。場合によっては長いサブルーチンもコードの臭いです。サブルーチンが6行で終わるなら、それは大したことではありません。600行ある場合は？それはコードの臭いです。悪臭を放っています。それをリファクタリングする必要があります。そのコードを書き直す必要があります。
チャーリー：GOTO文はリファクタリングを実施している人々のことを聞いたときの主な話題です。彼らは常にGOTO文に行き着きます。それは彼らがいつも見ていることの1つです。しかし、あなたは重複コード、重複コードのセクション、深い入れ子などについて触れました。RPGには他にどんな例がある可能性がありますか？あるいは、他の任意の言語のあらゆる種類のコード内にある可能性がありますか？あなたが最初に追跡する典型的な事はありますか？これまでに話した以外のプログラムをリファクタリングしようとしているとき、ここで容易に解決できる問題は何ですか？
テッド：そうですね、私にとって最初に試すべきことは、コードをサブプロシージャに分割することです。私のプログラミングは、本当に相互に結び付いた多くのサブプロシージャで成り立っています。それらはパラメータを渡しそして受け取ります、そして私は制御ロジック内にサブプロシージャを持たせるようにします。ですから、私が最初に探すのは、サブプロシージャの欠如であり、それが私の最も集中していることです。そして、それと同一歩調をとって効果を発揮するのは、グローバル変数を取り除こうとすることです。GOTO文は多くの悪い論評を受けていますが、そうなるのは当然です。グローバル変数も全く同様に邪悪だと思います。私はグローバルデータがとにかく嫌いなので、このプログラムをサブプロシージャへとリファクタリングして、作成しようと試みます。そして、サブプロシージャ内でだけ使用される変数がある場合は、それをサブプロシージャのローカル変数にします。可能な限り全てのグローバルデータを捉えようと試みます。
チャーリー：繰り返しになりますが、プログラムをもっと簡潔でデバッグしやすくするためですね。
テッド：そうです、正にその通りです。私達はこのコードが信頼に足るものであってほしいだけです。私達は、それが堅実でかつ動作し、望ましくない副作用無しに、実行する筈のことを実行することを望んでいます。そして、グローバル変数は副作用を引き起こすことで悪名高いものです。
チャーリー：テッド、コードに関して私達が一般的に認識している問題の1つは、それが必ずしも錆びているとは限らないということですよね？言い方が難しいのですが、私が言いたいのは、私達はコードを見て古いスタイルみたいだと言えると思いますが、Cxxレベル（例えばCEOレベル）の観点では、彼等はリファクタリングの真の価値を理解していない可能性があるということです。なぜなら、彼等の見解では、潜在的にプログラムは有効に動作しているからです。プログラムは結果を生み出しているのに、一体なぜ少しでも努力をしてコードをわざわざリファクタリングするべきなのでしょうか。
テッド：投資効果が見込めない場合は、リファクタリングするなと私は言うでしょう。古いプログラムがあり、そのプログラムを機能拡張する必要がなく、適正に機能しています。もしそれが古いバージョンのRPGで書かれているとしたらどうでしょう。あるいはそのプログラムがGOTO文を含んでいるとしたらどうでしょう。そのプログラムが有効に動作して本来の仕事をしており、あなたがそれを変更しないのであれば、それはそれで結構です。しかし、それを機能強化する必要がある場合はどうでしょう？ある機能を取り入れて、例えばWebサービスなど、そのプログラムが作成されたときには存在していなかったものと統合する必要がある場合はどうでしょうか。ここであなたは行動しようとします—問題は、あなたがプログラムに取り組めるかどうかだということです。あなたはそれを機能強化できますか？あなたがそれを機能強化できないならば、あなたには選択の余地はありません。リファクタリングしなければなりません。
チャーリー：ふ～む。お気付きの通り、私達がリファクタリングに関して言及しなかったことの1つは、埋め込みSQLの使用です。それは大きなものです。SQLを埋め込もうとする場合、それはリファクタリングと見做されますか？
テッド：次のように言わせてください。例えば、RPGプログラムにループがあり、READEなどを実行して一連の行やレコードを更新している場合は、これをすべて一挙に実行しループを発生させない更新SQLで置き換えることができる可能性があります。これはリファクタリングでしょうか？はい、動作が変わらない場合はリファクタリングですが、それに追加させてください。私は、ネイティブI/Oをコードの臭いだとは思わないので、SQLではないという理由だけで、あるいはネイティブであるという理由だけでリファクタリングしなさいとは言いません。私にとってネイティブI/Oは、依然として完全に有効なI/O実行方法です。しかし、あなたの質問に答えるなら、振る舞いが変わらない限りそれはリファクタリングです。
チャーリー：私が聞いていることの1つ（これについては、あなたも既に１つの方法で述べていますが）は、あるプログラムは修正が難しく修正が難しい程、例えばプログラムに新しい機能を追加するのに時間が掛るので費用が掛るということです。それはその時点での技術的負債の良い定義でしょうか？
テッド：ええ、あなたは技術的負債の正鵠を射ています。リファクタリングは、技術的負債を清算する方法です。ですから、プログラムが機能強化できない場合―言い換えるならそれは次の例え話のようなものだと思います。例えば、毎日仕事に来てシャベルを渡され「その穴に降りて、もっと深く掘り下げてください」と言われたとします。それはあなたの技術的負債を増やしているだけです。リファクタリングは、脇に立って土を穴に詰め込み、必要な状態に戻し始める手段です。その穴を取り除きます。
チャーリー：技術的負債は私にとって興味深いトピックです。なぜなら頭に銃を突き付けられて、何かをとても迅速に提供する必要があるという理由で、何かをする必要があることを認識したときのようなケースがあるからです。「私はそれを入れなければなりませんでした。今、金曜日の4:00です。金曜日の5:00までにそれが必要なので、それを本番環境に反映させるために、今日はハードコードされた値を入れます」と人々が言っているのを聞いたことがあります。それは意図的に技術的負債を追加することに対する公正な論拠ですか？ハードコードされた値を追加するという技術的負債を考えたことがありますか？
テッド：ああ確かに、それは技術的負債です。間違いなく技術的負債です。ハードコーディングは、私達が決してしてはいけないことの1つですが、ときに私達の誰もがそれをしなければなりません。私はビジネスが継続しなければならないことを理解しています。製品を出荷するあるいは何であれ、ビジネスを遂行する必要があります。ときには鼻を押さえ、行われていない方法で何かをしなければならないこともありますよね？多くの場合、私達は正しい方法でそれを修正しようとしてそこに立ち戻ることは決してないように見えます。しかし、聖書に「あなたは自分が蒔いた種を刈り取る（つまり、自業自得）」という古い諺があります。もし私達がこれらのことをすれば、私達の意図が何であれ、私達はやはり最終的にそれに直面します。技術的負債は返さなければなりません。
チャーリー：それが問題です、テッド。「ああ、それを一時的に入れました」という話を数多く聞きますが、もちろんそれは本番業務コードの恒久的な部分になるだけで、常に追加の、または常に新しくて緊急の気を逸らすものがあるので、私達は決して立ち戻ることはありません。そして、私達は立ち戻って私達が持っているものを元に戻すことができません。多分このようにして、結果的に私達は今日、自分の手持ちのコードに存在するもの（つまり、悪臭を放つコード）を持つに至ったのでしょう。
テッド：さて、これは主題から少し逸れていますが、しかしそれはあなたが話していることに触れていると思います。私がプログラミングでやろうとしているのは、良いプログラミングの練習を試みるということです。何年も前に、私がSystem/34かSystem/36か何かを使用していて、O仕様書があった場合、遅かれ早かれ問題が発生するので、O仕様書の後にブランクを使わないことを学びました。私はありとあらゆるこの種のルーチンを持っており、あの忌々しい＃Gソートとかを見つけました。私は、事後でではなく事前に、作業ファイルをクリアするべきであると学びました。そして、これは30年前のことですが、私が言いたいのは40年前後を通じてこれを行ってきたので、ベストプラクティスを開発しようと試みました。そして、ベストプラクティスを使って新しいプログラムを作成できたならば、技術的負債が生じる可能性が低くなり、リファクタリングが必要になる可能性も低くなります。
チャーリー：うーん、リファクタリングである程度成功しましたね。例えば、あなたが、手持ちのコードがそこら中技術的負債で一杯になっていることを知っている１つの組織に連れて来られた、またはその組織に在籍していた場合、そのことを論理的に主張するためにどのように経営陣にアプローチしますか？あるいは、敢えて経営陣にアプローチしますか？単に自分自身で始めますか？
テッド：そうですね、罰せられことなくやってのけられる限り、私は自分でリファクタリングします。通常プログラミングに取り掛かっているときは、リファクタリングに時間を掛けることができます。そして、これは私の言いたいもう1つの要点ですが、リファクタリングの専門家が言うには、機能拡張とリファクタリングを同時に行なおうとしてはなりません。リファクタリングまたは機能拡張のいずれかであり、両方を一緒にではありません。ですので、私には分かりません。私が仕事をした組織が1つあり、彼らにGOTO文を使わずにCOBOLを書く方法をプログラマーに示したいと言ったのですが、ITディレクターはそれには同意しようとしませんでした。その結果の1つは、私がその組織のために仕事をしなくなったことです。ときとして、人々に彼らが物事を行う方法を変える必要があると説得するのは絶望的なことがあります。ですから、そう、リファクタリングに興味を示そうとしない人もいますが、しかしそれは興味深いことです。今話しているあの組織は、彼らが望むことを行う、カスタマイズされたパッケージを持っています。彼らはOracleに移行することができませんでした (彼らは試みましたが、成功しませんでした)。そして今、オーナー達は骨董品だという理由でこのiSeriesを捨てたいと思っています。その原因は、これらの人々が自分達のしていることを変えようとしないからです。ですから、リファクタリングはシステムをモダナイズして最新の状態にするための良い方法です。それはあなたのツールボックス内にある良いツールですが、（役に立つかどうか）私には分かりません。人々がそれをしようとしないなら、あなたはそれらを実現できません。
チャーリー：では、誰かが「あなたが何を知っているというのですか？これらの新しいシステム上で最悪の、最も下手に書かれたコードであったとしても、ともかくこのシステムは非常に高速に処理するので、コードのリファクタリングについて心配する必要が無いくらい高速に動作します」と言うのを聞いたとき、あなたはどんな反応をしますか？
テッド：そうですねぇ、パフォーマンス上の理由でプログラムをリファクタリングする可能性はあります。これはリファクタリングする良い理由かもしれませんが、実際にはリファクタリングはパフォーマンスに関するものではありません。リファクタリングは保守性に関するものです。買掛金システムがあり、電子メールアドレスを入力する場所があるとしましょう。誰かがあなたのところに来て、2、3、または4つの電子メールアドレスを入力する必要があると言ったとします。あなたはそれを一晩で修正出来ますか、それともこれは6ヶ月のプロジェクトになりますか？コードをどのように書き、どのようにそれを設計したかがそのすべてに関わってきます。
チャーリー：リファクタリングの投資対効果の検討について話しました。あなたが、経営陣が参加すると知っているリファクタリングの本当の投資対効果検討書を作成することについて、他に例がありますか？つまり、この論争ないし議論を純粋なお金の話に単純化する必要がありますか？それは、これに予算を拠出するためにそこにいる最も頑固な経営陣を説得するための良いアプローチ法ですか？
テッド：私はリファクタリングに多くの予算が必要になると考えたことはありません。私の考えでは、当然のことながらプログラマーは単純にそれを行うべきです。誰かが私にプロジェクトを割り当てたとき、それを機能拡張する前に私はそれを1日リファクタリングするつもりだとは言いません。ですから、実際私はそれをそれなりに人々に売り込まなければならないようなことはありませんでした。私は、なり得る最高のプログラマーになろうという一環として単にそれを実行しただけです。
チャーリー：そうですね、あなたはわざとらしい動きをして、「わかりました。今すぐこの手持ちのコードすべてのプログラムを取得し、AからZまでのプログラムのリファクタリングを開始します」と言っているのではありませんね。
テッド：私はそんなことはしたことがありません。
チャーリー：そうですね。
テッド：そう、私は単にリファクタリングが必要だと気付いた場合にはいつでもリファクタリングをしただけで、大げさに騒ぎ立てるようなことはしていません。しかし、多くの場合私達がやっていることは、（私が言うところの）「それを突き刺す」試みだと思います。私達は単に修正しようとしているだけ―プログラムにパッチを適用して正常に機能させるだけです。私達は本当に一歩下がって、私達がやろうとしていることが何であるか言ってみるべきであり、それを行うためのもっと良い方法があるかを問うべきです。しかし再度言いますが、心すべきことは、あなたはプログラムの振る舞いを変えようとしているのではないということです。既存の振る舞いを維持しようとしているのです。
チャーリー：ご存知の通り、この議論で常に取り上げられる話題の1つは収穫逓減です。テッド、私が言いたいのは、（いつかはその地点に到達するので）どの地点がそこかということ、つまりバランスについてです。どの地点で、リファクタリング対プログラムの真の生産的機能拡張のことで頭が一杯になりますか？「OK、リファクタリングは終了しました。次のプログラムに進めます」と言うとき、いくらかのバランスが必要です。どうやってそれを決定しますか？これは簡単に答えられる質問ではありませんが、どのようにお答えになりますか？
テッド：異なる人々は異なる方法で物事を行うことができ、どちらの方法も良いことを私は理解しています。言い換えれば、皆のコードは私のコードのように見える必要はありません。違って見えるかもしれませんが、私のコードと同じくらい良く、もしかしたらもっと良いかもしれません。他の人のコードを自分のコードのように書き直す必要があるとは思いません。ですから、第1にすることはエゴを避けることです。それはあなたのやり方ではないかもしれませんが、コードが優れたものである限りそのままにしておきなさい。不必要にリファクタリングしたいという衝動に抵抗してください。本当に、他の方法では追加できない拡張機能を単に追加できるようにしたいだけです。そして、その地点に到達したら、停止します。
チャーリー：例えば、あなたが私のために働いていて、「ねえテッド、このプログラムに新しい関数を追加して欲しいのだけど」と言った場合、あなたはコードを開いて、「おやまあ、これは本当に緊急に必要です」と言いますが、追加する必要のある拡張機能は1つのセクションに過ぎないとします。あなたはその1つのセクションをリファクタリングするだけですか、それともプログラム全体を上から下まで書き直しますか？
テッド：私なら必要最小限のリファクタリングをします。1つのセクションだけをリファクタリングするでしょう。こう言い換えさせてください。ウィジェットを1個1ドルで出荷している場合、不必要にリファクタリングしたとしても、やはりウィジェットを1個1ドルで出荷することになります。ですから、必要な最小限の量をリファクタリングするだけです。少なくともそれが私のやり方です。
チャーリー：なるほど、これは正にソースコードの優れたハウスキーピングです。
テッド：そうです。それは丁度他のものと同じだと私は思います。あなたの家につい考えてみてください。物は壊れ、あなたの家の周りの何であれ何かを塗り直す必要があることをあなたは知っています。さて、あなたはそれをすべて積み重なるままにすることができます、そしてあなたは最終的に自分の家または何やかんやに対して10万ドルという巨額の改築を行う必要に迫られます。他方、あなたがそれをすべてその都度手入れしていたら、あなたはそれ程大きなプロジェクトを抱えなかったでしょう。
チャーリー：技術的負債。
テッド：そのとおり。正解です。
チャーリーまさにそれです。
テッド：ですから、リファクタリングと技術的負債は本当にとても関連しています。
チャーリーそうですね。リファクタリングは技術的負債の解決策であるか、少なくとも…
テッド：そうです、技術的負債を返済する方法です。
チャーリーそうですね。
テッド：少なくともそれを返済する１つの方法です。
チャーリー1つの方法、そうですね。
テッド：多分それは唯一の方法ではありませんが１つの方法です。
チャーリー：テッド、本日はお時間を頂きありがとうございました。あなたは確かにリファクタリングについて、私の考え得るすべての大きなポイントに到達したと言えます。それはとても重要な話題であり、皆が本当にそれに取り組む必要があります。これらのシステムで実行しているコードの多くは、実際に幾らかのリファクタリングが必要です。もちろんそうですよね？
テッド：そうですね。
チャーリー：ここで説明した助言のいくつかを使用できなかった組織のことを考えるのは私には難しいでしょう。
テッド：ええ、おそらく誰もがリファクタリングも行う必要があると思います。少し前に言ったように、「私達はリファクタリング・プロジェクトを行う予定だ」と言わないことが最善だと思います。プログラミングに取り掛かるときには、リファクタリングが必要なものがあるかどうかを探し、調べることを習慣にしてください。そしてその考えは、そのプログラムを離れるときには、少なくともプログラミングを開始する前よりも少しは良くなるはずであり、あなたは多分時間の経過とともに実際に必要とされる基準にまでそれを向上させるというものです。
チャーリー：それは完璧なコーディング・アドバイスのように聞こえます。テッド、有難うございます。また、一緒に参加してくれた聴取者にも感謝します。本当に楽しかったです。テッド、またあなたとお喋りできるのはとても良いことです。本日は本当にありがとうございました。ポッドキャストをお聴きいただき、誠に有難うございます。TechChannelのWebサイトをご覧ください。ポッドキャストや記事など、他にもたくさんの素晴らしい情報が見つかる、間違いなくあなたにとって価値があるサイトです。テッド、最後の言葉をお伝えします。来てくれてありがとう、そして聞いているであろう人々へのあなたの最後の金言に感謝します。
テッド：あなたは、私が理解したい方法でリファクタリングを理解する必要はないというのが私の最後の言葉です。私がこれまでに読んだすべてのことに関わらず、もっと知るべきことがあるに違いないと思うので、誰かがリファクタリングのヒントを持っている場合は、ITJungle.comにアクセスし、そこにある連絡先ページから私に連絡してください。私は常にもっと多くの情報を探しています。リファクタリングはとても重要な話題だと思いますし、私達全員が一緒にその実施法を学べると思います。
チャーリー：完璧です。ありがとう、テッド。本当に嬉しかったです。またお話ししましょう。
テッド：チャーリー、ありがとう。
第5回「IBM iの最新デバッグ技法 －RDiとサービス・エントリー・ポイントを使う－」はこちらから
