「ピンチはチャンスだ」なーんて言えるやつはただのアホだと思うくらいには常識人のつもりですが、入社以来、表題のような状況を多少なりとも生き抜いてきている自負があります（自負じゃない）。
有識者の居ないソースコードをどうやって修正してレビューしてテストして出荷しようかという話。もし誰も有識者が居ないソースコードを自分が修正しなければならなくなったらどうしようかを想起した、主に私の古き実体験談を思い起こしたようなそうでもないようなフィクションです。
そして誰もいなくなった
皆様は経験したことがあるでしょうか。気づいたら自分が古のソースコードの担当となっていたことを。人はいろいろな理由で去ります。入社して7年目くらい、まあまあ中堅扱いされる時期を迎えた頃、ふと気づいたら目の前には誰の背中もありませんでした。まあなんでしょう、先輩たち皆めでたくご卒業してたってやつッス。
残されたソースコードと私。
エッ、私C++読めない…
とか言ってられません。
有識者が居なければ、誰かが有識者になるしかない。まずここから語らないといけない状況を素直にイタイと思いましょう。でもそこは自らのマインドセット。自分が自分というスタートアップのオーナーたるしかないのです。例えば初めて使うOSSライブラリも、ややもすれば自分で読み解かなければ使えないですね？それがたまたまOSSではなく社内にただ閉じこもったソースコードだっただけです！せめて前向きに気持ちを切り替えて覚悟を決めます。
まずソースコードレビューに強くなろう
本題です。ソースを読みましょう。
コードレビュー時に引用するページのまとめ がわかりやすいです。以下★の多いもの抜粋。
悪いソースコードを知るには、良いソースコードを知らないといけません。いいまじないに力を与えるには、悪い言葉も知らなければいけないって、でも決して使うなってやつです。
好奇心ドリブン
1つだけラッキーなことがあります。なんと今ならどんなにしくじっても怒られることは無いのです。むしろ、捨てられて可愛そうに 残された者として責任感を育んで頑張っているね！ と、思ってもらえるしかあり得ない美味しいチャンスです。社内の空気だけは味方につけて、せめて興味を持ってデバッグから始めてみます。そんなときもお客様トラブルは待ってくれないよね。わかります。でもとりあえず報告されたトラブルの社内再現が第一歩。
叩かれ台レビュー
どうにかエラーを再現、涙ながら仮修正。胸を張って修正出来ているはずはありえないので、まずは「叩かれ台としてこうしてみました！」と私の場合大体言っていました。そしてレビュアーも、レビュイーも、初心者だからレビューできないとか、言っても始まらない。
レビュアーが常に上から目線である必要もないです。チーム力を育むときです。わからないことを聞く、わかるまで聞く。意外と修正者たるレビュイーも何もわかっていなかったことがわかればそれで良し。十分皆で、理解がすすみます。
テスト
肝です。今こそ過去のテストケースを読むとき。多分ですが、「そして誰もいなくなった」状況下でテストケースがきれいに書かれていることは稀でしょう。気づきましたかだからいなくなったんです。 いえ、自分が書くしかありません。でも前述の通りどうしたら初心者が、神のようなプログラムに対してテストを書けるというの？
- レガシーコード改善ガイド および 駆け足ガイド
- リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES) と リファクタリング 2nd Edition
- レガシープロジェクトを引き継いだ時、最初にするべき７つのこと
ここでも本です。読書です。分野には精通していなくてもチーム外に「ソースコードそのものに強い人」というのは必ず居ますね。社内だけでなくもしかしたら社外ですら、勉強会などと称してそういう方々と仲良くなっていれば実は「誰もいなくなった」なんて状況は杞憂だとわかります。驚いたことにこの業界は狭いです。僕らはひとりじゃない。
結論：意外とどうにかなる
冒頭に書きました。自らのマインドセット。
有識者が居なければ、誰かが有識者になるしかない。
でも「ピンチはチャンスだ」なんて言えるやつはただのアホだ。
いずれも然りです。しかし上に書いた一連のソースコードリーディング、レビュー、テスト。いずれも、そこにしか答えはありません何故ならプログラムだから。一つ一つ勉強するための大きなチャンスをもらったつもりで向き合っていると、いつの間にか自分が「有識者」と呼ばれる一人になっていると思うからそんな深刻になるなよと。なんだこの前向き過ぎる良い話は！
以上です。