Rails Developers Meetup 2018 なぜかコミュニケーションの問題に行き着く不思議
Rails Developers Meetup 2018
↓のエントリではマイクロサービス系のセッションについての感想をまとめたので、今回は別のセッションについて。
Rails Developers Meetup 2018 世はまさに大マイクロサービス時代 - DDD ディストーション駆動開発
神速さんの発表は私的ベストセッション
神速さんのセッションは、Railsやってる全ての人に教えたい、と思うくらい素敵でした。月曜日早速社内で共有しました。
私がRails始めたばっかりの時にこのセッション聞いてたら、あんなクソコードは書かなかったし、それがコピペされることもなかったのに、、、本当に耳の痛いセッションでした。
scaffoldで生成されるコードを読む
Rails始めたばかりの時「業務でscaffoldなんか使えねーよ」って思い込み、最近に到るまでscaffold忘れていましたが、本当にもったいないことしたと思っています。
scaffoldのコードはRails謹製のお手本な訳で、既存のコードがこれと似ても似つかない作りだったら、既存のコードの作りが悪いのだと思うのですよね。
Rails始めてから４年間、自分なりに色々考えた結果、「Railsっぽくないやり方を選ぶ」というのは大概間違いの始まりである、と気づきました。だって自分がDHHさんより頭いいわけないからね。
（すぐRailから外れたがる人のことを心の中で「CrazyTrain野郎」と呼んでいます。）
少しづつ弱体化させる
リファクタリング、っていうと「がっつりリファクタリングの時間が必要だ！」みたいになりがちですが、そんな時間取れるわけないです。「最終形としてはこうしたいけど、一気にそれをやる時間はないから、今回はここだけ最終形に近づけておく」みたいなことを繰り返して行くしかないと思うのです。
ただ、「最終形はこうだよ」が共通認識になって「みんなでここを目指そう」という状態を作るのって難しいですよね。。。
がんばっていくしかない。
五十六メソッドとペアプロ
やってみて
言って聞かせて
させてみて
褒めてやらねば
人は動かじ
Aimingさんでは上記のような観点からペアプロを実践しているそうです。
私もこの言葉好きなので、ちょっと嬉しくなっちゃいました。多分これって、
- 言った本人がそれを体現していること...説得力が違う
- やったことを褒められること...見てもらえたこと、行動が正しかったことがわかる
っていうのがとても大事なんですよね。そういう意味だと、ペアプロやった後も、これがいいよと伝えた内容が実践されていたら、コードレビューなりで褒めるの大事だと思います。
自分はKPT使ったふりかえりの「K」で「このPRのここのコードすごく良かった。こういうもの書くときはこれを真似てほしい」というのを伝えるようにしています。
（そのために、ふりかえりに参加するメンバーのPRは休憩時間とかにめっちゃ目を通してます）
概念を掴み取る力と、それを伝える力
設計とは
・概念に名前をつけること
・地図を描くこと
・境界を決め、それを守ること
joker1007さんのこの言葉。設計に必要なことが、端的に表現されていて本当に凄いです。しかも言葉選びがカッコイイですね。
設計レビューするときに知りたいのは「どのClassにどのメソッドを、、、このメソッドは、、、」とかいうものではなくて「この機能のためにこういうことをするClass達を作る」っていうものなんだよ、、、コードは.rbに書いてくれ、っていつも思います。
機能を実現するのに必要な概念が出揃ってて、それぞれ命名が適切なら、だいたい大丈夫だと思うのですよ。
ただその、「これはこういうことだよね」っていうのを掴み取ることと、掴んだものを適切な言葉に置き換えていくことって難しいですよね。
描いた地図の共有が最も難しい
人が作った機能を改修する時は、作った人が描いてた世界に思いを馳せて、それを壊さないように、そっとやりたいことを乗せて行って欲しいのですよ。それっぽい箇所にそっとif文増やしたらやりたいことできた、とか、力技で乗り切った、とかやると、少しずつ世界が歪んで、気づいた時には「どうしてこうなった？」ってなるんですよ。
まとめ：コミュニケーションの問題に行き着く不思議
みんなで共通認識を作るの難しいね、とか、やって見せて褒めよう、とか、掴んだ概念をうまく言葉に落としこもう、とか、なんかエンジニアリングの話なのにコミュニケーション能力求められている不思議。
フレームワーク使った開発、チーム開発って結局それが全てなんですね。