- バグ修正のときはエラーとしてあがってきたユースケース以外に、それに関連したユースケースにもバグがないかどうかチェック
- ロジックを自分の口で説明するときは、自信を持つ
不思議なものでこの二つ、僕が自分に向けて書いたセルフレビューでも実は全く同様のことを挙げていました。すなわち、自分から見た己の改善点と他人から見た僕の改善点は一致しているということ。己の視点と他者の視点が一致することは分からないこともなく、というのも「ここをこうするともっとよくなる」とか「この誤りはもう二度と起こさないようにしよう」とかチーム内では普段から直接相手に言うようにしているので、レビューが書かれる頃には自分は何を改善すればいいのかおのずと分かっているという寸法です。レビューで指摘されている己の改善点を読む際にも少なくとも一度は直接言われていることなのでキモを冷やさずに済むと。
上記の二点は言うは易しのようなところもありますが、一点目は2013年になってからは改善できていると自分でも感じます。特定のエリアに限ってユースケースとコードベースのマッピングが頭の中で出来てきたおかげです。逆に初見のコードベースでは、まだまだというところか。しかしそのような状況でもやれる人はやるんですよ。そういう人は、1) 過去の経験からくる類推がわりと効くのと、2) その未知のエリアに明るい人物を探す能力に長けているのと、3) 疑問解決のためにその人物に投げかける質問の内容が実にポイントを得ている。僕はまだ三つのうちどれも未完成で、未知のエリアではしばらく試行錯誤を繰り返す日々が続く。
二点目もまだまだ改善が必要なわけで。自分のロジックを自信を持って説明している人は論拠となっている土台にブラックボックスがほとんど存在していない。もしくはそのブラックボックスを使う上での前提をよく把握している。すなわちその前提から外れた状況下でブラックボックスを使用して己の論理を組み立てていくと、導き出された結果が undefined behavior になることを良く理解している。僕の改善すべき箇所は、まだ年配のエンジニアの説明を鵜呑みにしている部分が多いということ。論拠となる部分で「Aさんからこういう説明を受けたので自分としてはこういう理解のもとに話を進めます」では、説得力に欠けるんですわ。しかし大規模ソフトウェアでは、assumption の上に assumption が重なっていくのでどこかで線引きをしないと、ブラックボックスの中を覗いているだけで一週間が終わってしまう。時間との戦いなのでどこかで探求を打ち切り前進しないといけないのだけれど、そのあきらめ方を工夫しないと説得力のある説明はできないというのが現状。これも日々試行錯誤しないといけないよな。
にしてもレビューで、自分の改善点を指摘するために具体例として挙げる過去のエピソードをどうしてこんなに克明に覚えているのっていうくらい、年配のエンジニアは僕との作業を良く覚えてる。こういうところでもシニアの人はさすがだと思わされるわけです。
