Why = なぜこのような処理（仕様）になっているのか？
Whyが残っていないと「なぜこの処理になっているのか？」がわからず変更しても良いものか迷う。 特別な仕様が残ってるのか？どうなのか？とか考えて調査していると半日持っていかれるとかよくある。
トリッキーな処理が必要なときはWhyをどこかに残しておいて欲しい。
コミットログにWhyを書きましょう、みたいな話はよく聞く。 コミットログだとファイルの削除（ファイル名変更）が入るとgit blameのめんどくささが跳ね上がる。
Pull Request（Review Requestでもいいけど）なプロジェクト運営であれば、Pull Requestのdescription（説明）やコードコメントにWhyを残しておいて欲しい。 VSCodeは優秀なのでGitLensのExtensionからPull Requestに直接ジャンプできる。
個人的には過去コミットを漁る工程は結構好きで、他人の思考やコードdiffから学べることが多いと思っているため。 コードリーディングは2019年に比べてかなり上達したと思っている。
最近は利用ライブラリの実装もGitHubからコードをcloneして読めるようになってきた。えらい！ でもプロダクト開発するときは調査量を少なくして、なるべく早くプロダクトを改善したい。
ので、過去の思考がすぐわかるようになってた方が良い。
