日本CTO協会24卒Advent Calendar3日目です。3日目も日本CTO協会に所属していない私が書きます。もちろん他のメンバーも書くので安心してください。2日目のわたしの記事はこちら
はじめに
今日は私が業務で体感した、強いエンジニアの方はどのようにバグや実装方法を調査をしているのかについて書いていきます。
先月、エンジニア歴が7年近くある先輩とペアプロする機会がありました。実装したい機能について、どう実装するのか私も先輩も経験がなく、一緒に調べながら進めていこうという感じでした。
その中で得た私の学びが「調査が上手な人はコードを『物体』として認識している」というものです。
「コードを『物体』として認識している」とは
抽象的すぎる表現になってしまいましたが、私としてはこの表現が腑に落ちています。
どういうことかというと、ライブラリで提供されている関数やメソッドなどの機能に対して、「こういう機能を提供してくれるやつ」とぼんやりと認識するのではなく、「コードとして目に見える形(＝物体)でたしかに存在しているもの」と認識しているということです。
一見当たり前のように聞こえますが、この意識は非常に重要です。なぜならこの意識をもつことで、調査するときにレポジトリにコードを見に行くという行動が選択肢に入ってくるからです。
私のような新米エンジニアは、ライブラリをただの便利機能として認識してしまいがちです。そのため、エラーが出た時や提供されている機能を使って実装しようとしても上手くいかなかったときに、ライブラリそのものに原因がある、もしくはライブラリの中身のコードを見れば解決できるかもしれない、という可能性を知らず知らずのうちに排除してしまうのです(私だけかもしれませんが…)。
ライブラリがどのように実装されているのかをメソッド名から推測し、気になったメソッドは中で使われている変数名から処理の流れを把握する、ということを繰り返した結果、経験がない実装も完成させることができました。先輩のその調査のエレガントさにとても感動しました。恥ずかしくて直接は言えないですが。
以前、新人研修で調査のコツを今回ペアプロしていただいた先輩にお願いしたのですが、そのときに「うまくいかないときはコードに原因がある」とおっしゃっていました。このペアプロを通じて、「うまくいかないときはコードに原因がある」という1つの抽象化された考えに則って調査を進めることで、最初は手つかずだった問題も解決できるようになるということが私にとって衝撃でした。
この経験以来、何か詰まったときに自分のコードだけでなくライブラリのコードも意識的に読むようにしています。ときにはIssueを検索してみて、同じような問題が既に取り上げられていないかを調べるようにもなりました。もちろん先輩には遠く及びませんが、自分の調査の型が少しずつできているように感じています。
最後に
「うまくいかないときはコードに原因がある」。その認識を常に持ち、自分のコード・ライブラリのコード関係なくフラットに考えて突き詰めて調査することの重要性を今回学びました。この意識をもとに自分の調査方法の練度を高めていきたいです。