概要
今更ですけどプルリク開発イイですよね。
自分がいるちょっと堅めの組織では、プルリク駆動が浸透するまでに1年半くらいかかりました。ただ、導入後のアンケートでははsvnを使いたいという人が皆無になるくらい、プルリク駆動開発には価値があると現場にわかってもらえましたので、導入時に効果的だった口説き文句をまとめてみました。
えらい人も説得しないといけないし、現場も説得しないといけないので、それぞれに向けたフレーズになっています。
なお中には、gitにもかかわらずtrunkという言葉を使っているケースがあります。これはgitのmasterブランチという言い方をするよりも、svn習熟者にtrunkという表現の方が刺さると考えられるため、あえてこういった表現をしています。
書かないこと
gitの内部構造についての話や、使い方についての話など、これらの説明を補強するバックボーンについてはサラっとしか記載していません。面白いのでいずれ是非そちらにも触れたいです。
対象読者
プルリク駆動がイイことは知ってるし、広めたいとも思っているけど、svn主流の環境ではどう広めたらいいのか悩んでいる、という方に向けた記事です。
対象環境
堅い組織向けということで、オンプレのGitLab環境を想定しています。
GitHubも良いですが、最近のGitLabも大変進歩してますよね。GitHubと比べて遜色ないどころか、組織によってはGitLabを導入した方がフィットすることもあるのではないでしょうか。
堅い組織では、GitLabが持つprotectedブランチが作れる機能は強みになります。gitの習熟度が低いメンバーが入っていても、masterブランチへの直接pushを防止できるというのは、導入のハードルを下げることに寄与します。
えらい人向けの口説き文句
では本題です。
「ほっといても継続的な教育効果が発生するようになります」
- 世の中、技術の進歩が速すぎてついていくの大変ですよね
- 教育のためのコードレビューをルールとして強制したとしても、svnでは全コードのレビューなんて現実的ではないですし、継続にかかるエネルギーが大きくてやめちゃいますよね
- プルリク駆動は日々のすべてのコーディングにレビューを強制します。レビューする側/される側それぞれが、実務に従事しながら継続的に学ばざるをえない環境をつくれます
「新人さんやパートナーさんのコードコミットに、レビューを強制できます」
- svnでは自由にtrunkにコミットができるので、レベル感の見えないパートナーさんのコードであとあと痛い目に遭うことって多いですよね
- あとあとになるほど問題への対処コストは指数関数的に増加しますから、早い段階で潰せるようになることは品質に寄与しますよ
「組織のコーディングレベル平準化を、ペアプロよりよっぽど低いコストで」
- 勉強熱心な開発者ばかりではないので、開発者ごとのコーディングレベルのばらつきってだんだん大きくなって悩みますよね
- プルリク開発では常時ペアプロに似た効果が期待できますので、継続的にばらつき解消ができますよ
- レビュワー/レビュイーの他に、プロジェクトに組織の全メンバーを含めておくこともできますので、組織全体のレベル平準化としても機能します(※)
- 受注規模を拡大するためには「人に作ってもらう」技術は重要ですが、組織として「自分たちも作ろうと思えば作れるんだ」という状態を維持し続けることも大切ですよね
※実際のところ全部のプロジェクトからメールくると鬱陶しいけど、最初はこれで押せることもある
現場向けの口説き文句
次は現場向け。
「シンプルな設計で非常に複雑な問題を解決しているからそうそう廃れないよ」
- 「gitを勉強したとしても、どうせすぐにその次のSCMが出てくるんでしょ、何回も勉強するのは大変だから嫌っス」って思ってるでしょう?
- gitは、コードベースが1500万行を超えるlinuxカーネルを管理するために、linus tovalsが自ら設計したシステム
- 内部設計は3種類のモデルオブジェクトをKVSとして1テーブルで管理するだけのシンプルなもので、それ以上シンプルなデータモデル設計が出てこない限り廃れないところが強み
- だから、勉強しても損しないよ!
※KVSを1テーブルとか言うのは強引な表現ですが、シンプルさの表現としてこう表現しちゃってます。
「プロジェクトメンバーに気兼ねすることなく、コミットできるようになるよ」
- 「機能まるごとtrunkにコミットするには粒がでかすぎる。細かくtrunkにコミットすると、他人のコミットと混ざって意味レベルでコミットをまとめられない。svnでのコミットの粒度悩ましい、ファック!」と思いながら開発してますよね?
- gitではあなたのブランチは別なメンバーのブランチに一切影響を与えません
- あなたはあなたの好ましいと感じるところまでコミットを重ねてブランチを伸ばしてから、まとめてtrunkにマージできるようになります
「gitは速い」
- svnもそう不満に感じるほど遅くはないと思うけど、普段触れるものの動作が速いことって、日常的なストレス軽減に寄与しますよね
- gitではすべてのオブジェクトがKVSで管理されるから、どのオブジェクトへのアクセスでも、探索にかかる時間がO(logN)に収束するんですよ
- linuxカーネル4万ファイル1500万行コードを現実的に管理できてるくらいですし、マジで速いですよね
※これは詭弁かもしれないけど、実際使ってて速いって感じるので、言っちゃってる・・・
そうは言っても、gitってそんないいところばっかりなの?
「gitが良さそうなのはわかった。ただね、そんなうまい話ばっかりでもないんでしょう?どういうところにデメリットがあるの?」という疑問は必ず出てきますよね。
いろいろな疑問に、丁寧に嘘偽りなく答えられるようにする切り返し集も、機会があれば書きたいなと思ってます。参考になれば幸いです。