根本原因を直す

不具合は、症状が出た場所でなく、原因の場所で直す。症状は誤った状態が見えた場所で、根本原因は系が最初にしてはいけないことをした場所、または扱うべき状態を扱えなかった場所。

なぜ: 症状の手当ては証拠を隠し、欠陥を別の場所に出させる。名前の無い不具合への回避策がコードに残り、系を追いにくくする。

適用する場面:

• 試験や CI が落ち、落ちた行の近くで直そうとしたとき。
• None の確認・再試行・例外の握りつぶし・値の切り詰めを足して通そうとしたとき。
• 再起動の後にだけ起きる失敗を見たとき。
• 審査やレビューの指摘を直すとき（指摘の文は、見つけた 1 か所の形で書かれる）。

やること:

• まず再現する。各段で「なぜ」を問い、答えが前の段の結果でなく、コードの誤った判断になるまで遡る。推測せず、実際のエラーと実際の状態を出して読む。
• 症状を起こした状態が正当かを問う。正当なら、それで壊れたコードが原因で、そこで扱うのが修正。ありえない状態なら、壊れた場所の確認は不具合を隠すだけなので、状態を作った場所を探す。再起動の後だけ落ちるなら、残った状態（設定・キャッシュ・ロック・保存した状態）を先に疑う。
• 1 件でなく型を探し、同じ欠陥を持つ場所をすべて直す。指摘を直すときは、直す前に根の性質を 1 文で書き（例: 「fixture を準備した結果が、意図した状態になったかを確かめない」）、道具や書き方が違っても同じ性質の箇所を grep などで探す。回避策に段落ほどの注釈が要るなら、直すべきはコード。決め手の事実を深く掘って見つけたなら、最初に見れば分かる安い手がかり（ログの 1 行、状態の表示）を常に出す案を出す。

使わないとき: 原因がこちらで直せない外部（他社の API、ホストの不具合）にある場合。回避策を置き、原因と外す条件を同じ場所に書く。

確かめる例: 修正の説明に、症状・根本原因・その状態が正当かの判断がある。同じ欠陥のほかの箇所も、同じ差分で直っている。