ポートフォリオの2作目を、工程ごとに自分用の手順書を先に書いてから着手する形で進めています。
手順書には「ここで詰まりそう」という罠を、分かる範囲で先に書いています。
今日、その罠の1つを踏まずに通過しました。
エラーが1件も出ませんでした
新しく入れたライブラリで、公式ドキュメントの書き方が1つ前のバージョンのものでした。
そのまま写すとエラーになります。
手順書には、新旧の書き方の対応表が5行だけ書いてありました。
作業に入る前にその5行を読んでいたので、エラーは1件も出ませんでした。
運が良かったのではなく、順番の問題でした
公式ドキュメントを見に行く前に、手順書を見た。 それだけです。
逆だったら、公式の書き方をそのまま写して、エラーを見て、
「なぜ公式のとおりに書いて動かないのか」を調べる時間が発生していたはずです。
内容は同じでも、読む順番で結果が変わりました。
同じ記録の使い道が2つありました
これまで、詰まった記録は「あとで同じところに来たときに理解するため」に残していました。
今日わかったのは、もう1つの使い道のほうです。
- 踏んだあとに理解するため（これまで）
- 踏む前に避けるため（今日効いたのはこっち）
同じ記録が、置く場所を変えるだけで役割が変わりました。
振り返り用のログに置けば前者になり、着手前に読む手順書に置けば後者になります。
ただし、避けると実感が残りません
困ったのはここでした。踏まずに済むと「学んだ感じ」がほとんど残りません。
エラーを見て調べて直した記憶は残りますが、「先に読んだので何も起きなかった」は記憶にも記録にも残りませんでした。
なので対応表そのものを開発ログに書き写しておくことにして、踏まなかった罠も記録としては残すようにしました。
おわりに
罠を書くのは時間がかかるので、書いた罠を踏まないと「あれは無駄だったのでは」と思いそうになりました。
でも今日の結果は、書いたから何も起きなかったが正しいです。
何も起きなかったことは記録に残らないので、意識して残しにいく必要がありました。
効いた準備ほど、あとから見えなくなります。
