COBOLから一段現代化
前に、「因果と確率 ４」にて、
しかしながら、COBOLプログラムなどで、
- 商品の内容から金額を出す
と言った、テストし易い課題と異なり、
- 何々を満たす"全てのもの"から何ちゃらの処理をする
と言った、業務のキモに当たる課題では、陰関数的になるのが100%の通例でした。
と書きましたが、
現代では、ブラウザというアプリが有り、事情が変わっています。
一段、現代化しないといけません*1。
すなわち、
- テストし易い陽関数で無く、陰関数になる原因の変化
です。
ブラウザというアプリ
ブラウザというアプリには、1つの決定的な性質が有ります。それは、
- SUBMITに当たる処理は、必ず人間のマウスクリックが必要で、
- それをプログラムが模倣出来ない（自動で進められない）
という性質です。
それに対し、バックエンド（”何々を満たす"全てのもの"から何ちゃらの処理をする”などをする）では、ある程度以上、自動で進んでもらわないと行けません。
「自動で進む」為には、
「自動で進む」為には、
- 責務的処理（陽関数に出来る）
のみで無く、
- 責務的処理（陽関数に出来る）
- その後に、『次のプログラムの「単位」の為の準備処理』ー２
が少なくとも必要で、場合によっては、
- その前に、『前のプログラム「単位」からの引数チェック』ー１
- 責務的処理（陽関数に出来る）
- その後に、『次のプログラムの「単位」の為の準備処理』ー２
も必要になり、
- 責務的処理を陽関数にすると、
- その前後の、「自動で進む」為に必要な処理は、陽関数に出来なくなる（関数の表現能力の枯渇）
となるのでは無いかというのが、私の（熱心な）実感です。
なぜ「自動で進む」為にはそれらが必要か？
- 陽関数は絶対に「自動で進む」事が無く（それが本質だから）
- 「自動で進む」為にはそれ以外の何かが必要
で、一般的には、
- 前から、後の為（上記ー１と、ー２）
という性質を持つプログラムの部分を追加する事で、その必要を満たすのでは無いかというも、私の（熱心な）実感です。
責務的処理を不用意に陽関数化（テストし易い）する事が、全体のテスト（前から、後の為を含んだ、「自動で進む」処理のテスト）を遅滞させる原因になりうる、とも言えます。
結論
これからも『プログラムの「単位」』について、主な責務以外の点についての考察不足が原因でプログラミングが嫌いになる人は存在し続けることでしょう。
