とりあえずやってみればいいじゃん

読者です 読者をやめる 読者になる 読者になる

とりあえずやってみればいいじゃん

エンジニア関連のことについてつらつら書くブログ

11/10 コード改善 meetup #2に参加してきました

kaizen.connpass.com

前回の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さん

qiita.com

ボーイスカウト・ルールいいなと思いました。自分が書き始めた時よりキレイにして書き上げることができたら、、、いいですね。あと「技術的負債は複利で増える」というのはその通り過ぎると思いました。軽症な例で言うと、使おうとしてる変数名がすごく微妙なんだけど、もう既にいろんなところで使われているからその変数名を増産するとか。ロジックで微妙なのが増えちゃうともっと大変ですよね。きちんと対処していきたい。。。

リファクタリングの実情」@ryshさん

www.slideshare.net

自分のコードはリファクタリング時は「リファクタリング」という文字列をコミットメッセージに入れているはずなので割合出せるっちゃ出せるけど、、、恐ろしいですねw

このLTでも「人を巻き込む」というワードがあったのでやっぱそれは大切なんだなと思いました。

「null安全はいいぞ。だって、型安全はいいぞ。」@takasekさん

まず最初にものすごいタイムリーな内容だなと思いました。数日前にバズった記事を盛り込みつつ自分のLT作るってすごい。。。

null安全は機械に任せるべきものを機械に任せる仕組みというのは納得がいったし、ありがたいことだなと思いました。Swiftを書いている時にXcode側で即時に「これnull来る可能性あるからどうにかして!」って言ってくれるのは安心感があります。

対話後半

  • nullは結局何を意味するのか
    • nullの扱い
      • nullが来たら例外にする?エラーを表す何らかのオブジェクトを返す?空の配列を返す?
      • どのような時にnullを返すべき?
    • 回答
      • 設計、どこを守りたいかによる
      • 登録日付がnilだったら新しいユーザ、みたいなロジックがあるとnilを返すべきだし
  • 不要なテストの削除
    • より上のレベルで確認できるようになったのであれば消す