2021-04-20 エクセルVBA 男坂。この果てしなく遠いエクセルVBA道を友（とも）と駆け抜ける

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

swtch関数を読み切ってからカーネルのコードがちょっとわかってきた感じ。仮想記憶、forkときてやっとswtch関数が理解できた。しかし、またしてもexec関数という巨大な壁が立ちはだかるｗｗｗ。

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

は～～あ、たしかにswtchの仕組みがわからないと質テムコールはまったく読めないわな。逆に言うと、仮想記憶、swtchの仕組みがわかればかなりのシステムコールが読める。forkから解説しているのは「なるほど」というかんじ。

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

カーネルは、ユーザプロセスからみた場合に、 ①コードを共有 ②データセグメントを共有 ③スタックのみユーザプロセスごと となっていて、他のプロセスから呼ばれたswtchがなぜか違うプロセスのswtchとして機能するようになっっている。

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

ユーザプロセスからみたら自分専用のライブラリがあるように見える（実際にそう）んだけどカーネル視点だと鵜飼いのようにたくさんのユーザプロセスからの要求をうけてさくっと違う鵜にまわしているようなイメージ。

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

もっともわかりにくいのは、swtch関数に入ってからreturnするまでに２回カーネルスタックが切り替わっていることだろう。スタックってのは関数が実行されてきた積み重ねそのものなので実行状態（プロセス）が切り替わっている。

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

ここは通常のC言語の考え方を捨てないとなかなか理解できない。JSRは所詮、最後はスタックから値を拾ってきてそこにJUMPしているという理解が必要になる。これがnewprocから1が返ったように見える理由。

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

swtchの中でもsavuをしているので、swtch関数を呼んで他のプロセスに切り替わっても、今度はまた自分が呼ばれたときのスタックはswtchを呼んだ関数の呼んだ場所の次となっているのでswtchを呼んでswtchから返ってきたように見える。とっつきにくいがわかりにくいとは思わない。

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

カーネルコードを読むときの最大の困難な点は「世の中に比べるものがない仕組み」なので比喩は使えなくて正確な概念を取得するしかない。比喩ではなにもわ買わないしそもそも比喩がむずかしい。今回からハンズオンを多めにしたので理解度も結構わかるようになってきました。

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

VBA進化ワイの体験（累計） ①書き始める　１００時間 ②直せる　３００時間 ③エクセルFWの仕組みがわかる　５００時間 ④いろいろ学ぶ　１０００時間 という感じでしょうか。もちろんこれにはアプリを作っている時間を含みます。習得は割と大変なんですよね。

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

たとえばVノックにしても１つに３時間とすると（あとの方はむずかしいですね）これだけで３００時間ですね。ちょっとやったらすぐにVBAができるなんて幻想ですね。それはVBAの文法がわかる程度でしょう。本当に重要なのはエクセルFWの理解と使いこなしかと。

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

全体的な体系図を書いたことがあるのですが ①エクセルオブジェクト概要 ②レンジの理解 ③組み込み関数 ④テーブル、ピボット、その他 ⑤制御構造と関数分割 それらの組み合わせと練習。とかですぐに１０００時間ぐらい言っちゃいますよね。そこからがスタートだと本当に思います。

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

ここまでやって、やっと転記ものがちょっと普通に作れる程度だとおもいます。それ以外に ①業務の理解 ②簿記、データベースの原則、その他原則の理解 ③アプリの作り方基本 ④初歩的なアルゴリズム ⑤エラー処理 ⑥進捗管理 みたいなのが山のようにあって常に男坂なんですよね。

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

ほんとにこんな感じなんですよね。１０００時間やってやっとスタート地点。って感じです。ワイは元本職なので多くのことは知っていましたが、それでも「のぼりはじめたばかり」だとずっと感じています。 pic.twitter.com/7ornjoiIcF

拡大

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

だからノンプロの方のコードのレベルが低いとあたりまなんです。気にする必要なんかないと思います。本職があるのですから。自分の業務改善に何千時間もきっちり勉強するのはやはり費用がかかりすぎでだと思います。その時のベストなコードがかければそれでよいかと。

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

本職は違いますかね。それが職業なので一定のレベルは求められると思います。保守性が低いコードは一定のレベルをみたしてないということですね。コメントについても同様です。関数説明のないコードは一定のレベルをみたしていません。

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

面白くて自分の実力以上のコードも以下のコードも書けません。端折れるのはコメント部分ぐらいだけでしょうか？「動けばいい」といのは「うごけばいい」レベルのコードしか書けないということです。ノンプロはそれでまったくOKですが、本職であればそれは問題があるということですね。

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

アプリの開発を含めて数千時間以下のノンプロがまともなコードを書けないのは「まったくの当たり前」のことなんです。そこを本職の人は勘違いしてはいけないとおもいます。本職はノンプロの人の１０倍の時間勉強してるのですから。その時時のベストのコードが有る。それでいいと思います。

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

ノンプロがピボットを多用している、コードが洗練されてない、余計な処理があっておそい、、、なんてのは全くの当然のことでそれをプロが批判してはいけないと覆います。ノンプロがノンプロをコードの質が低いといってするのはありかな？なんておもいますがｗ。

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

ソースコードレビューをすることは、コード力を効率よく、劇的にあげます。なのでノンプロの方ほどコードレビューをしてもらったり、リファレンスコードを精読するのがよいとおもいます。ただ、一人でリファレンスコードを精読しても「意味、意図」わからないのでわかっている人と一緒にレビューする

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

のがよいとおもいます。当ほえDX塾でもVノック１００のレビューなどというまったくの他人の褌作戦も考えております。リファレンスコードをみながら「なぜそう書くのか？」を解説していくシリーズです。自分で回答を作ることは楽しく、かつ、重要ですが

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

そこまでしなくても、問題をみて、暫く考えた後にリファレンスコードを「コードリーディング」すればよいのです。むしろ書かないで頭の中でコードを動かす訓練になってよいかと思います。書かずに頭で動かしてみてちゃんとうごくのか検証するんです。

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

V１００を自分でやることはすばらしいですが、講師１人が１０人に対して「コードレビュー」を実施すればそれはとても効率の良いものになります。ある程度なれてくれば自分で解く必要は実はそれほどでもないと思います。「よいコードを精読する」ほど有効な手段はなかなかないですよね。

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

どうしてよいかというと、理由があります。人間の特性として「学習」はとても得意で効率がいいんです。ですから「書けないレベルのコード」でも「精読してその手法を取得すること」はできます。コードの精読は人間の特性にマッチしてるのでとても効率がいいんですよね。工夫するのはその後で十分かと。

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

簡単にいえば、多くの人にとっては、Vノックは「精読する」「コードレビューしてもらう」ためにあるんです。最初は作るんではなくて書き方、考え方を「ぱくる」んです。パクって後、工夫すればよいのです。できなかったらドンドン答えをみればいいと思います。

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

ただし、コピペして動かしてもなんのいみもありません。動かしてはじめてわかる。というのは否定しませんが、動かしてわかるということは理解していないといことになります。動かすのは頭の中でうごかすんです。図とか書きながら。ほえDX塾での精読がたのしみです。