Drupal 開発ディレクター兼エンジニアが仕事、育児、本など雑多に書くブログ

他者が書いたコードが理解できない時に聞くか読み解くかの判断基準

「他者が書いたコードを読んで理解できない時に聞くか自分で読み解くかの判断基準」が書かれていたのでシェア。

処理なら頑張る / 意図なら聞く

分からない部分が処理についてなら、自分で読み込むべき。分からないメソッドはググり、呼び出される関数を追い、理解に努めるべき。

対して処理は理解できるが意図が理解できない時は、素直に聞くべき。 意図を深く考えて推測してもそんなに意味がない。どちらかというとエンジニアリング力よりは単に要件が頭に入っているか等の背景に問題があることが多い。

意見・補足

ここからは私の意見や補足。

沼にハマりそうだったら頼ろう

もちろん処理であっても、沼にハマって全体の工程に影響を及ぼすなら相談すれば良い派。 基本的には働いた時間に対して報酬が発生し続けている訳なので、無限に頑張っていただくとそれはそれで困るという別の問題もある。すいません。

エンジニアとしてというか、仕事に対するスタンスとして、自分でやり遂げたいということ自体は悪いことではないんですけどね。

基準を決めておけば仕事が速くなる

スタンスを

  • 処理の部分は頑張って読み解きます
  • 意図の部分は分からなかったら素直に聞きます

と決めておけば病むことも減るし、判断が速くなる。 判断が速くなると、仕事はどんどん速くなる。

深い沼にハマり続けるよりは、浅い沼に何回も潜って時間の密度を上げることによりフォーカスすべきかなと。

自分の責務は何か

ちょっと脱線しますが、良いエンジニアは処理は自分でしっかり練るけど、そもそもの要件が分からなかったらソッコーで聞いてくる。

これはとてもありがたくて、自分の価値提供ポイントを理解しているとも言い換えられる。

基本的には割いた時間に対して報酬が支払われている。であれば割ける時間で最も自分が価値提供できるようにバランスを取るべきでしょう。

理解しようとするスタンスが大事

ここでこの本が言いたいのはスタンスの話である。 何をしているか分からないコードをそれこそコピペすることは、それこそアラビア語を写生しているのと何ら変わらない。

思考をくぐらないプロセスは、その場で上手く問題が解決されても、それ以上は何も生み出さない。

日々分からんことだらけですが、理解しようとするスタンスは常に持って、一歩ずつでも進んでいきたいですね。おっさんになっても。

そんな感じ。