チームで読書会やってみたyo！

題材

良いコード/悪いコードで学ぶ設計入門

きっかけ

1人でこれ読んでチームslackに「良かったよ！」と報告したところ、反応してくれた人（積ん読してる、昔読んだなぁ、気になる、etc...）がいたので、有志で読書会することに。

スタイル

• 基本毎日開催
• zoomで
• 人数は3~5人（忙しい人は不参加なことも）
• 1回30~60分
• 1回あたり10~15ページ（キリの良いところまで）
• 最初15分で読む&付箋ツール（miroとか）に感想、理解したこと、疑問点、持論など自由に書く
• 残りの時間で付箋の内容をベースにフリーダムに話す

学び（本の内容について）

• 読みづらいコード、保守（機能追加/改善）しにくいコードとはどういうものか（＝いわゆるアンチパターン）について理解が深まった
  • 特に、今までなんとなくこのコード嫌だなぁというのが言語化されて名前がついたことで、知覚とチーム共有がしやすくなった
  • 詳細については割愛（本を読めば分かる内容なので）
• どういうコードが読みやすい、保守しやすいかについても理解できた
  • 粒度（メソッド/クラス/パッケージ/モジュール）は異なれど基本はカプセル化（＝内部処理の隠蔽）。カプセル化された小さな処理単位をまとめて1段大きな処理単位を作る（もちろんそれもカプセル化する）。それを繰り返していくことで大きなアプリケーションの処理を実現していく。
• 既存のコードをどう改善していくかについても一定のヒントが得られた
  • いわゆるリファクタのやり方。
  • ただ内容としては重きを置いておらず、書内でも別のリファクタ本(リファクタリングとかレガシーコード改善ガイドとか）を薦めていたので、本格的に学ぶにはそっちを読んだ方が良さそう。
• 改善していく際の心構えとか布教のさせ方について触れられていたのが新鮮だった
  • 1人でやるとしんどいけどチームの10%を味方に付けられれば1つの勢力として認識してくれるので物事を進めやすい
  • パレートの法則（全体の20%の要素で価値の80%を生み出している）を参考にすると、実はリファクタすべき箇所はそんなに多くなく、コア部分（20%の要素）を優先的にやっていけば良い
  • 一度で完璧を目指さず（そもそも完璧な設計/コードなんてものは存在しない）、日々インクリメンタルに改善していけば良い

学び（読書会自体について）

• 1人で読んだ時とは違った気づきがたくさん得られた
  • これはうちのチームで使えそう/難しそう
  • 自分とは異なる解釈
  • 派生した話
• 人数は3~5人でちょうど良かった
  • 全員が何かしら発言できる/発言しやすい人数
  • これ以上増える場合はブレイクアウトルームとかで分割しても良さそう
• 1回あたり30分くらいがちょうどいい
  • 60分はさすがに長いなと感じた
    • とはいえ、議論が白熱した時に30分で切れちゃうと不完全燃焼感もあるので、基本30分でMAX60分まで、という体であれば割と苦ではなかった
• 事前課題（読んでくる等）は無しで良かった
  • そもそも忙しくて読む時間を取れない
  • 事前課題をやってないことで「今日行くのやめとこ...」というのを無くしたかった
    • 結果的にうまく行ったっぽい
  • 数日休んでても行けばその日の会話には入れるという安心感は出せた
  • とはいえ今回は布教に重きを置いて入りやすい環境であることを意識したので、元々意欲の高いメンバーでやるのであれば事前課題を用意しても良いのかもしれない
• 付箋ツールに自由に書く&付箋を起点に話すというスタイルは良かった
  • 付箋を書けば皆んなに一度は発言権が回ってくるので、本人の気質（積極的/消極的）に関わらず色んな人の意見を集められた
• （複数人でやった割には）思ったよりハイペースに進められた
  • 400ページ弱の本を約1ヶ月半（30営業日）で読み終えられた
  • 毎日開催というのがデカかった
    • 逆に繁忙期と重なってしんどいタイミングもあった
  • 業務に必要だけど積ん読してるなぁという本を読むには良いやり方かもしれない（仲間を集められれば）