ほえほえのプログラミング情報（2021年7月投稿順）

ほえほえ＠スプシマン @hoehoe1234

システムとして組む場合のアーキテクチャとかいう以前にモジュール分割できないケースが多いように思います。モジュール分割とはなにか？といえば、アプリを組むことそのもののように思います（もう一つは全体構成についての指針、方針）。なのでここは避けれないとおもうのですがどうなんでしょうね。

ほえほえ＠スプシマン @hoehoe1234

関数をデータパイプライン（INOUT変換）としてモデル化するか、機能としてモデル化するかで分割手法が異なるんですよね。あとは繰り返しをどう表現するか、結合方式をどう考えるか。ほとんどのサイトはヨードン、ジャクソンなどをなぞっているのに過ぎないので参考にならないんですよね。

ほえほえ＠スプシマン @hoehoe1234

２～３０、多くのサイトをみましたが、壺１がもっとも手法として確立しているように思いました。壺１は問題意識をもって読み込まないと「なにをいっているのか？」わからないんですよね。エッセイ形式なのもそれに拍車をかけています。ほんとはOSSから逆にモジュール構成を抜き出すといいんですけどね

ほえほえ＠スプシマン @hoehoe1234

C言語とかだとクロスリファレンスとかモジュール構成図がツールで出せるのでそれで研究してみてもいいかもですね。時間があればある程度大規模なC言語のOSSのモジュール構成を比較、解析してみたいです。

ほえほえ＠スプシマン @hoehoe1234

ざっとみですけど、アパッチなんかだと引数の１つめに構造体ポインタを取ったりしますので、これはハンドオブジェクト指向設計なんですよね。golangのレシーバと同じ感じですね。結局そうなるのかな？という予感はしますけど。とにかくやってみたいとは思います。

ほえほえ＠スプシマン @hoehoe1234

インデントはなぜするか？当然視認性のため。全体ー部分の構成をみやすくするため。なので一般的なインデント手法はあるが、みやすければどうてもいいと思う。逆に、アーリーリターンを理解してないインデントは不用意にネストが深く意味がつかめない。目的は「視認性」。インデントは単に手段。

ほえほえ＠スプシマン @hoehoe1234

@excelvba_diary ですね。そのような機能からの分割がわかりやすいとおもいます。データに注目したDFD、ジャクソン法、関数のデータパイプラインとして構成技法も試しましたが難易度と分割のための資料作成コストが高すぎるとおもいました。再現性のあるモジュール分割はほんと難しいです。