ここからは、実際にプログラムをどう組んでいったかという話になります。
私はJavaScriptを専門にしてきたわけではありません。
もともとはネットワークエンジニアで、プログラミングについても、C言語を中心に触ってきました。仕事としてコードを書く場合も、ゼロから何かを作るというより、既存のプログラムにパッチを当てたり、必要な部分を修正したりすることの方が多かったと思います。
それでも、プログラムを書くこと自体は嫌いではありませんでした。
今回も、最初からJavaScriptの作法を完璧に理解していたわけではなく、C言語で考えてきた感覚を手掛かりにしながら、JavaScriptではどう表現するのかを調べつつ作っていきました。
最初に考えたのは、料金をどこに持たせるかです。
料金をプログラムのあちこちに直接書いてしまうと、料金改定のたびに探し回ることになります。
それなら、料金に関する情報をある程度まとめて持たせておいた方がいい。
C言語であれば構造体などを使って、関連するデータをひとまとめにする、という考え方があります。
JavaScriptにも、オブジェクトなどを使って同じように関連するデータをまとめて扱う方法があります。
そこで、料金や制度上の条件をできるだけ整理して持たせ、必要なところから取り出して使う構造にしていきました。
計算ロジックと表示部分をどう分けるか
次に考えたのが、計算する部分と、画面に表示する部分をどう分けるかです。
これは昔からプログラムを書いている人間としては、なるべく分けておきたいところです。
一つの巨大な関数の中に、
「入力を読む」
↓
「計算する」
↓
「結果を表示する」
を全部詰め込んでしまうと、後から変更するのが大変になります。
そこで、全体の計算をいくつかの小さな処理に分け、それぞれを関数として組み立てていくことにしました。
料金の計算も、
マッサージ部分
変形徒手部分
鍼灸部分
往療部分
訪問人数による部分
負担割合による部分
というように、役割ごとに分けて考えていきます。
小さな塊に分けておけば、あとから必要なところだけ確認できます。
そして、その計算結果を画面に表示する部分は、また別の話になります。
こちらはHTMLを使って画面を作り、JavaScriptからその表示を動かしていく。
今回のプログラムでは、この「計算するところ」と「見せるところ」をなるべく分離することを意識しました。
負担割合をどう扱うか
負担割合についても、少し考える必要がありました。
基本的には、
1割
2割
3割
を選択できれば、利用者様向けの料金表示としては十分です。
ただ、施術者側が制度上の料金を確認したい場合には、10割の金額も必要になります。
また、療養費の支給については、現物給付だけではなく、償還払いという形になる場合もあります。
そう考えると、
「利用者様が実際に負担する金額」
と、
「制度上の療養費として計算される金額」
は、同じものとして扱わない方がいい。
そこで、負担割合を単なる固定値としてではなく、計算結果を表示するための一つの条件として扱うことにしました。
マッサージ／鍼灸／併施をどうモード化するか
次に出てきたのが、マッサージと鍼灸をどう扱うかという問題です。
マッサージの場合は部位数などによって計算が変わります。
鍼灸には鍼灸の計算があります。
そして、マッサージと鍼灸を併せて行う場合には、さらに別の組み合わせが発生します。
これを全部、
「もしマッサージなら……」
「もし鍼灸なら……」
「もし併施なら……」
と個別に書いていくこともできます。
しかし、それでは条件が増えるたびにプログラムが複雑になります。
そこで、施術の種類そのものを「モード」として扱うことにしました。
「現在はマッサージを計算している」
「現在は鍼灸を計算している」
「現在は併施を計算している」
という状態をプログラム側で持たせることで、共通する計算と、それぞれ固有の計算を整理しやすくなります。
こういうところは、実際にプログラムを書き始めてから、
「こうしておいた方が後が楽だな」
と気づいていった部分でもあります。
「料金改定」と「プログラム修正」をどう分離するか
今回のプログラムでは、ここもかなり重要でした。
療養費は改定されます。
つまり、今回動いたからといって、そのまま何年も変更せずに使えるとは限りません。
そこで、
「料金が変わること」と「プログラムそのものを修正すること」をできるだけ分けておきたい
と考えました。
料金が変わっただけなら、料金を持っている部分を変更すればいい。
計算方法そのものが変わったなら、計算ロジックを変更する。
新しい機能を追加したなら、その機能を追加する。
こうしておけば、料金改定のたびにプログラム全体を触り回る必要がなくなります。
実際、今回のプロジェクトでは、制度改定に伴う料金の変更と、通常のバグ修正・機能追加を別のバージョン管理として考えるようにしました。
これは後の公開・ライセンスの話にもつながっていきます。
UIと計算部分をどう分けるか
そして、最後が画面です。
JavaScriptは、私にとっては昔からHTMLと組み合わせて使うものという印象が強い言語でした。
HTMLに文章を表示したり、定型的な内容を挿入したりするところから始まり、現在ではDOMを操作することで、画面そのものを動的に変更できます。
ただ、私がエンジニアを離れた頃には、現在のようなJavaScriptの書き方はまだ身近なものではありませんでした。
そこで今回は、昔知っていたJavaScriptの記憶をそのまま使うのではなく、現在のJavaScriptの書き方を調べながら組んでいくことになりました。
そして、
計算する部分
と
画面を作る部分
を分けておく。
これは単にプログラムを綺麗にするためだけではありません。
将来、
「計算方法は変えずに画面だけ変えたい」
あるいは、
「画面はそのままで計算方法だけ変更したい」
ということが起きても対応しやすくなります。
今回のシミュレーターは、最初から大きなシステムを作ろうとしていたわけではありません。
むしろ、
「料金表を動かしたい」
という小さなところから始まったものです。
だからこそ、後から制度が変わったり、機能を追加したりすることを考えながら、できるだけ小さな部品に分けて作っていくことにしました。
そして、ここまで設計を考えてくると、次は当然、
「では、実際にJavaScriptを書いてみよう」
というところへ進みます。
