【本感想】世界一流エンジニアの思考法

牛尾剛さん著「世界一流エンジニアの思考法」を読みました！
のでその感想を書こうと思います。

読んだきっかけとしては、僕もエンジニアの端くれとして働いているので単純に参考にしたいと思ったからです。（そのまま( ・∇・)

本書は「世界一流のエンジニアの思考法」というタイトルではありますが、マイクロソフトで働く著者が一流エンジニアと一緒に働く上で学んだことを綴られている形になっています。
なので、一流でない私たちと同じ目線で書かれていて非常に飲み込みやすい内容でするすると内容が頭に入ってきます。

その中で特に私に響いた箇所について感想を書いてみました。

クイックコールのすすめ

クイックコールとは、予定されていないビデオ通話のこと。必要なときにTeamsとかのチャットで、先方から「今クイックコールしていい？」（Can I have a quick call?）と言われるので、良ければ「いいよ！」（Sure!）と送り返す。

このクイックコールは自分も日頃リモートワークをしていて効果を実感する部分です。

リモートワークをしているときは、基本的にメッセージ上のやり取りがメインだと思うんですが、それだけだとメイントピックの外にある話が放置されてしまうことが多い。

例えば自分がアサインされたタスクについて起票者に聞きたい場合に、質問したいメイントピックとしては「追加する昨日の具体的な挙動」についてだったとする。
で、それがメッセージ上でやり取りしてそれ自体は解決したときに、「で、なにを持って挙動が必要になったんだろう、、」と思ったとしても、追加で質問するのはちょっと気まずい。

一方、声を通して話している場合は「ちなみにそれはどのユースケースで使われるのでしょうか」とか簡単に聞きやすい。と思う。

なので僕は、質問したい内容が明確に一つの事柄に絞られているときはメッセージ上で簡単に質問し、疑問に思っている内容が明確になっておらずふわふわした状態のときは（slackだと）ハドルをしてコミュニケーションをするようにしています。

また、これが一番重要だなって思ったんですが、クイックコールをすることよりも、「ちょっとハドルしていいですか」て気軽に言えるような関係性を築けていることが重要だと思う。

コードを読みものとして扱う

コードもまた読み物だ。
コードを書きながら「この部分はわかりやすいかな？」というのを最優先にすると、コメントが激減するのがわかった。

ここすごいいいなって思ったし、私も日頃下記のようなことを意識してPullRequest作ってます。

レビュワー目線で
- FilesChangedが極端に多くなっていないか
- 追加しているロジックが多くないか、（できるだけ1PRに1ロジックに収める）
- PRの趣旨と違う修正を入れていないか
ソースコード全体を読む人目線で
- 一つの関数、クラスに複数のロジックを詰め込んでいないか（単一責任の原則）
- 関数外に影響を与えるロジックが入っていないか（開放閉鎖の原則）
- クラス名や関数名などの命名が適切に設定されているか
  - ソースコードがドキュメントのように眺められるようなわかりやすい設計になっているか

特に最後に書いた「ソースコードがドキュメントのように眺められるようなわかりやすい設計になっているか」というのは結構意識してて、理想で言えばコードに対するコメントがなくても処理のロジックやユースケースが伝わってくるのが理想だと思ってます。
（反面コメントは、処理のロジックからでは推測できない補足情報を入れるのが理想だと思ってます。）