鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

実装の経緯は記憶していません

記憶してるんじゃなくて記録{して,させて}いますという話。

同僚との会話から

チームでメンテナンスしているプロダクトの実装について質問を受けたときに、私がささっと調べて答えているのを見た同僚から「長いこと関わってるからあちこち触っていて、実装の経緯とか知ってるから答えられるんですね」と言われて、記憶でとっかかりが得られることもあるけど、最近はほぼ記憶に頼らずにやっていたのでそう言われて驚いた。

記憶をたどる

記憶に辿らなくて良くなった経緯を思い出してみた。

今の会社に入った当初、既に書かれたコードのメンテナンスをするにあたり、もちろん記憶に頼ってとかはできないし、コミット履歴を見ても有益な情報が得られなかったので、周りの人に聞きつつ頑張ってコード読んでたように思う。コード量も今のコードと比べると少なかったし、要求されるスピードも今と比べるとそれほどでもなかったのでなんとかなったところはあると思う。

人の記憶に頼って何とかしようというのは、設計、実装した人が離職されたら途切れてしまうし、人がどんどん増えたときにそれをすべて伝承し続けるのは筋が悪い。自分のそれまでの経験でも、問いの宛先となる設計、実装した人が過去の自分で、記憶に頼るというのはあてにならないというのを自ら痛感することも度々あった。

そういうわけで、JIRAのチケットに途中の検討内容のメモを書いときましょうとか、関係する情報をリンクしましょうとか、git のコミットメッセージちゃんと書きましょうとか、情報を記録することと、それらをリンクしていくことは大事だよと周りにもおすすめしつつやってきた。そういった活動を始めた時点から増えてきた分のコードには、付随してある程度の情報が保持される状態になっているのが今。

記録の辿り方

使える情報が存在していても、辿れないとそれは存在しないのと同じ。冒頭で出てきた同僚は辿り方を知らないのかもしれないなと思って、先日チーム向けに git blame の使い方のデモをした。

blame したときにできるとよいこととして、

  • 特定行からコミットメッセージに飛ぶこと
  • ひとつ前のコードでblameし直す

がある。前者はコミットメッセージに残された情報や、コミットメッセージ中のチケット番号からJIRAへと辿り着くのに使える。後者は、フォーマットの変更などの意味のないコミットがあったときに、本質的な変更のコミットを探すのに使える。

ある時点のコードを空間方向に眺めて得られる情報の他に、git blame や git log で時間方向に視点を動かして得られる情報を加えることで、よりコードの理解が容易になる。

手でgitコマンドを叩きまくってもできるけど、ツール使うと楽ができる。デモに使った magit-blame ではこれらはキー一つでできる。Emacs使ってるの私だけなのでそのままでは聞いてる人の役に立たないので、tig blame とか vimagit にも軽く触れておいた。

magit.vc

jonas.github.io

github.com

記憶するのではなく、記録する

記憶に辿らないコードの読み方を共有したので、将来の自分たちや仲間たちのためにさらに有用な記録を残していけると良いな。