忙しい人のためのまとめ

詰まった時にメモを取れば、進捗も思考も可視化できるのでおすすめです！みんな詰まった時はメモを取ろう！

こんなことってありませんか？

むかしのきもちがわからない

僕はインターン先でフロントエンドのアーキテクチャを設計したり、そのアーキテクチャを実装するために必要不可欠なライブラリを作っています。
ところが、今作っているプロダクトならともかく、何個か前の成果物となると、「あれ、どうしてこんな設計にしたんだっけ」みたいになっちゃうんですよね。
コメントやPRに書いとけよってツッコミが入りそうなのですが、読むのに必要な込み入った実装テクニックや実装内容はと違って、実装の背景の設計や思想は記憶の海に流されてしまいがちでした。

なぞのばしょでまいごになった

難しい実装をしている時や、難しいコードを読んでいる時（ライブラリを読んでいる時）って、他の誰も分からない。自分も分からない。なんてことありませんか？
いや、もちろんこういう時って他の人と議論できればそれに越したことはないのですが、「いや、他のタスクで忙しいし...」みたいなことにどうしてもなっちゃうと思います。それに、議論するにしたって議論の材料は必要ですね。「要は君は何がしたいの？」と聞き返されて言葉に詰まるのがオチです。

そんな時は、メモを取ろう！

メモを取ると何が嬉しいか

書いたことを眺めながら他のことを考えられる

「自分が考えていることを眺めて批判しやすい」というのは非常に強いメリットです。

最初の例として、（手前味噌になってしまいますが...）きたるべきvue-nextのコアを理解するを書くためにコードを読んでいた時のメモを一部載せてみます。コードを一通り読み、自分なりに違和感を覚えたところを言葉にしている部分です。

## 疑問点

処理中の effect は単にスタックに積んで、処理が終わったら pop される。
そうすることで、「getter を叩いたときに実行する関数を取得する」みたいな動作が可能になる。
いま実行している effect はスタックの一番上にいるからだ。
(※1)

だけど、これが非同期処理とかで effect 関数が同時に 2 つ走ったりしたらどうなるんだろう。
混乱しないのかな。
「A→B の順番に非同期な effect 関数を同期的に発動して、B 実行中に A から getter を叩く」と参照がずれそう。
A から叩かれた getter なのに、「B から叩かれました」と誤認する気がする
(※2)

もう一つ

「effect を経由しないと副作用は伝播しない?」
テストコードは effect を使用したもののみだったけど、effect がない文脈で、
リアクティブな値 ra,rb があったとして
ra = rb
みたいなことしたときに、rb を変更したら ra も追従するのだろうか?
するとしたら、それはどのような機構なのか?

(※1)では、その時の自分の理解を書いています。(※1)を書く前では、「なんとなくeffectという関数周りが怪しいな」と思っていたくらいの思考でしたが、現状をとにかく言葉にしてみることによって、(※2)の疑問点をちゃんと表現するのが簡単になりました。

一旦考えを言葉にしていつでも見れるようにしておけば、別のことを考える余力が発生するので、「書くことによって考える」といったことが可能になります。

「お気持ち」を残せる

今度はVue.jsのcomposition-api関連のプログラムを書いていて詰まった時のメモです。

# setup 内の render

https://github.com/vuejs/composition-api/issues/84

でもそうだし、setup の型定義もそうだし、なんなら jsx ではうまく行ってるんだけど、
ts モードでやるとうまくいかなくて死んでしまう。謎だが、まあ書けなくはないしいいか。

んん、でも tsx モードでもコンテクストは読めてないぞ。
render function しか読めてない。

謎を解明するために、
公式が書いているサンプルをちょっと改造してコンテクストがどうなってるかを調べてみる。

んんんん。なんということでしょう。
こっちでもうまく行っていないらしい。

いろいろ試行錯誤したところ、以下のようになった

- ctx.slots はいつでも確かにいるし、ちゃんと関数になってる
- けど、render function 内で呼び出さないと死ぬ

なるほど？？？

どうやら、ctx.slots 内の関数は render の実行時コンテクストをどっかで参照しているらしく、
render function の外で呼び出すとそれが狂うらしい。しるかよそんなん。

いろいろ試行錯誤をしていて詰まった時のメモです。
試行錯誤を残すのも大事ですが、ここでは最後の「しるかよそんなん」というのを書いています。

メモをとり、プログラムを書いている時の「お気持ち」は一見無駄な情報に見えます。

しかし、「お気持ち」には、「なんだか使いづらいなあ...」だったり「これは自明だけど一応試してみました」といったメタな情報が意外とつまっているのではないかと思います。

例えばライブラリを使っていて「使いづらいなあ...」と思ったところは改善点になる可能性がありますし、「しるかよそんなん」は非自明な点があるということなので、どこが非自明なのかを洗い出すとっかかりになります。

「詰まった時の進捗」を可視化できる

上の両者について言えることですが、「詰まった時」に「詰まり」が解消するまでの過程が書かれています。

詰まった時は、往々にして「進捗がずっとフラットで、解消された途端に一気に進捗が生えたように見える」ので詰まったと形容されがちです。

ですが、詰まった時にメモをとることで、「いつもなら詰まっている時」でも、少しづつ進捗が見えるようになっていきます！

どんな風にメモを取ればいいの？

まず、いつでもメモを取れるようにする

僕はとりあえずメモ用のテキストファイルを作り、そのテキストファイルを開いたエディタを常に待機させています。
また、メモの心理的ハードルを爆下げするテクニック -外部記憶装置としてのScrapbox (+ Alfred + chrome拡張)-のようなテクニックもおすすめです！

喋るように書く・無理をしない

書き始めたら、形式とかを気にせずに書いてみてください。
僕は喋るように書いていますが、大変なうちは単語の羅列でも自分の役に立つと思います。

それと、メモをとるとスピードが下がるのは確かにあるので、普段うまく行っている時は無理して取らなくてもいいと思います。

詰まった時を自覚できるようにする

一番難しいのがここだと思います。
僕は30分に1回目をつぶったり、何かしら特殊な行動をして、その時に自分の今やっているものが進んでなかったら「詰まった」とみなしています。

詰まった時こそメモを取ろう！