この記事は
先日、チーム内で「良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方」という本の読書会を行いました。
- どうして読書会を行おうと思ったのか
- どんな風に読書会を進めたのか
- その後どうだったのか
といったことをお伝えしたいと思います。
はじめに
普段、Ruby on Railsを使ったWebアプリケーションをチームで開発しています。アジャイル開発手法のスクラムを運用していて、メンバー間でのコードレビューは勿論のこと、ペアプログラミングやモブプログラミングなども活用しながら日々開発に取り組んでいます。
最近、チームメンバーが大きく入れ替わって、新人さんの割合が増えました。
実装の手戻り
そんな中、チームメンバーが既存コードを流用して新しい機能を開発していました。しかし元コードの設計があまり良いと言えるものではなかったため、元コードを書き換えて新しい機能を追加するのに手こずっていました。そしてコードの品質も元コードの品質に引っ張られて、コードの保守性が低いものとなってしまいそうでした。
実装の途中でこのままでは良くない方向に行きそうだと気がついて、ベテランメンバーでクラス設計をやり直して、その設計を元にコードを書き直してもらいました。
すると、とてもスッキリしたコードになって、コード理解、テストコード実装、機能追加がやり易いコードになりました。
振り返りにて
毎週行っているチームの振り返りで、クラス設計することが大切だという認識を共有できました。そして、設計力を向上させたいけれど、それにはどうすれば良いかという話しになりました。
普段、チームメンバーのコードレビューをしていて、コードのどういった所が良くて、どういった所が悪いのか、この辺の知識と経験が足りていないところがあることがわかっていました。
そのため、まずは知識としてその辺りをインプットしてもらおうと思いました。
選書
私が以前に読んだことがある「良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方」を思い出しました。
2022/4/30に出版。サンプルコードはC#で書かれています。チームでは、Ruby on Railsを使っているのでどうかと思ったのですが、読んでみるとその辺はほとんど気になりませんでした。
良いコード悪いコードに対して、そのコードがなぜ良いのか悪いのか、わかりやすく説明してくれています。用語も丁寧に説明されているので、チームの共通言語を増やすのにもってこいだと考えました。
設計について書かれた多くの書籍では、業務分析、モデリング、UML、シーケンス、ユースケースなど、より上流工程をターゲットに書かれているものが多い印象で、それはそれで大事なのですが、難易度も高く、新人プログラマは敬遠しがちな内容に感じています。（オススメの設計本あったら教えてください！）
その点「良いコード/悪いコードで学ぶ設計入門」はプログラマ視点、コードに近い場所での設計について書かれています。業務分析みたいな話しは出てこない代わりに、どのようにクラスを分割すると保守しやすいコードになるかといったような話しが出てきます。
読書会：準備
2週間後ぐらいに読書会の日程を決めます。
それまでに読んできてほしいところを共有しておきます。
まず最初に、第15章「設計の意義と設計への向き合い方」を読んでもらってから
次に第1章から第6章まで読んでもらうことにしました。
どうして、第15章「設計の意義と設計への向き合い方」を最初に読んでもらうかというと
この章に設計がいかに大事かということが書かれているからです。
（個人的にはこれが第１章でも良いのではないかと思うぐらいです）
また1回で話し切るにはボリュームが大きいので2, 3回に分けて実施することにしました。
チームメンバーの中に、すでに読んだことのある人もいましたが、その人たちには再読してもらうことにしました。
読書会：当日
読書会の目的は、一人で本を読んで理解するだけでなく、本を読んだ人同士で意見交換することで、本の内容をより深く理解し、共通認識を得たりすることです。
第15章、第1章から第6章の順番に章ごとに区切って進めます。
1章あたり15分ぐらいを目安にしました。
Miroなどの付箋アプリなんかを使うとやりすいと思います。
まず3分ぐらい時間をとって、参加者全員にその章で気になったキーワード、フレーズ、考え方などを付箋に書き出してもらいます。
付箋が書き出せたら、同じような付箋を集めます。
次に5分ぐらい時間をとって、多くの付箋が集まったところについて、付箋を書いた人に意見や感想を述べてもらいます。付箋を書いてもらった人からも、そうでない人からも意見を集めます。
5分経ってまだ話しが盛り上がっていたら3分延長します。一通り話し終えたら次の付箋の山に移るようにします。
途中休憩をはさんで、全体で2時間ぐらい。
最後は、この日の勉強会の場を振り返って、みんなで付箋を書いて、それを共有して終わりにします。
その後どうだったのか
全部で17章のうち6章まで読書会しましたが、残りの章についても同じようにやっていきたいと思っています。
チームメンバーの「設計力を向上させたい」という動機から読書会をやってみましたが、流石にいきなり設計が上手になるというのはありません。ですが、コーディングとレビューの質は上がったと思います。当然かもしれませんが、経験の浅いメンバーほど効果が高いように思えます。
メンバーの成長もそうですが、私自信が改めて、良し悪しの理由＝価値基準をメンバーにインプットすることの大切さを再認識しました。
まだ設計力の向上には繋がっていないかもしれませんが、良いコードと悪いコードの理解が進んでいるので、どうすれば事前に良い設計を考えることができるのか分からなくても、書かれたコードを見て良い方向に進んでいるのか悪いコードに進んでいるのか、多少は見る目が養われたのではないかと思います。
仕様を実現するためにコードを書いていると、納期に追われてついつい複雑なコードになって行きがちだと思いますが、チームの中で「メソッド内のコードが長い」「条件が複雑になってきた」「変数名がわかり難い」など、これまでもよりも活発に議論するようになった気がします。さらに「クラスを分けようか」といった話題も出てくるようになって嬉しい限りです。
「設計力を向上させたい」このために、まずはこの本に書かれていることをチーム全員で理解して、そこからさらにステップアップして行こうと思いました。