アセンブラとモジュールメーカーという分業

とりあえず『ごるふぁんⅡ』もこんなところ。

ごるふぁんⅡ

こういう動きをさせるのに、アセンブル担当者が書くプログラムコードはこれだけ。

(d)=>{
ScoreBoard.init(this, RoundData);  //スコアボードの初期化
this.yard = {code:1, name: 'ごるふぁんParkGoldYard'};  //ゴルフ場の設定（★ダミー）
this._obj('yard/blocks/confirm').title = that.yard.name;
}

d=>ScoreBoard.marker.open(d, 'portrait')   //ポートレイト型のセルを選択⇒スコア入力カードを開く

d=>ScoreBoard.marker.open(d, 'landscape')  //ランドスケープ型のセルを選択⇒スコア入力カードを開く

d=>ScoreBoard.storeData(d)	//スコア入力カードで入力⇒1コースの1ホールのスコアを保存

d=>ScoreBoard.setCourse(d)  //コースを選択⇒コースを保存。スコア入力カードを設定

d=>{
//ゴルフ場を選択⇒
ScoreBoard.board.init({
code: 'golfun',
courseCount: 3,
yard: this.yard.code
}); //スコアボードのボードの初期化
this.selectCourse();  //コースの選択
this._obj('main').current = 'score';  //スコアボードを開く
this._redraw('main');
}

アセンブラ、あるいはそれを兼ねたディレクターがこれだけ書いて
あとはモジュールメーカーにオーダーする。

ただ実はこの「ScoreBoard」はアプリに依存してるから
この「モジュール」は汎用的なものじゃなくてアプリエクスクルーシブなんだけど。

モジュールの依存性

「依存性の注入（DI＝Dependency Injection）」なる言葉。
どうもすんなりと入ってこなくて困惑してるものの一つ。

「ポータブルなモジュールを作って」
とオーダーしても理解されないこともあった。
できたもののコードはばりばり依存してた。

モジュール化の最大のメリットはポータビリティ。
つまりアプリケーションに依存せず、必要に応じてほかのモジュールに置き換えることができること。

エンジニア人生をポータブルなモジュールが当たり前で始めたから
「コンポーネントやオブジェクト間の依存関係を解決するための手法」
って何を今更
と。

例えば最も小さいポータブルなモジュールは関数。
DIは引数で行う。
これがオブジェクトになればプロパティになる。
ちょっと高度なことをするにはコールバックを使う。

”離れた”モジュール間では何らかのメッセージングで行う。
それの最も低水準なものがコマンドラインのパイプやファイルシステム。
もっと離れたらプロセス間通信
さらに離れたらhttpなどを通信プロトコルを使う。

システムを設計する際は、ユーザーもひとつのモジュールとして考えるといい。
専属オペレータから”ポータブル”なゲストユーザーまで
そのシステム依存度に合わせて設計することが重要になる。

モジュール化の意味

とはいえ、このアプローチはエンジニアには何の意味もない。

ほとんどのプロジェクトは垂直分業で開発してるから、かえって手間が増えるだけ。

スタッフの書いたコードを全部隅から隅まで読んでチェックするのが自分の仕事だと、中にはそう思ってるPMやPLも多いけど
そういうボスにとってはむしろモジュール化は忌まわしいものだ。
いちいちモジュールを”開けて”見ないとならないのはめんどくさい。
上からずらずらと書いてある”昔ながら”のコードの方が読みやすい。
たとえ数千行あろうと。

モジュールを使ってアプリケーションのコードをせっかくコンパクトにしてあっても
それを読むのにそこからモジュールにジャンプして
しかも「依存性」がどうなってるのかも読み解くなんて
そりゃ大変に決まってる。
たとえスーパーエンジニアでもそこはマシンのようにはいかない。

でもモジュールになってれば、モジュールのテストはマシンで自動でできる。
ただテストコードが必要というなら、その”コスト”は見逃せないものになる。
だからモジュールもその仕様も統一されていればいい。
それがESPの思想。

依存性のくびき

でもこういうPMでもライブラリやコンパイラやOSのコードは開けて読まないのね。

逆にどんなモジュールも依存性からは逃れられない。
その最たるものが言語。

例えば「文字列の2文字目から3文字を切り出すコード」。

JavaScript:

const slicedStr = str.slice(1, 4);

Python:

sliced_str = str[1:4]

Java:

String slicedStr = str.substring(1, 4);

Ruby:

sliced_str = str[1, 3]

Go:

slicedStr := str[1:4]

言語ごとでこうなる。
これらは「言語フレークワーク」に依存していて、この関数を使ったモジュールも言語に依存する。

みな書きやすさを創意工夫して競ってるわけだけど・・・
あほくさ。

処理: 文字を切り出す
元の文字列変数: str
開始位置: 1
長さ: 3

どれもエッセンスはこれ。

コードは書けなくても、これが明確にできれば、コードを書かせられる。
今どきはAIにも。

これがロジカルシンキング。

これからは言語を書けることじゃなくてロジカルに組み立てる能力が重要になる。
ともう10年も前から叫ばれてるけど
教育はそうなってるのかな？