新しい仕事やプロジェクトを始める時に、コードベースを一から作ることはめったにありませんよね。なじみのないコードと格闘するのは骨が折れますし、新たに取り込む情報の多さを考えると、気の遠くなる思いがします。Rubyを使っていた環境からNestoriaに移った私の場合は、新しいコードベースの学習に加えて、Perlまで勉強しなくてはならなかったため、二重の苦しみを味わいました。そんな私が、できるだけ短期間で生産性を上げるために使った7つの方法を紹介します。

謙虚になろう

プログラミングと聞いて、真っ先に”謙虚さ”を思い浮かべる人はいないかもしれません。何しろ”傲慢”が プログラマの三大美徳 の1つに数えられているくらいですからね。そうは言っても、なじみのないレガシーコードに出くわしたら、あまりにも分からないことが多すぎて、何度もミスをしてしまう自分にきっと嫌気がさすでしょう。このような場合は、謙虚な姿勢でその事実を受け止め、どっぷりとはまってみる必要があります。コードが理解できないのは、そのコードの書き方が下手で分かりにくいせいかもしれませんが、自分がその分野に不慣れなことや、元々のアルゴリズムが複雑であることが原因かもしれないのです。それにもかかわらず、最初からコードの欠陥のせいと決めつけてしまうと、多くの時間を無駄にするだけでなく、同僚にも迷惑をかけてしまうでしょう。そんな時こそ、このコードを最初に作った人にはそれなりの意図があったはずだと思いを巡らす謙虚さを持ち、自分が本当に理解できるまでは、批判的になりすぎたり、大幅な変更を加えたりするのはやめましょう。

まず、テストしよう

コードベースがユニットテストと統合テストで完全に検証されている場合は、この方法は必要ないでしょう。しかし大抵の場合、コードには、より良いテストカバレッジ、もしくはより信頼性の高いテストを適用できるエリアがあるものです。テストの追加や改善をすれば、本番用コードを損なうリスクなしに、コードベースの信頼性を高められます。テストを書いたり再度書き直したりすることで、コードを読んでいるだけでは分からないことに気づき、理解を深められます。次に取り組むことが何であれ、まずテストを読むことにある程度の時間を割き、テスト不足だと思ったところに対して新たなテストを加えてみましょう。退屈な作業かもしれませんが、いざ本番用コードを書き始める時に大いに役立ちます。なお、Katrina Owenによる 癒やしのリファクタリング でも、同様のアプローチで不慣れなコードに取り組む方法を紹介しています。

何か書いてみよう

とにかくできる限り早い段階で、コードを書いてみましょう。実際にコードを書くことは、コードに慣れる一番の早道です。小さなプロジェクトから手がけるといいでしょう。完成するまでにかかる時間はあまり気にせず、学びながら目の前のプロジェクトを完成させることに集中してみてください。

質問しよう

自分の力で全て解決しようとして悪戦苦闘するのもいいですが、他の人に質問することで問題が素早く解決するものです。まず少しだけ自分で調べてみましょう。その上でつまらない質問をすることは、不必要に悪戦苦闘するよりもずっとマシです。チームメンバーとしては、質問を寛容に受けそれにすぐに応じることで、手助けができます。たとえそれが取るに足らない質問だったり、どう答えてよいか分からない質問であったりしても、チームメンバーから励ますような反応が返ってくれば、新たなメンバーはどんどん質問をしやすくなりますね。チームメンバーとしては作業を中断されてイライラするかもしれませんが、新たなメンバーの理解が進むことは、長い目で見ればチーム全体の利益になるのです。チーム内にRTFM（マニュアルを読め）という雰囲気があるとしたら、新たなメンバーはちょっと質問すれば何時間も悩まずに済む可能性があるにもかかわらず、質問できずに独りで悪戦苦闘することになってしまうでしょう。

ペアを組もう

質問することよりもお勧めしたいのは、コードをよく理解している人とペアを組むことです。すぐにフィードバックを受けられますし、単にコードを読むだけでは習得が難しい多くの決まり事を身につけることができます。これを効果的に進めるにはチームメンバーにも訓練が必要です。経験豊かなチームメンバーは、新たなメンバーの仕事を代わりにやってしまうことのないように気をつけなくてはなりません。この方法は特に全く知らない分野において有用です。例えば、私はLinuxのシステム管理についてあまり知りませんでした。そこで、Linuxの知識が必要となるような作業を行う時には、他のチームメンバーに作業が完了するまで同席してもらいました。また、コードレビューを行っても有益なフィードバックを得られます。

ドキュメントを書こう

コードについていくらかの経験を積み、必要性を感じるようになったら、ドキュメントを書き始めましょう。最初は自分だけのために書きます。それは個人的なwikiページやただのテキストファイルの形でも構いません。またStack Overflowで質問や回答を投稿するなど他の形でドキュメントを書き、それを自分用のドキュメントにフィードバックするのも役に立ちます。そして自分のドキュメントは正確で他の人にとっても有用なはずだと感じるようになったら、それをコードや公式なドキュメントに反映していきましょう。

全体像を見よう

最初は、システムのアーキテクチャについて全体像を知ることが有益です。これから取り組むシステムのアーキテクチャについて、誰かに図解をしてもらい、それから自分自身でコード内の各モジュールを図の中にマッピングしてみましょう。

数ヶ月後には新しいコードベースにすっかりなじんだと感じ始めることでしょう。コードベースの一部に触れたに過ぎないとしても、チームの慣習や一番重要なポイントがどこなのか、理解できているはずです。そうなったら改めて全体を見て、初めに説明されたアーキテクチャが理にかなっているか考えてみてください。あなたなら他にどのようなアーキテクチャを作ることができたでしょう？　現在のアーキテクチャを改善するために、これまでの経験をどのように活かすことができるでしょう？　あなたが経験したコードの動きは、初めに説明されたアーキテクチャ通りになっているでしょうか？　あなたならどのような説明の仕方をするでしょう？

他にもコードベースを理解する助けになるような方法はたくさんあるだろうと思いますが、ここに挙げたものが私にとって最も役に立った方法です。コメント欄で、あなたの方法を私たちに教えてください。