元ネタを渡すと何らかの答えを返してくれる存在、あるいはその手続き自体のこと。
SAPの[[ABAP]]プログラミングにおいては、[[サブルーチン>アドオン/サブルーチン]]や[[汎用モジュール>SAPのオブジェクト/汎用モジュール]]と言えばピンとくるだろうか。
* 目的 [#n312fc22]
-繰返し利用する命令をひとつの手続きとしてまとめることで、可読性を維持する
これに反した例を端的にいえば、同じような処理をコピペして差分だけ直すようなもの。
単純に見にくいし醜いし、ミスが起きやすいし、バグ発覚時の修正も現象が低レベル過ぎてゲンナリする。
''コードのコピペは低能の証''ということを、肝に命じられたい。
-繰返し利用する命令をひとつの手続きとしてまとめることで、保守性を維持する
例えば同じ式で異なるフィールドを計算する場合、どちらかは異なった動きをしうる。
これを一つの関数にすれば、処理自体が正常であることを担保すれば、フィールドごとの利用は受け渡しだけの試験で済んでしまうし、バグがあれば修正は一か所で済む。
式をコピペしてしまっては、修正はすべての個所に及ぶし、単純にいじるコードの総量が増えれば修正漏れやデグレの率も高くなるというもの。
-繰返しなくても、意味的なまとまりを示す
設計書のフローチャートの箱ごとに分ける、と表現すれば平易か。章や項で処理が分かれていれば、書きやすいし読みやすい。バグだって潰しやすいし、トラブルシュートもやりやすい。
コードが読み易ければ、本を読む感覚で理解できるという面もあるかと思う。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
