湘南ボーイのIT日記

phpエンジニアで、スクラム開発で頑張ってます。

書評 【アジャイルモデリング―XPと統一プロセスを補完するプラクティス】

本日紹介する本はこれ。

アジャイルモデリング―XPと統一プロセスを補完するプラクティス (OOP Foundationsシリーズ)

アジャイルモデリング―XPと統一プロセスを補完するプラクティス (OOP Foundationsシリーズ)

 

アジャイル開発をやり始めて、もうすぐ1年が経ちます。

今の開発プロセスとしては、設計書を作る機会がほとんどなく、要求事項(ユーザストーリ)から直接プロダクトコードを作成する。という感じです。

 ※当然、TDDでやっているので、テストコードも作りますよ。

 

TDDで進めているので、クラス・メソッド単位でのリファクタリングをしながら作っていくんですが、僕の技術力不足もあって、最初にできあがったプロダクトコードのコードレベルがすげー低い状態で、できあがります。

この状態から、時間があれば、プロダクトコード全体のリファクタリングをやります。ただ、だいたいは、時間がないので、コードレベルが低い状態で、リリースして、リリース後に隙を見て、リファクタリングしているいうのが現状です。

 

リファクタリングをやる目的は、リリース後の追加機能に対応する場合で、既存のコードが汚くなってしまった場合にやるのが、本来の目的かなっと思っています。今のやり方だと、あまりいいプロセスではないので、どんどん汚いコードの量が多くなってしまいます。なので、最初からある程度のコードレベルの状態まで持っていきたいので、いろいろ悩んでいたところに、今回の本の存在を知り、読んでみました。

後、そもそ【モデリング】というキーワードはアジャイルやる前から気にしているキーワードだったので。

 

この本のコンセプトとして、モデリングの作成方法は記載されておらず、モデリングの進め方を記載しています。具体的には、XPで進める場合に、どうモデリングを開発プロセスに組み込んでいくか?等の話です。

 

基本的にXPのプラクティスを元にモデリングの組み込み方が記載されているので、アジャイル開発をやっている人には、ほとんどの内容がすんなり頭に入ってきます。

 

で、この本の中で、気になったことは以下。

 ①モデル≠ドキュメントである。

 ②これから作るものを理解するためにモデリングを行う

 ③チームメンバと話すためにモデリングを行う。

 

①に関して、簡単に言うと、

 作ったモデルの目的を果たせば、モデルを捨てよう。

です。もし、本当に残す必要があるモデルのみ、残しましょう。ということです。

この考え方は、ものすごい共感できますね。僕がドキュメントを作りたくない最大の理由は、ドキュメントのメンテナンスができる自信がなく、ドキュメントの存在自体が邪魔になって、めんどくさいからです。

このやり方なら、メンテナンスも考える必要もなく、楽ちんです。

 

②に関して、簡単に言うと、

 コーディングを始める前にじっくり考えてみたら、生産性が向上する。

です。

コーディングを始める前にじっくり考えるということは、僕の悩みを解決してくれる一つの解決策ですね。やっぱり無作為にコーディングをやるよりも、1時間なら1時間、1日なら1日と開発する規模に応じて、ちゃんと考えようと思いました。

 

③に関して、簡単に言うと、

 チームメンバのコミュニケーションを促進するために良い方法の一つである。

です。

これも非常に納得しました。コードレビューは、クラス・メソッド単位で実施していくんですが、対象のプロダクトコード・テストコードを見て、判断できることもあれば、全体像が把握できないと判断できないこともあります。

自分が全体像を把握しているソースの場合は、比較的にスムーズにコードレビューができるんですが、把握してなかったら、コードレビューをやっても、きちんと指摘できているか自信がないです。なので、やっぱり全体像が把握できる資料があれば、いいなっと。これに関しては、クラス・メソッド単位でレビューする考え方と全体をレビューする考え方に分けたほうが良いかなっと思いました。

 

 

明日から実践したい内容としては、

規模がそれなりに大きな開発なら、コーディングに入る前に②の内容をチームメンバ全員でレビュー/全体像を全員が把握する。

これが終われば、作ったモデルは不要なので、削除する。

コーディング中は、クラス・メソッド単位でレビューする。

をがんばっていこうかなっと。