Exsr DayOfWeek; v.s. WeekDay = DayOfWeek(deliveryDate); |
どちらが起こっていることについてより多くの情報を提供するでしょう？プロシージャDayOfWeekの呼び出しは、ルーチンに対して何が入力として使われ、演算の結果が何処に格納されるかを教えてくれます。サブルーチンからその情報を得るためには、サブルーチンのロジックを詳細に調べる必要があり、これは時間が掛る上に潜在的に間違いを起こし易い作業です。
２．再利用可能な関数ライブラリを確立する
サブプロシージャを中心にしてアプリケーションを構成し始めるとすぐに、元々それ用に開発されたプログラムの外にユーティリティをもつルーチンを探すのが自然なことになります。明らかな候補には、住所の正当性を確認する、電話番号を整形する、電子メールを送信する、顧客検索を実行する、そして信用調査をするなどが含まれます。
このアプローチは多くの恩恵を生み出します（つまり、関数が１つの状況下で顧客番号の正しさを検証するといった所与の仕事を正確に実行するなら、その関数はすべての状況下で正確に動作するでしょう）。これは、1つのプログラムから別のプログラムにコードをコピーするよりもずっと良いことです。このコピーという慣習は多くの企業で標準になっているものの、複数のバージョンが独立に存在するという状況を生み出す可能性があります。その結果、この慣習は機能を追加したりバグを修正したりするのに時間が掛り、かつエラーを招きやすいプロセスになります。数年前、古いスタイルのRPGの維持管理に特有の収穫逓減の法則と格闘し続けているお客様がありました。そのお客様は、維持管理および対応が改善されることを期待して、最終的に主要アプリケーションの1つを再利用可能なコンポーネントを中心に再構築することを決定しました。
そのお客様は２つのことを発見しました。第1に、プログラマーは「ブラックボックス」を独立して完全にテストでき、コードの記憶が新しいうちにバグを修正できるので、新しいアプリケーションのテストは、もっと早く、広範で、問題の発生がより少ないということでした。第2に、プログラマーは、以前は不可能だった方法で新しい機能の要求に応えることができるということでした。この事実から1年後、新しい習慣の50%以上の時間が、古いシステムでは夢見ることのできなかったウェブサービスやその他の新たな機能を開発するのに使われているとこのお客様は報告しました。
３．Db2とSQLを活用する
私達の多くは、データベースへのアクセス法に関する決断をするのに多くの時間を費やしません。他の多くの言語と違い、RPGはSQLまたはRPG独自のネイティブなデータベース・アクセスのどちらを使用するかの選択肢を開発者に与えます。大半のRPGプログラマーは次の２派のどちらかに分かれます：SQLだけを使う派、またはSQLは遅く複雑だと理解しているのでSQLを絶対に使わない派。
私達は仕事のために最善のツールを使うことを信条としています。これはしばしばSQLをその集合指向の特性と共に使用することを意味します。しかし、開発者にSQLだけを使うよう強制すると、カーソルを扱い、処理方式を条件付けるために複雑なRPGロジックに繋がる可能性があります。ですから、私達はデータアクセスに最も適した方法を決定するために、開発者にアプリケーションにおけるデータベースの用途に目を向けるよう勧めています。RPGのネイティブなアクセスとSQLによるアクセスを混ぜることを禁じる法律はありません。
どのようにデータベースにアクセスするかに関係なく、ビジネスルールをデータベースに埋め込み、RPGロジックを簡素化するために、会社はDb2 for iの使用を検討するべきだということは間違いありません。これは複数の方法で行えます。
参照整合性と検査制約を実装することで、値域および値の検査と同様に関係制約を規定することができます。こうすることで、必要なRPGロジックの量を減らし、データの妥当性検証の処理ロジックを確実にもっと首尾一貫したものにするのに役立てることができます。RPGあるいはSQLで書かれたトリガーは、複雑なビジネスルールを首尾一貫した形で処理することができます。ワークステーションベースのソフトウェアは、ODBC/JDBCまたは他の形式の遠隔アクセスを採用しているので、ユーザーが自分自身の目的のためにデータベース・テーブルにアクセスする可能性が高まるにつれて、データベースに規則を埋め込む必要性は日々高まっています。
SQLビューを作ることができ、その結果SQL文の実力を十二分に活用することができます。これはDDS論理ファイルの能力を遥かに凌ぐものです。またSQLビューを作ることで、プログラムロジックなしで関連するテーブルからデータを集めるために、選択、結合、あるいは和集合を求めるといった操作を行うことによってRPGロジックが簡素化されます。
すべてのSQLを直接プログラムに埋め込むことも可能である一方で、SQLビューを使うことは、外部記述ファイルを更に大きく前進させるようなものです。私達のプラットフォームにおいては、各プログラムの列、データ型、そしてサイズ定義をハードコーディングしようと夢見ることは決してありません。そして、私達はその哲学をデータの選択や表示の仕方にも拡張します。
４．手持ちのツール群をモダナイズする
私達はRational Developer for IBM i (RDi)が大好きです。5250ベースのPDMやSEUツールセットは、これらについてだけでも多くの記事を書くことができる製品ですが、これらと比較してRDiを使用するのには多くの理由があります。しかし、ここでは私達の好きな機能のごく僅かな部分にハイライトを当てることにします。
RDiを使うと、編集のために多くのソースメンバを一度に開くことができ、同時に複数のメンバを見る必要がある場合には、実際の画面サイズが許す限り画面を幾つにも分割できます。このことは、今日のよりモジュラー型のコーディング・スタイルと共に重要になります。1度に見ることのできるコード行数は、画面サイズと調整可能なフォントサイズの組み合わせだけで制限されます。一般的に、SEUと比較して２～３倍のコード行を1度に画面表示できます。
否応なく発生するように思われるコンパイル時エラーのすべての修正は、ソースコードと共に画面上にコンパイルエラーのリストをポップアップするRDiのエラーフィードバックのお陰で劇的に速くなります。リスト内のエラー上で素早くダブルクリックすると、違反のあるコード行が即座に表示されます。
RDiのアウトラインビューのお陰で、内部定義されたものであろうが外部定義されたものであろうが、変数のサイズと型が一目で分かります。アウトラインの相互参照は、各変数（またはプロシージャ、あるいはサブルーチン）をコード内で参照しているすべてのコード行の表示もします。アウトラインからの同じデータは、変数定義をホバーテキストとして表示されるようにするためにも使用され、新しいロジックを書くときにコンテンツアシストがプログラム文の完成を支援できるようにします。
ショートカット・キーは、日常的な行動をより迅速に実行する方法を提供してくれるので、私達が好きなもう1つの機能です。私達は自分達の好きな独自のキーボード・ショートカットのピンナップリストを公表しています(https://systemideveloper.com/pages/downloads/RDiShortCuts/)。
他の重要な開発ツール
変更管理および／またはバージョンコントロール・ソフトウェアは、今日のアプリケーション開発サイクルの早いペースに信頼性高く対応するための要件になりました。IBM iに特化したツールのサードパーティ・サプライヤーの多くは、伝統的なソースメンバ保管モデルを理解しています。多くのツールは、たとえばコード配布支援のような、単なる変更の追跡を遥かに超えた機能さえ有しています。IBMの最近のオープンソース・イニシアチブのお陰も一因ですが、Gitのようなオープンソース・ツールもまた急速に人気を獲得しつつあります。
他の多くのツールは、RPG/400をフリーフォームRPG IVに変換するものや、文書化のための複雑なロジックを復号化したりリファクタリングしたりするのを支援するツールを含め、RPG開発者の日常をもっと余裕のある、より生産性の高いものにすることできます。ここで述べたほとんどのツールは確かに有料ですが、結果のROIは開発ツールへの支出に対する明確な投資対効果検討用資料になります。
５．ユーザーインターフェースを強化する
5250画面は幾つかのアプリケーションには十分である可能性があります。（そして、GUIインターフェースよりも上手く、またはずっと上手く使えると主張する人々がいます。）しかし筆者等の経験では、そうした5250画面に対する主張の大部分は、お粗末なUI設計に帰着します。問題の単純な事実は、銀行業務から音楽を聴くこと、あるいはお気に入りのレストランでのメニュー選択に至るまで、今日の労働者はあらゆることにGUIおよびタッチインターフェースを使っています。UIのモダナイゼーションに失敗すると、会社にとって人材募集や新しいユーザーの訓練は難しいものになります。
たとえ5250画面が、幾つかの仕事用として十分である、あるいは適してさえいると認めたとしても、そのインターフェースを使用することが「幸せ」なのは財布のひもを握っている人ではないので、それは関係ありません。財政支援を支配している人々は、5250画面の傑作を見て、即座にそれを古臭いものとして軽視する人々と同一人物です。幸いにも、非常に洗練された「スクリーン・スクレイパー」からバックエンドロジックを動かすために既存のRPGスキルを活用することで、新しいグラフィカルアプリケーションやモバイル指向のアプリケーションを構築するために設計されたツールに至るまで、モダナイゼーションを支援する多くのツールが利用可能です。これらのツールのほとんどが、筆者のような設計力の劣る開発者でも実用的なインターフェースを迅速かつ容易に作成できるよう支援するために、フレームワークあるいはテンプレート駆動システムを使用しています。
６．もう１つ他の言語を学ぶ
ここでの主要な考えはRPGを置き換えることではなく、RPGを増補することです。そしてもっと重要なことは、考え方を刷新することです。たとえば、私達がPHPを学んだときに、PHPが特にRPGの中で配列やDＳ配列を使用するという私達のアプローチを変えたことに気付きました。同様に、直ぐに利用可能な広範にわたるPHPの関数ライブラリのお陰で、絶えず車輪を再発明するよりも、事前に構築されたソリューションを探すという決断を下すことが増えました。
IBM i上で使用価値のある言語の大半はPＣ上でも実行できます。IBM iにPHP、Python、node.js等をロードする許可を得る必要はありません。PC上で言語を学び、これらの新しい言語が会社にとって価値あるものであることを上司達に証明するために、Db2にアクセスすることさえできるのです。
RPGは、今後何年もの間ビジネス・アプリケーションの中核に位置し続けると私達は何気なく信じていますが、あなた自身のキャリアを強化するためのちょっとした「将来の保証」に決して害はありません。新しい要件にアプローチする最善の方法について、管理職が助言を求める相手があなたであることを確実にしてください。あまりにも多くのRPGプログラマーが、どんな言語がIBM iでサポートされているかをよく知りません。その結果、彼らは誰かがIBM iプロットフォームを問題にしたときに異を唱えません。
７．オープンソースを活用する
IBM i上の新しい言語の到来によって、高品質、低コスト、あるいは無料アプリケーションの（無限とまでは言わないまでも）広大な世界が広がります。
効果的でコスト効率の高い運用を行いたいのであれば、車輪を再発明する風潮に抵抗しなければなりません。既存のツールやアプリケーションを活用することを学びましょう。そして、新しい言語を学ぶという私達の戦略と同じように、ソフトウェアに親しみ、それがうまく適合するかどうか判断するためにPCが使えることを忘れないでください。
また、RPGで作成されたツールの数も増えてきています。この記事の執筆時点で、手持ちのプログラムをJSONを活用した新しいRESTウェブサービスを利用、提供することができるようにしたいお客様のために、筆者等は概念実証を完了するプロセスを進めています。これは、ウェブサービスを利用するためのHTTPAPIと一緒にスコット・クレメント氏のYAJL JSONライブラリの移植版（という広範にテストされてきた2つの優れたソフトウェア）を活用して達成されています。また、これには新しいウェブサービスを独立してテストするために、IBM iベースのツールと一緒に無料のSoapUIデスクトップ・アプリケーションを使っています。
小さなステップが大切
モダナイゼーションは、IBM iを使用しているすべての会社内そして会社間で起こるべき重要な会話です。唯一の間違ったアプローチは何もしないことだと覚えておいてください。これらのアプローチの幾つかを試してみてください。どんなことが達成できるか誰にも分からないのですから。
＊訳注１：英大文字と半角カナ文字を使用している日本語環境では英小文字は正しい変数名として認識されませんのでご注意ください。
＊訳注２：これについては、下記のジョン・パリス氏の記事にある具体的なコーディング技法を参照すると理解し易いでしょう。 “AN INDICATOR BY ANY OTHER NAME” https://www.itjungle.com/2011/08/24/fhg082411-story01/
