どの様な話？
「単位」とはここでは、
- 因果ダイアグラムの原因から出た矢印を、
- プログラムが結果として受ける
- プログラムのかたまり
を言います。
それについて、私は一貫して、
- プログラムの部分、一部分
- （関数も含む）
と言ってきました。何でそのかたまりを、
- 関数だ
と言い切らないのか、私の信念の形成内容についてご披露いたします。
プログラムの（模式的）例
例として、COBOL言語のバッチ処理プログラムについて、模式的に示します。*1
- 前処理
A.変数初期化【後】
B.引数内容（前のプログラム「単位」からの）チェック【前】
C.入力、出力データセット*2 オープン【他】
D.次のプログラムの「単位」の為の準備処理【後】
E.入力データセットで、次レコード位置付け【後】 - 主処理（データセットを読み終わるまで繰り返す）
A.責務的処理の為の準備処理【後】
B.責務的処理【主】
C.出力レコード編集の為の準備処理【後】
D.出力データセットで、レコード書き出し【後】
E.次のプログラムの「単位」の為の準備処理【後】
F.入力データセットで、次レコード位置付け【後】 - 後処理
A.入力、出力データセットクローズ【他】
となります。
【前】と有るのは『前からの処理の為のプログラムの「単位」』で、
【後】と有るのは『後に続く処理の為のプログラムの「単位」』で、
【主】と有るのは『責務を果たす主となるプログラムの「単位」』で、
【他】と有るのは『（確かに原因を持つが）責務には直接関係無い
プログラムの「単位」』
となります。
責務的な処理以外にも処理は有るのが現状だと思います。
関数として独立させ易い「単位」と、させ難い「単位」
【主】と有る部分なら、関数として独立させ、テストもモックで出来ると思いますが、
【前】、【後】と有る部分は、極力関数にしたがる人でも、中々しない（出来ない）と思います。
理由は、
- それらが、「前からの為の」、「後への為の」処理であり、
- 【前】、【後】と有る部分のみを関数としても、有利にならず、
- スコープ・引数で隔たりを作り、絞る分、実装面で不利になる場合も多い
からだと思います。
関数として独立させ難い「単位」とは言え、軽視すべきでは無い
【前】、【後】の様な部分は、
関数として独立させ難い「単位」とは言え、
因果ダイアログの原因からの矢印に指向された、歴とした処理で有り、
- 責務云々の観点からすれば、見るべきでも無い、些細な物
となるのかも知れませんが、
- 原因からの矢印に指向されている以上、そちらの観点からするならば、
仕様との適合性に齟齬があったら、即不具合と成る
重要な、夢夢、軽視すべきで無いプログラムの「単位」なのも事実です。
ですので、
プログラムの「単位」（前述の定義での）では、
- 関数だ
とは言い切れない、絶対に無理で、
- プログラムの部分、一部分
- （関数も含む）
とするのが、最も妥当だという信念を持つに至った訳です。
結論
これからも『プログラムの「単位」』について、主な責務以外の点についての考察不足が原因でプログラミングが嫌いになる人は存在し続けることでしょう。
