ソースを読む。これは開発者としては当たり前のことです。
自分がコーディングしたソースを読んでチェックすることも当然ですが、
他の開発者がどのようなコーディングをしているのか研究をしたり、
新しい言語を学ぶときなどはサンプルソースを読むのが一番の早道であったりします。
＃さらに昔のことを言えば、コンパイルに時間がかかるので、机上デバッグでコンパイルエラーゼロを目指すというのもありましたね。

今回、この品質向上という意味でのソースを読むとは、以下の２つをあらわしています。

・本人が自分のソースをチェックすること
・他者が人のソースをチェックすること

開発会社なら当たり前のことかもしれませんが、
特にVBAが全盛だったころ、新人のソースは必ず印刷して先輩社員がチェックするということを行っていました。
現在ほどカプセル化などが進んでおらず、1本のプログラムはそのソースを印刷すれば
凡そすべてが記述されているという状態にあったのである程度1,2年先輩であれば誰でもチェックができていました。

さて現在ですが、上記の言い方をすれば、カプセル化が進んでしまっていて
その仕様を理解していなければソースが読めない、もしくはそのカプセル化された先のソースも読まなければならないので
ソースがあちこちに飛んで読みにくいということになります。
仕様を理解していなければならないという点は確かに必要です。
ですが、一度読んで理解してしまえば、後はずっと同じかつ既に正しいことが保証されているのですから何度も読む必要はなくなります。

フレームワークが正しく整備されていて、カプセル化された内容が保証されていれば読むポイントはある程度絞ることができます。

・発行するSQL文は仕様通りであるか、結合キーに誤りはないか
・決められた手順通りの記述ができているか、規約を守っているか
・変数などデータ型で不整合を起こしていないか（→これはVS.NETであればOption Strict Onにすることで対応も可能ですね）
・画面やテーブルの転送項目で必要な項目の漏れはないか

特にSQL文などは、動作テストだけではテストデータの作成方法によりたまたまうまくいくということもあります。
それこそ「ソースを読む」ことで潜在バグをなくしていくようにしたいものです。