BPStudy 第150回はコロナヴィルスの影響でZoomでの開催。初BPStudy参加でした。 Zoomには70名以上が参加して、最後の解散までの2hの間、70人以上をキープしていました。すごい。
https://bpstudy.connpass.com/event/166409/
自走プログラマーとは
「自走できるプログラマーは実装や設計に明確な根拠を持てるプログラマー」
自走プログラマー ～Pythonの先輩が教えるプロジェクト開発のベストプラクティス120 - amazon
kyさんが言った言葉を借りると「自走プログラマーってなんだろう」という疑問に対する端的な答えはこうなると思います。実装や設計について、「どうしてAのように書いたの？Bのほうが良くない？」と聞かれた時に、説明できる根拠を持つ。たいへんなことだと思う。
時間に追われるプログラマー
時間に追われるプログラマーは、とにかく時間がない。実装するときに「ベストプラクティスを探している時間なんてない」と考える。プログラムが動くのが第一優先事項。Googleで検索すればコードがたくさん出てくる。そいつをコピー・アンド・ペーストする。期待通りに動いたら「PR提出だ！」と意気込む。
このプログラマーは目の前の実装を一問一答形式の問題のように捉えている。「問題が解決できさえすればそれでよい」。その問題がなぜ起きているか、自分が選択した解決策がプロジェクトにどういう影響を及ぼすかという視野がない。気持ちはすごくわかる。時間がなくて、目の前に問題がある時、なるべく単純化して解決向けてひた走る。そういう対処法もあるけれど、目の前の問題だけに目を奪われると解決策の質とか、解決策の与える影響について殆ど考える余地が無くなってしまう。それは結果的に技術的負債を産み、問題を単純化してひた走りった恩恵より何倍も厄介なトラブルを引き起こす。ほとんど必ずと言っていいほど。そう言える経験が僕にはまぁまぁあります。
レビュアーからの視点
同じものでも視点が変わると見えるものが変わる。同じPRを見ていても、実装者とレビュアーは心持ちが違うと思う。「問題解決」を第一義とする実装者のPRを「品質の確認」を第一義とするレビュアーが見ている。この観点の違いがコードレビューの価値だと僕は思う。もし、「問題解決」ができてなおかつ「品質の確認」もできているPRならレビューなんていらないのかもしれない。
最近特にレビューに神経をすり減らしている。「絶対に一行も見落とさないぞ」という気持ちでレビューに挑んでる。すごく疲れる笑 でも、それが結果的に最良な方法だと今は考えている。リリースされてから出戻りが発生するより、レビューで突っ返されたほうが修正は何倍も楽だ。だから集中してレビューに望む。
もしレビュアーが少しでも適当になってしまったら。もし「品質の確認」という点で微妙なレビューをしたら。それはレビューをせずにmasterにマージするのとほぼ同じだ。だから、大変だけどレビューは本気でやる。
本気でやると、PRで指摘をする時に深く根拠について考えるようになる。コードに対して指摘する上で、端的に相手に伝わるように情報を集める。その過程で自分の中のベストプラクティス集が少しずつ形成されていく。（そしてそれが自分が実装者の時にコードレビューで指摘を受けてアップデートされたりもする笑）
最近の私
こうしてレビュアーとして取り組むようになって「根拠を深く掘り下げる」という行為を実装者としての自分に持ち帰るようになった。掘り下げた根拠はPRやコードコメント、Wikiに適宜書く！
それはそうと、プログラミングと建築って似てると思いませんか。自分が作って他人が長く使う。増改築があって、セキュリティと利便性が大事。仕事で品質のことを考えるといつも三匹の子豚を思い出します。「家がほしい」という要求に藁の家を作った子豚がいたとして。たしかに家はできてるけど、セキュリティがひどくて、増改築もし辛いんじゃ良い家じゃない。プロの仕事じゃない。ある一部屋を作る時は家全体のことを考えないといけないし、様々なことを考慮して作らないといけない。決して、部屋というスペースができればいいってもんじゃあないと思うんです。自走プログラマーは藁の家を作れるようになった子豚が更に次のステップに進むための一冊(あるいは考え方)なような気がします。レンガの家作りてぇな！
BP Studyでshimizukawaさん、kyさん、tell-kさん, haruさんの話を聞いて、とても刺激がありました。今回書いた内容は感想の一部です、勢いそのまま書きました。またモチベーションがUPUP！これからも立派な自走プログラマー目指して日々精進していきます。
