出てきたコードを、どこまで読むか

• 全部読もうとすると、続かない
• 影響の大きい箇所から読む
• 読まない箇所は、動かして確認する

出てきたコードを全部読もうとして、途中でやめた。優先順位をつけた話を書く。

全部読めなかった理由

最初は全部読んでいたが、続かなかった。

• 量が多いと、集中が切れる
• 切れた後は、読んだつもりになる
• 読んだつもりの箇所が、一番危ない

3つ目が問題だ。読んでいない箇所を把握しているほうが安全だと考えた。

必ず読む箇所

優先して読む箇所を決めた。

• データを消す処理
• データを書き換える処理
• 外部とやりとりする処理
• 条件分岐の条件部分

4つ目を入れたのは、条件を1つ間違えると、対象が大きく変わるからだ。

読まないと決めた箇所

逆に、動かして確認する箇所も決めた。

• 見た目を整える部分
• 表示の並び替えや整形
• 間違っていても、見れば分かる部分

3つ目が基準だ。目で確認できるなら、コードを読む必要は薄い。

読むときの見方

読み方も変えた。

• 上から順に読まない
• 危ない処理を探してから、その周辺を読む
• 変数が何を指しているか、確認する

3つ目が効く。処理の形は合っていても、対象が違うことがある。

分からない箇所の扱い

読んでも分からない部分が出てくる。

• 何をしているか、説明してもらう
• 説明が納得できなければ、別の書き方を頼む
• 分からないまま入れない

3つ目を守っている。分からないコードは、問題が起きたとき直せない。

量を減らす工夫

読む量そのものを減らす方法もある。

• 一度に頼む範囲を小さくする
• 1つの機能ずつ進める
• まとめて頼まない

1つ目が最も効いた。出てくる量が少なければ、全部読める。

動かして確認する方法

読まない箇所の確認手順も決めてある。

• 正常な入力で動くか
• 空の入力で落ちないか
• 想定外の入力でどうなるか

2つ目を忘れやすい。空の場合の処理が抜けていることが多い。

後から読む仕組み

その場で読まなかった箇所も、残しておく。

• 読んでいない箇所を、記録する
• 問題が起きたら、そこから見る
• 時間があるときに、読む

2つ目が実用的だ。未確認の箇所が分かっていると、原因を探しやすい。

読む習慣の効果

続けてみて、別の効果もあった。

• 自分で書ける範囲が広がった
• 何を頼めばよいか、分かるようになった
• 出てきたものの良し悪しが判断できるようになった

2つ目が大きい。読めるようになると、指示も具体的になる。

読まずに入れて失敗した例

実際に起きたことも書く。

• 一覧を取得する処理に、件数の上限が無かった
• 件数が少ないうちは問題が出ない
• 増えてから、表示が止まった

2つ目が厄介だ。入れた直後は動くので、問題が後で出る。

読む習慣をつけるまで

最初から読めたわけではない。

• 最初は、何を見ればよいか分からなかった
• 危ない処理の種類を覚えてから、見る箇所が決まった
• いまは、該当する箇所を探す形で読んでいる

2つ目が転機だった。読む対象が決まると、量が減って続く。

確認を頼む形

自分で読むほかに、確認を頼むこともある。

• 危ない処理が含まれていないか、挙げてもらう
• 想定外の入力でどうなるか、説明してもらう
• 説明を読んでから、該当箇所を自分で見る

3つ目を必ずやる。説明だけで判断すると、確認したことにならない。

読む時間の確保

読む時間も、作業の中に組み込んでいる。

• 書かせる時間と、読む時間を分けて見積もる
• 読む時間を省くと、後で直す時間が増える
• 急いでいるときほど、読む箇所を絞る

3つ目が現実的だ。読まないのではなく、読む範囲を狭める。

まとめ

• 全部読もうとすると続かない。優先順位をつける
• 消す・書き換える・外部とやりとりする処理は必ず読む
• 目で確認できる部分は、動かして確認する
• 一度に頼む範囲を小さくすれば、読む量も減る
• 読んでいない箇所を記録しておくと、原因を探しやすい