11/10 コード改善 meetup #2に参加してきました
前回のmeetupから...
- 品質改善チームを設立
- 効果を計測
- 品質評価
- Scrutinizer導入
- Re:dashを使用
- 月に1度の改善day
LT前半
「進め方」@futoaseさん
コード改善を筋トレに例えてのLTでした。言われてみれば筋トレとコード改善は似ているところがありますね。地道ですぐに効果は見えないし。
「理想・ゴールを持つ」という項目がありましたがこれ意外と難しそうですね。コードが改善された状態とはどんな状態なのかを言葉で明確にするにはどうしたもんか。そしてゴールに達したかどうかをどう判定するのか。懇親会で聞いておけば良かったなーと今になって思いました。
「You Can Change Your Team.」@secret_hamuhamuさん
www.slideshare.net
チームビルディングの話でした。「正しい課題設定をしよう」という部分は特に印象に残りました。問題の本質を理解してissueを導き出して、さらにそこからサブissueを特定して、というのは会社で教えられてきたことですが、それとちょっと近い部分もあるのかなと。
※LT中に出てきたタックマンモデルは知りませんでした。PLC（製品ライフサイクル理論）のチーム版のような印象を受けました。時を経るにつれてチームの性質が変わり、その時期によってチームリーダーは舵取りの方法を変えていくべきという内容だと認識しました。
「コードレビューの文化を手探りで作っていった話」@yasuhirokiさん
www.slideshare.net
「コードレビュー依頼時のテンプレート」で話されていたのですが、プルリクのテンプレートを設定することができるんですね。知らなかった。。。GitHubのIssue・PullRequestのテンプレート機能を試したという記事によるとissueも同じようにテンプレートを作っておくことができるようですね。
このLT聞いていて思ったのはやっぱりコミュニケーションって大事だなと。意味、意図を伝えることで人は動かせるんだなと思いました。
対話前半
前半のLTを受けて、みんなで質問、議論する時間です。いろんな話が出ていたのでざっくり箇条書きでまとめます。
- PR上で会話していてもPRを見ない人には実装、状況がわからない
- みんなで集まる機会を設けてそこで話す
- コードレビューは少人数、ピアでやる
- 大勢の前で叱ってはいけないという原則
- どっちでもいいようなものは指摘しない
- レベルが近い人でピアレビューしている
- ルールを作ったら「ガチガチすぎない？」と言われた
- リーダブルコードを持ち出してみた
- 仲間を作った
- コードが改善されると自分の時間が増えて他のことにかける時間を増やすことができる
- コードレビューの意義
- 品質の保証と言うとコレジャナイ感
- 品質の保証をテストで担保できればレビューはコードの良し悪しにフォーカスできる
- エラーがでるコードは機械で弾く
LT後半
「コードを改善する3つの方法」@sinsokuさん
ボーイスカウト・ルールいいなと思いました。自分が書き始めた時よりキレイにして書き上げることができたら、、、いいですね。あと「技術的負債は複利で増える」というのはその通り過ぎると思いました。軽症な例で言うと、使おうとしてる変数名がすごく微妙なんだけど、もう既にいろんなところで使われているからその変数名を増産するとか。ロジックで微妙なのが増えちゃうともっと大変ですよね。きちんと対処していきたい。。。
「リファクタリングの実情」@ryshさん
www.slideshare.net
自分のコードはリファクタリング時は「リファクタリング」という文字列をコミットメッセージに入れているはずなので割合出せるっちゃ出せるけど、、、恐ろしいですねｗ
このLTでも「人を巻き込む」というワードがあったのでやっぱそれは大切なんだなと思いました。
「null安全はいいぞ。だって、型安全はいいぞ。」@takasekさん
まず最初にものすごいタイムリーな内容だなと思いました。数日前にバズった記事を盛り込みつつ自分のLT作るってすごい。。。
null安全は機械に任せるべきものを機械に任せる仕組みというのは納得がいったし、ありがたいことだなと思いました。Swiftを書いている時にXcode側で即時に「これnull来る可能性あるからどうにかして！」って言ってくれるのは安心感があります。
