関数の独立性

先日投稿した『変数や関数の宣言とスコープ』のまとめとして『チーム開発を意識したプログラミングではスコープはできる限り絞った方が良いことになります』と記載しました。これは、何か変更が必要となった時の影響範囲が狭くなる効果があるからです。

LotusScript で開発を行うと、ほぼ必ずと言っていいほど関数を作成します。この関数作成においても影響範囲は小さい方がよいとされています。理由はスコープと同じですね。

情報処理試験のようなお堅い世界では、この影響範囲の度合いを ”独立性” といいます。今回はこの独立性という側面から、関数とはどうあるべきか考えたいと思います。

なお、記載に当たっては ”モジュール” という一般的な言葉を使用しています。LotusScript の場合であれば、関数やサブルーチンを思い浮かるとよいかと思います。

独立性とは

”断捨離” なんて言葉ありますが、無駄なものを切り捨てて身辺整理するとシンプルな生活が送れます。モジュールも同様で、無駄を削いで、必要以上のしがらみを持たないようにすればシンプルにできます。その度合いを表すのが ”独立性” です。

独立性を表す指標には 2 つ存在します。『モジュール強度』と『モジュール結合度』です。少し硬い話になりますが簡単にまとめます。

なお、説明は LotusScript 的に表現するため、私なりに意訳しております。正確な情報が必要な場合には、信頼あるサイトや専門の文献をご確認ください。

モジュール強度

機能的な関連の強さを表す指標です。

モジュール強度が ”強い” ほど独立性は ”高い” といえます。

独立性	モジュール強度
低い ↑ ↓ 高い	弱い ↑ ↓ 強い	暗号的強度	単純にいくつかの関数に分割した場合など関数の機能を明確にできない場合
		論理的強度	関連する複数の機能をまとめて作ったモジュールで、１つのインターフェースで複数の機能を実現する場合
		時間的強度	初期設定など特定のタイミングで実行されるが他の機能に関して弱い関連しか持たない場合
		手順的強度	バッチ処理のように複数の機能を逐次実行するが、各機能間の関連性は弱い場合（業務仕様上の関連は持っている）
		連絡的強度	ある機能の結果が次の機能の入力になる場合など、手順的強度に加えデータも関連する場合
		情報的強度	同じ構造のデータを扱う複数機能を持ったモジュール
		機能的強度	１つの固有な機能のみを持つモジュールで、モジュール内の全ての要素がその機能に関連している場合

モジュール結合度

データ的な関連を視点に表す指標です。

モジュール結合度が ”強い” ほど独立性は "低い" ことになります。

独立性	モジュール強度
低い ↑ ↓ 高い	弱い ↑ ↓ 強い	内容結合	他のモジュールの内容を直接参照する場合やモジュールの一部を共有する場合 ロータススクリプトでは見られない結合
		共通結合	共通のメモリ領域を共有するような場合 ロータススクリプトでは見られない結合
		外部結合	パブリック変数を使用し、モジュール間でデータを共有する場合 パブリック変数をどう使っているかわかりづらく、再利用しにくい
		制御結合	モジュールの動作を決定する情報をインターフェース（引数）で渡す結合 引数により制御されるためモジュール間の関連性は高い
		スタンプ 結合	パブリック変数でない同じデータ構造をインターフェースを介して共有する結合 ただし、直接必要としないデータ（関連する他のモジュールで利用するデータ）を含む場合
		データ結合	モジュールで必要なデータのみをインターフェースとする結合 独立性がもっとも高く、再利用が容易

独立性を高めるためには

さんざん細かいことをのたまったあとにどうかと思うのですが、上記の指標は事細かに記憶する必要はありません。「こんな風に作ると独立性は下がるんだ」という事例のようなイメージでとらえていただければと思います。

独立性を高めるポイントを端的に言うと、

1. できる限り単機能にする
2. 必要なデータのみで作る

となります。

関数の作成という視点では、単機能な関数を作成して、処理に必要なデータだけを引数で渡すということになります。

チーム開発と独立性

独立性を高めるとプログラムがシンプルになり、理解しやすくなりそうだということは、容易に想像できます。ただ、”うんちく” じゃなく ”使える” ネタが欲しいと思いますよね。

誤解を恐れずに言えば、次のような点を意識して開発すればよいかと思います。

◇ 関数は 1 画面に収める

一つの関数が複数の機能を持つと得てしてコードが長くなります。１画面に収まらない長さになった場合、複数の機能がないか確認し、分割を検討してみましょう。

単純な関数であればあるほど、変数の数も減りますし、機能を誤解なく表現できます。そして、後任者には、より明確に意図が伝わります。

◇ 関数の集合で機能を実現

単機能な関数ができたら、複数まとめて機能を実現する関数を作ります。手順的強度や連絡的強度の関数ということですね。

こういった関数は、処理の羅列となり、処理の流れがとらえやすく、わかりやすいプログラムになります。

ノーツ的な側面では、私は次のような点を注意して開発するようにしています。

◇ 外部結合に注意

notes.ini の環境変数や文書のフィールドなどの操作はパブリック変数のようなものです。関数の奥の方でこれらにアクセスしていると独立性は低くなると考えています。できる限り、外側で値を取得して、関数には値を渡すようにしましょう。

◇ 処理をそろえる

LotusScript では、文書を取得して、何らかの処理を加えて、保存するというような処理を書くことが多いですが、文書の取得と保存を同じ関数内に記述しましょう。こうすれば、取得から保存までの間のコードは ”文書に何らかの処理を加えているだけ” にでき、将来の改造にも強くなるといえます。これも一種の独立性だと思います。

改造を繰り返すアプリでは、一連の処理で何度も保存を繰り返しているのを見ることがあります。レスポンスの懸念以上に、作成者や読者などの権限系のバグにつながる可能性がありますので注意しましょう。

プログラミングは言語ですから正解は一つではありません。回りくどい表現であっても論理的に正しければ、正しい結果を得ることができます。とはいっても、わかりにくい表現、誤解を招くような表現はよくないですよね。特に、ビジネスやチームでの開発では、シンプルでストレートに伝わるコーディングを心がけることが重要です。

今回は最近の潮流であるノーコード、ローコードとは逆行するネタでした。独立性なんて意識せず ”使える” アプリができる時代がくればいいのですが、もう少し先ではないかと思います。現時点では、少し込み入った機能を作る際には必要な知識でしょう。

独立性に思いを馳せるだけでも、ステップアップになると思いますよ。