memo/20230928

直流の電圧変換回路（DC/DCコンバータ）を勉強中ですが挫折気味です。

それはそれで。本を読んでいて改めて思ったこととして、電気回路って、配置思考的というか、位置関係思考的なところがあるなぁ、と。

ソフトウェア設計も、電気回路の設計みたいに、カタマリの配置で特性が生じたり、何々方式と名付けがなされたり、そうならんものだろうか。

ギター演奏の上達過程にて、コードフォームを「図形的に」暗記することで思考がショートカットできる、という時期があります。まぁ、そこから少し進むと、そういうショートカットでは進めなくなって、基礎からやり直すという再学習行為が何度も必要になるのですが…。でも図形思考で上達する時期があるのは、間違いないし、その思考方法はもっと上達した段階でも、全く無駄にはならないです。

で、ソフトウェアにもそういった「図形的な」思考で、組み上がったロジックの出来が良いとか悪いとかの判断を、一部ショートカットできる、ような方法があるのでは？と思って探しているのです。ずっと。クラスの役割とトポロジカルな配置に名前を付けて、ソフトウェアの「デザインパターン」と呼んだ時期がありましたけど、なんかあの話って結局は滑って終わった感があります。当初期待された壮大なゴールに着地できなかった。
ソフトウェアのプリミティブ要素とは、何と何だろうか、という研究が、足りていない気がするんです。それがいわゆるGoF本だと、OOP言語のクラス。ダイクストラの構造化プログラミング論だと {順列 | 条件分岐 | 繰り返し} でしたっけ。

でもそのもうちょっと中間あたりのサイズで、「ソフトウェアの構成要素はコレとコレとコレだ」っていい感じに抽出したもので、図形的に考えることが上達の助けになるようなもの、って無いですか？という話。


【* 日々のメモ】