【第21回】RPG開発者達がRDi採用の動き‐その理由は？

増々多くの組織でRational Developer for i (RDi)が、RPGプログラマー向けの開発プラットフォームとして5250のエディターに置き換ってきています。

02/01/2019　スーザン・ガントナー＆ジョン・パリス

IBM iの開発組織に足を踏み入れると、黒い背景に浮かぶ大量の緑色のプログラムコードを目にするという状況は、そう昔の話ではありませんでした。最近では、プログラムコードを書く人間にとって5250ベースのエディターは絶滅に瀕した種です。増々多くの組織で、RPGプログラマー向けの開発プラットフォームとしてRational Developer for i (RDi)が5250のエディターに取って代わりつつあります。そしてその移行速度は、昨年辺りから極めて加速しているように見えます。

なぜ皆がRDiに移行しているのか、多くの理由を簡単にリストすることができますが、開発者達が最終的に5250のエディターを捨てるよう影響を与えている、主要な5つの理由に焦点を当てようと決めました。

1.もっとたくさんのコードが見られる

今日RPGを使用している組織における流れは、新しいコードをもっとモジュラー形式の機能駆動型で書くことです。とは言え、大半の組織は膨大な数の古いスタイルのコードで要員を維持する必要もあるという事実が依然としてあります。開発者が、一度に画面上でもっと多くのコードを見ることが出来れば出来るほど、ロジックの流れを理解するのがもっと容易になります。RDiエディターを使えば、見ることができる行数は、使用するモニターのサイズと形状によって制約されるだけです。私たちが使っている大きなデスクトップ・モニターでは、大体３～４倍の行数のコードを見ることができます。

RDiエディター・インターフェースは、一度に数多くのメンバーを開くこともできます。これは、プログラム呼び出しの連鎖を追うためにソースメンバーを切り替えるのをずっと楽にしてくれます。また、これはそれら新しい小さな関数やそのプロトタイプのコード間を移動する際にも重要です。タブを1回クリックすれば、すぐにソースメンバー間の切り替えができるのです。

分割された画面上で複数のソースメンバーを同時に操作する方が容易な場合もあります。RDiエディターは、モニターのサイズと形状の現実的な範囲で、水平方向にも垂直方向にも何回でも分割できます。そして、分割された画面のすべてのメンバーが編集可能です。これに対し、5250画面では、第二メンバーは表示のみという制約があります。

RDiは画面上のよりアクティブなコードを見る別の方法を提供します。つまり、表示画面からアクティブでないすべてのコード行を除くことができます。コメント行やコメント化して無効にした行は、単純なコンテクストメニューのオプションで「フィルター＞コード」を選ぶことで簡単に非表示にできます。

2. 情報がすぐに使える

多くのプログラマーが、すぐにRDiのアウトライン表示に病みつきになります。それは、コードに関する貴重な情報源です。アウトラインは、たとえ外部記述ファイルであろうがすべての変数定義の詳細を素早く入手できるようにし、あらゆるデータ構造のレイアウトを表示します。またアウトラインは、完全なレコードレイアウトの詳細情報を備えたファイル一覧だけでなく、サブルーチンやプロシージャの一覧も提供します。呼び出されたプログラムまたはプロシージャのプロトタイプもアウトラインに含まれます。そうした情報がすべてあれば、私たちはそれらの全詳細を探すために時間を費やす必要がありません。エディター内のソースの隣にあるアウトラインにすべてあるのです。

また、アウトライン・ビューは、これらすべての項目がコードのどこで使われているかというコード内の完全な相互参照も提供します。変数の場合、単にそれが参照される場所とは違い、その値が変更されるかもしれない場所を(M)と表示して参照場所を強調表示します。

アウトライン内のすべての情報はエディターに関連付けられます。たとえば、変数名をクリックするとコード内でその変数が定義されている場所にエディターが移動され、変数の相互参照行をクリックするとエディターはそのコード行に移動されます。そうすることで、アウトラインはコードに関する情報源としてだけでなく、ナビゲーション・ツールとしても使うことができます。

エディターは、今やホバーテキストを介してアウトラインの情報の多くを取得する機能を提供しています。ホバーテキストは変数の定義を表示できるだけでなく、今やその定義のコンテキストも表示できます。つまり、ホバーテキストには、定義がデータ構造の一部である場合はDSの名前が、外部記述の場合はファイル名が含まれています。プロトタイプ化された呼び出しでは、渡されるパラメータ（そして、もしあるなら返戻値）がホバーテキストで表示され、パラメータが定数として宣言されているかといった詳細情報も含まれています。

今やホバーテキストは、変数、ルーチンまたはプロシージャと関連するコメントさえも表示します。定義の直前にあるコード内のコメントや定義行の行末のコメントも表示されます。最後に、エディターはRPGプログラマーにコード内にもっとコメントを書くよう促す機能をもっています。

3．コード・ナビゲーションとコードの理解

RDiアウトライン・ビューが、どのようにしてプログラム中のナビゲーションを支援するかを見たところですが、他のいくつかの機能はコードの理解とナビゲーションを更にサポートしてくれます。

私たちのお気に入りの機能の1つは、比較的あまり知られていないキーボード・ショートカットの組み合わせによって実現されています。その使われ方を理解するために、簡単な利用シナリオを説明します。

あるプログラム・ロジックを読んでいて、EXSR（サブルーチン実行）命令に遭遇したと仮定しましょう。大抵の場合、次に行う必要があるのはサブルーチンに行ってそのコードを見ることです。その後、コードの残りの部分の調査を再開できるように、現在の位置に戻りたいと思うでしょう。呼び出されたルーチンに素早く移動するためにいくつかの方法が考えられます。しかし、容易かつ信頼性高くこの現在の位置に戻ってくるのは、かなり手の込んだ作業です。

以下、RDiで行うことを説明します。サブルーチンの名前の上にカーソルを置き、F3キーを押します。（この操作でソースエディターから退出してしまうように感じるかもしれませんが、そうはなりません。）カーソルがサブルーチンの先頭に位置付けられます。エディター・ウィンドウの下端のメッセージ行をチェックすると、「Altキーを押したまま左／右の矢印キーを押すと、以前の場所と現在の場所の間の切り替えができます」という、元の場所への戻り方のヒントが表示されています。コード内でカーソルを移動するとそのメッセージは消えますが、サブルーチンのロジックを調査し終わるまでその機能は依然として有効ですので、このメッセージは覚えておいてください。Altキーを押したまま左矢印キーを押すと、元のEXSR文の行に戻り、すぐにコードの残りを継続調査できます。

このナビゲーション機能は、サブルーチンだけでなく内部プロシージャやデータ定義に対しても有効です。変数の上にカーソルを置き、ホバーテキストからそれがデータ構造の一部だと分かったならば、そのデータ構造の定義に移動したいと思うかもしれません。ホバーテキスト内にある定義へのハイパーリンクをクリックすることもできますが、それでは現在の場所にすぐに戻ることはできません。私たちの好みは、そのデータ構造内の変数の定義場所に移動するために、変数名の上でF3キーを押すことです。その後、ロジック内の元の場所に戻るために、Altキーを押したまま左矢印キーを押すことができます。

F3が必要なキーであることを忘れてしまった場合、コンテクストメニュー（つまり、サブルーチン名の上で右クリックする）を使うことができ、「ソース > 宣言を開く」を選択します。

編集しているコードを理解する助けとなるもう1つのツールは、好みに合わせて任意のフリーフォーマットのネストされたロジックを（再度）桁ずらしする機能です。これは、現在の桁ずらしではロジック構造が明確にならないようなロジックに遭遇してしまった場合に役立ちます。この機能は、エディターのコンテクストメニューから「ソース＞フォーマット」を選ぶことで実行できます。

未だ固定フォーマット形式であるネストされたロジックは更に大きな課題です。RDiの中の「ブロック・ネストの表示」機能は、ネストされたロジックを明確にするために矢印を描いてブロックを示してくれます。

「ブロック・ネストの表示」は固定フォーマットのRPGコード内のネストされたロジックを強調します。この機能はサブルーチンまたはプロシージャの全体、あるいは特定のブロックに対してコードブロックの先頭ないし終端、またはブロック内のELSE、WHEN、またはOTHER文の上でもロジックの塊の場所を示す働きをします。これを有効にするには、コンテクストメニューで「ソース＞ブロック・ネストの表示」または「Ctrl + Shift + O」というショートカットキーを使います。固定フォーマットのネストされたロジックをもっと理解し易くしてくれる別のツール類もありますが、これが筆者等のお気に入りです。

4. コンパイル・エラーの発見と修正の速さ

私たちは、最初の試行でエラーを起こさずにすべてコンパイルされるほど完璧なコードを書く人に未だお目にかかったことがありません。コンパイルの試行後5250画面でエラーを見つける方法は非常に厄介です。RPGとIBM iが初めての開発者達にコンパイル時のエラーの見つけ方を教え始めるまで、私たちはこのことを考えもしませんでした。エラーを見つけるためには、スプールファイルを開き、エラーが報告された一画を見つけ、各エラーに対してソースプログラムの中でどのコード行が影響を受けるかを究明し、最終的にソースメンバーの中でそのコード行を特定する必要があります。これらすべての作業を行って初めて、エラー修正の方法を考え出し始めることができるのです。

RDiでは、コンパイルをすると特別なエラーリストにあらゆるエラーが直ちに、かつ自動的に報告されます。このエラーリストはデフォルトではワークベンチの中のエディター・ウィンドウのすぐ下にあります。リスト内の特定のエラーをダブルクリックすると、エディターをエラーの原因となっているコード行に移動します。この段階になると、先に説明したアウトラインやナビゲーション機能により、問題の解決法を把握する作業過程が迅速化できます。また、エディターに表示されるエラーや、ソースプログラム内でのエラーの印付けの仕方を制御することもできます。

5. 今日のRPGを完全にサポート

RPG言語は今日のビジネス・ニーズに遅れないよう絶えず進化しています。IBMは10年以上5250画面のSEUエディター上での言語サポートを更新していないので、SEUは現在のRPG構文のすべてを理解できるわけではありません。RPGの優れた新しい機能すべてを活用したい開発者達は、それらの機能を理解するツールに引き付けられがちです。RDiはRPGや他の言語の最新の機能拡張に遅れないようIBMが機能拡張している唯一のエディターです。

5250画面によるエディターは、フリーフォーマット宣言のようなより新しいRPG機能を使うと、誤って構文エラーを出します。RDiは現代の構文を理解して受け入れるだけでなく、開発者が新しい宣言型を容易に学習し、使用できるようにするコンテンツ・アシストのような機能ももっています。

フリーフォーマット宣言は、RPGに加えられてから現時点でもう4年以上経ちますが、SEUでは誤って構文エラーとされる最も顕著なRPG機能です。その他にも、少なくとも8つの組込み関数、（フリーフォーマット宣言のすべての操作命令に加え）2つの操作命令、そして旧RPGの機能を拡張する新しいキーワードがSEUでは構文エラーになります。新しいリリースが発表される度に、RPGの構文とSEUがサポートする構文との隔たりは大きくなり続けるでしょう。現代のRPGが提供するべきすべての機能を活用するためには、その機能すべてを理解し、それらを使うためにその構文を支援できるエディターを使うのが理に適っています。

これは始まりに過ぎない

以前は5250エディターを使っていた開発者達がRDiエディターに切り替える動機には他にも沢山の理由があります。そして、RDiで出来ることを知ったらこれを使い続ける更に多くの理由があります。かねてから、RDiを試してみようと考えていて、使い始めるためのいくつかの指南書が是非とも欲しいと思っているなら、私たちの書いたRDiクイックスタート・ガイド（bit.ly/2BPXuqe）と私たちのお気に入りのキーボード・ショートカット（bit.ly/2SxyF8f）虎の巻をダウンロードしたいと思うかもしれません。

RDiに切り替えたものの、まだバージョン9.6 に更新していない人たちは、新しい機能を見逃しています。見逃すことのできない、新しくかつ拡張された多くの機能が昨年発表されています。