##はじめに
この記事は SAP Advent Calendar 2019 の12月9日分の記事として執筆しています。
##ABAP to the Future
ABAP to the Future (3rd edition)は、ABAP 7.52 (SAP S/4HANA 1809) をベースとして、今の最先端と少し未来のABAP関連技術について書かれています。ページ数は圧巻の867ページ！なお、クラウドプラットフォームでの開発についてはほとんど触れられていません。
##なぜ読もうと思ったのか
私は約1年前からSAPUI5を学び始めました。その中でわかったのは、FioriアプリはUIだけではなくOData、CDSなど複数の要素から成り立っているということです。また、学ぶ端から技術がどんどん更新されていくのも感じました。たとえば、最初はフルスクラッチのUI5アプリの作り方を学んでいましたが、今後はCDSやFiori Elementsが主流になるでしょう。そういうわけで、アプリの開発周りのことを網羅的に知りたいと思っていたのでこの本はうってつけでした。
##この記事で伝えたいこと
本書の中ではCDS、SAPUI5、Restful Programming Modelなど様々な技術が紹介されていますが、全体を通して重要なテーマだと感じたのは次の二つです。
- テストの自動化、TDD
- モデルとフレームワークは分離すること
###1. テストの自動化、TDD
####テストの自動化
本書で紹介されているフレームワークや技術には、ほぼすべてにテスト自動化の仕組みがついてきます。ここでいう自動化とは「コードを書いたら自動的にテストができる」ということではなく、同じテストを何度も自動で実行できるようにしておくということです。この仕組みがあると、ソースを修正したときに影響を即座に確認することができます。
ABAPのソースコード管理は将来的にGitへ向かうようですが、修正したソースを本番化する前に不具合がないか自動で確認することもできるようになります。
####TDD (Test Driven Development)
著者はTDDでの開発を勧めています。なぜなら、テストできるコードは良いコードだからです。ここで言う良いコードとは、他への依存性が低いコードということです。
TDDは①コードを書く前にテストを書く、②テストする（もちろん失敗する）、③コードを書く、④テストをする（成功）、⑤コードをリファクタリングする、という流れで進めます。
テストをするためにはメソッド同士の依存関係ができるだけない状態にしておく必要があるため、テストを先に書くと自然と依存性の低いコードになります。
####自動テストやTDDは普及するのか
テストを自動化するためには、テスト用のクラス（あるいはコード）を別に用意する必要があります。当然、初期の開発工数は自動テストをしない場合に比べて大きくなります。決められたスケジュールの中、導入ベンダー側から自動テストやTDDで進めるということは提案しにくいのではないかと思います。テストの自動化は保守フェーズにおいて最も効果を発揮するので、恩恵を受けるのは顧客です。顧客側から「自動テストができるようにしてほしい」という要望を出せば、ベンダーとしても対応せざるを得なくなるのではないでしょうか。
####テストの自動化、やってみた
テストの自動化について掘り下げてみたくなったので、以下のシリーズを始めました。
【ABAP】ABAP Unitを使ってみよう(1) ～簡単なところから
###2. モデルとフレームワークは分離すること
####モデル、フレームワークとは（私の理解）
モデルとは、データ定義やバリデーションなどのビジネスロジックを表します。フレームワークとは、UIやデータ取得のために用意された、再利用可能な仕組みです。UIのフレームワークならSAPUI5やWebDynpro、データにかかわるフレームワークならCDSやBOPF、といった具合です。
####なぜ分離する必要があるのか
最近のSAPの動向を見ていてもわかるように、フレームワークはどんどん新しいものが出てきます。一方で、モデルはフレームワークの技術とともに変わるものではありません。図1のように個々のフレームワークの中でビジネスロジックを書く場合、新しい技術が出てくる都度、同じようなロジックを書かなければなりません。
図1: モデルとフレームワークが分離していない例
本書の中ではALV、WebDynpro、SAPUI5などさまざまなUI技術が紹介されますが、データに対する操作は同一のモデル（ZCL_MONSTER_MODEL）で行われています。こうすることで、新しいフレームワークが出たときに既存のロジックを利用して開発ができるため、効率性が高まります。モデルはすでにテスト済なので、開発者はUIとモデルのI/F部分だけに集中すればよく、品質面でも優れているといえます。
図2: モデルとフレームワークが分離している例
このようなやり方は従来も汎用モジュールなどを利用して実践されていたケースもあって特別新しいものではありませんが、技術の変化が早くなっているので設計段階から再利用を考慮することがより重要になると感じました。
##さいごに
###SAPの新技術、どこから手をつけたらよいのか？
繰り返しになりますが、ここ最近技術の変化が本当に早くなっていると感じます。せっかく新しい技術を勉強しても、使う機会が来る前にその技術は廃れてしまうかもしれません（それはそれで、無駄ではないはずですが）。
開発者として、まだ新技術を使う機会のないプロジェクトや保守の現場にいたとしたら、どこから手をつけたらよいのでしょうか？
私は今後のトレンドにも左右されないであろう、「基礎の基礎」は以下2点だと考えています。
####エディタはSExx系トランザクションではなくEclipse (ABAP ADT)を使う
CDSやBOPFなど、新しい開発オブジェクトは基本、Eclipseでの開発となります。Eclipseではレポートプログラムや汎用モジュールの開発もできます。Eclipseの使用感や機能に慣れるためにも、今後の開発はEclipseに寄せていくのがよいと思います。EclipseにADTをインストールする方法については以下の記事をご参照ください。
【ABAP】ABAP Development Tools (ADT) をインストールする方法
####OO(Object Oriented) ABAPで開発する
今後のABAP技術（フレームワーク）では、基本的にOO ABAPを使用することになります。標準プログラムを追うときも、OO ABAPを知っていると理解の助けになるでしょう。
OO ABAPで設計するとき、個々のクラス・メソッドにどんな役割を持たせるのかを意識します。この過程で大きなタスクは小さなタスクに分解されます。目的がはっきりした小さなタスクは自動テストにも適合しやすいはずです。
ところで、私が過去いた現場でOO ABAPが使われているのをほとんど見たことがありません（OO ABAPは20年近くも存在しているにもかかわらず！）。皆さんの現場はどうでしょうか？ もしまだ一般的でないなら、ひっそりとはじめてみてはいかがでしょうか。たとえば汎用モジュールを作る代わりにABAPクラスにするなど。
#####追記：ABAP 7.31からサブルーチンが廃止になった
@okabanaさんからご連絡いただいたのですが、ABAP 7.31からサブルーチン（FORM ~ ENDFORM）が廃止されました。⇒公式ドキュメント
レポートや汎用モジュールの中で使われていたサブルーチンですが、もう推奨されません。メインのロジックを丸ごとクラスにして、それを（必要ならば）レポートや汎用モジュールでラッピングするという実装になると思います。