CodeZine(コードジン)

特集ページ一覧

レガシーコードから脱却するために有効な方法とは? ルール駆動開発が解決する課題【デブサミ2020】

【14-D-3】全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、“ルール駆動開発”

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/03/17 12:00

 「スパゲティコード化・ブラックボックス化したレガシーなアプリケーションを、どう改修するか」こうした課題に悩んだことのあるエンジニアは少なくないだろう。既存ロジックを壊さず、かつ最小限の工数でレガシーコードを修正することは、エンジニアにとって難易度の高いタスクの1つだ。この課題に解を示す開発手法が、ルール駆動開発である。複雑にソースコードが絡み合った既存システムを、うまく解きほぐすための手法とは? レッドハット株式会社で培われたノウハウとベストプラクティスを、松田絵里奈氏が紹介する。

目次
レッドハット株式会社 Senior Specialist Solution Architect 松田絵里奈氏
レッドハット株式会社 Senior Specialist Solution Architect 松田絵里奈氏

既存コードの解析ではなく、業務要件の把握からスタートする

 ルール駆動開発とは、以下の特徴を持った開発手法である。

  • ルール(ロジック)とデータアクセスを完全分割
  • 業務目線でルールを整理し、そのまま実装
  • 小さく作ってはテストをくり返す、イテレーション開発

 読者のなかには、モノリシックなレガシーアプリケーションの改修プロジェクトに携わった経験のある方もいるかもしれない。例えばクライアント企業から「既存のアプリケーションと全く同じ機能を持ったアプリケーションを、他の言語で作り直してほしい」といった要望があったと仮定しよう。

 そうしたケースにおいて、要件定義書や設計書などのドキュメント類が全てそろっているケースはまれだ。多くの場合は資料が不足しているか、内容に不備があり読んでも役に立たなかったりする。そうした場合、どのような方法でリプレースを行うべきなのだろうか。

 「一番やってはいけないのは、既存のプログラムの解析から入ることです。現行のソースコードは多くの場合、継ぎ足しでのメンテナンスが行われており、『秘伝のタレ』のような状態になっています。

 また、不要コードが残ったままになっていることも多いです。私が経験した某案件では、『既存コードのうち約60%が不要ロジックだった』ケースすらありました。コード解析からスタートしてしまうと、必要なプログラムとそうでないプログラムの判断がつきにくくなってしまいます」(松田氏)

 では、ルール駆動開発においては、どのようなアプローチで既存アプリケーションの解読を進めていくのだろうか。その答えは「まず、業務内容を知っている人にヒアリングしに行く」ことだ。本来、アプリケーションのリプレースにおいてエンジニアが知りたい情報とは、プログラムの中身そのものではなく「どのような業務要件が必要なのか」である。

 ヒアリングにおいて、注意すべき点がある。業務内容を知っている社員に1から10まで全てを聞くと時間がかかるうえ、全体像を把握しているメンバーはそうそういない。そのため、「あなたが携わっている業務の情報だけをまずは聞かせてください」とお願いし、基本的なルールから質問していくことが肝要である。

 また、業務マニュアルや業務フロー図など、システム要件を把握するのに便利な資料を業務担当者が持っているケースもある。資料を発掘するという意味でも、社員へのヒアリングは非常に有効である。

 可視化した業務要件は、DMN(Decision Model and Notation)を用いて図示していく。これは、業務的な意思決定を説明してモデル化するために、OMG(Object Management Group)が確立している規格である。DMNの内容をもとに、業務担当者と認識のすり合わせを行っていく。このプロセスを経ることで、開発の手戻りや設計・実装の誤りを最小化できるのだ。

DMNを用いて業務要件を整理
DMNを用いて業務要件を整理

 業務内容の整理ができたら、次は一連の業務ルールをサービスとして切り出す。例えば、「請求金額を算出する」ために必要な一連の業務ルールがあるならば、その塊を1つのサービス単位として分離する、といった具合だ。切り出し後は、どのようなインプット・アウトプットが必要かというインターフェースを定義していく。

 アプリケーションがスパゲティコード化しやすい理由の1つとして、「業務ルールとデータアクセスが混在している」という要素が挙げられる。例えば、「何かの条件分岐を判定するために、特定のマスタデータにアクセスする。その判定が正であれば、別のテーブルに格納されたデータを取得する」といった処理が積み重なれば、コードは一気に難読化していく。

 ルール駆動開発では、そうしたロジックの複雑化を回避できる。業務ロジックを1つのサービスとしてまとめ、REST APIなどを経由して呼び出す形をとるためだ。サービスの適切な分離により「ルールのテストがしやすい」「改修時の影響分析範囲が狭まる」「データベース構成の変更影響を受けにくい」などの利点が生じる。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

バックナンバー

連載:【デブサミ2020】セッションレポート

もっと読む

All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5