コーディング規約が浸透しない問題

コードレビュー、プルリクのタイミングなどでは、レビュアーの指摘は立ち位置をそのプルリク作者の思考地点に揃えるのが私は良いと思う。その前提が作れなさそうなら、実装方針を事前に揉むってことが必要だと思う。そういう流れが作れると割とスムーズになる。

— Hidenori Goto (@hidenorigoto) 2017年5月14日

2017/5/15 20:08 追記

システム開発で、レビューする側もレビューされる側も、成果物をレビューするという意識になっていると不幸になる。作業途中で方向性が間違っていないか？をレビューする

— てるろー (@terurou) 2017年5月14日

コーディング規約をつくっても読まれなかったり、定着しなかったりで、うまくいった試しがなくて、 なんでかなーと思っていたけれど、このツイートをみて、「実装方針の共有」ってところがキモになるんじゃないかと思った。

今まで見てきた/作ってきたコーディング規約だと、コーディングスタイルの話と、実装方針の話がごっちゃになって箇条書きにされているだけというのが多かった気がする。 コーディングスタイルを統一させたいのであれば、PHPならphpcsとか、rubyならrubcopとかあるし、Scrutinizerとか、SideCIでも静的解析はしてくれるので、そういうものを人間が目で確認しなくてもいいように取り入れていくべき。

実装方針については、フレームワークやライブラリによってある程度縛られる部分はあるし、エンジニアなんだから使っている技術は十分に知っとけっていう人もいるかもしれないけれど、スポットで入る人とか、初めて触る人との共有はやはり難しいと思うので、「こういう処理が書きたくなったら、このコンポーネントにまとめてね。」とか「この部分はテストパターンも厚めに書いてね」とか、共有できると、PR見る方も、投げる方も幸せになれるような気がする。

OSSでなくてもCONTRIBUTING.md作ってあらかじめ共有しときたいことは書いておいたほうが良いのだろうか。それでもやっぱり読まない人は読まないから、無駄なんだろうか。 「これくらい知っとけ」の場合でも、「この記事は読むべし」みたいな一覧があると、ミスコミュニケーションが原因でPR全部書き直しみたいな事態は防げそうだけど、大変でも苦労して頑張れ事案なのだろうか。