推測を求められたら推測だけでなくその根拠も伝えるということ

レビュワーからアドバイスをもらう時にときどき言われて後から気づくことがあるので依頼前のチェックリストの備忘録として残します。

結論(今回学んだこと、今後のチェックリスト)

自分なりの推測を求められたら引用できる内容（ネット記事やコードなど）を添えて根拠を伝える
思い込みによる推論をしない <- 思い込みによる推論が正しいか(根拠があっているか)ネットで調べる
質問する必要が出てきた時にissueを再確認する(質問する内容とissueの内容が完全に合致しているか確認する)

自分なりの推測を求められたら引用できる内容（ネット記事やコードなど）を添えて根拠を伝える

分からない時はプログラミングの正しい質問方法をプロが体系的に解説 | 侍エンジニアブログの`3つの質問テンプレート`を参考にしてつくるのが良さそう。

今回は`「どこが原因だと思いますか？」`とレビュワーに質問されました。

レビュワーの意図は `確認すべきファイル、処理は妥当なところか？`ということが知りたかったのだと思います。
今回は見るべき部分を見ていたので問題はなく良かったです。
以前は自分の乏しい経験則や勘で`ここらへんだと思う`というざっくりとした返答しかできなかった時期があり、その

思い込みによる推論をしない <- 思い込みによる推論が正しいか(根拠があっているか)ネットで調べる

今回は自分の思い込みが原因で修正すべき箇所を見つけることができませんでした。
複数レコードを取得してくる際はレコードのidを基準に整理されて格納されると思っていました。
通常複数レコードを取得して表示する場合はorderを指定する必要があるのですが、それを失念していました。
mysql - ORDER BY を指定しない時／ SELECT結果表示並び順の法則性 - スタック・オーバーフロー

なかなか自分で気づくのは難しいですが、本当にダメな場合は自分の考えている前提が正しいのか確認したほうが良いと感じました。

雑感

少しずつコードを読むことはできるようになってきている気はするが、

コードをすぐ理解できrこと
原因箇所を特定すること
特定して修正すること

の能力が着実に上がって欲しいな...とおもいましたw

P.S.
そもそも論としてissueを誤解釈していたことが始まりだったように思います。
issueをしっかりと確認すれば解決できる内容だったかもしれません...