"オブジェクト指向でコードが書けるようになろう。"参加して来ました。
【主催者】
DEVLOVEの主催のイベントです。
http://devlove.doorkeeper.jp/events/4060
【ゲスト】
"有限会社システム設計 代表取締役 増田亨"さんです。
増田さんのSlideShareはこちら。
http://www.slideshare.net/masuda220/presentations
【会場】
"リクルート メディアテクノロジーラボ"さんの会場をお借りしました。
【進め方】
CodeIQに上げていた課題への回答をグループ内で共有・議論し、その後に全体への共有、増田さんからのフィードバックという形で進められました。
そして最後に、質疑応答がありました。
【CodeIQに上げられていた2つの課題】
◆課題1
あるWebサービスの会員登録の画面で、以下の入力が必要です。
・氏名
・メールアドレス
・パスワード
・パスワード（確認用）
入力は、以下のルールを満たす必要があります。
・氏名は２０文字以内
・メールアドレスは、正しい形式
・パスワードは、半角英数字で、大文字・小文字・数字の三つが混在
・パスワードと確認用パスワードが一致する
この入力チェックを実現するためのクラスを考えてください。
※ 一つの問に複数のクラス名を解答してもかまいません。
※ 同じクラス名を複数の問に重複して回答してかまいません。
◆課題2
以下の「設計改善」をすると、クラス数はどうなるか考えてください。
（１）結合性を弱める
選択肢：
a.クラス数は増える
b.クラス数は減る
c.結合性とクラス数は関係しない
理由は？
（２）凝集性を高める
選択肢：
a.クラス数は増える
b.クラス数は減る
c.凝集性とクラス数は関係しない
理由は？
（３）リファクタリングする
選択肢：
a.クラス数は増える
b.クラス数は減る
c.リファクタリングとクラス数は関係しない
理由は？
（４）多態性（ポリモーフィズム）を高める（使う）
選択肢：
a.クラス数は増える
b.クラス数は減る
c.多態性とクラス数は関係しない
理由は？
（５）同じ機能を実現する場合、クラス数とクラスの大きさの関係は？
選択肢：
a. クラス数が増えるにつれ、個々のクラスは小さくなる
b. クラス数が増えるにつれ、個々のクラスは大きくなる
c. クラス数とクラスの大きさは関係しない
理由は？
【印象に残っている事（箇条書き）】
◆一概に良い設計、悪い設計とはいえない。
コードを保守する人や使う人、修正する人が使いやすい理解しやすい設計がよい設計であり、そのような背景なしに設計に良し悪しを付けることはできないとのことです。
TDDで開発するとコードの最初の使用者は自分になるようなので、この観点ではTDDは良い設計を導くと考えられます。
◆クラス名はお客様が理解しやすい名前を採用する。
課題1の値をチェックするクラスの名前として"Validator"や"Checker"などいろいろな名前が参加者の中から考え出されました。
お客様が理解しやすいという観点で、"Validator"よりも"Checker"の方が理解しやすいため、この２つでは"Checker"を採用した方が良いとのことです。
「関心事の分離」の中の「技術的関心とモデルの分離」に分類される話なのかと。
◆データ発生・変更のタイミングでクラス分割を判断する。
課題1の中で、プロパティ毎（氏名、メールアドレス、パスワード）のクラスは必要かどうかという話題になりました。
増田さんは意見は「氏名の変更、メールアドレスの変更、パスワードの変更は別々に行なわれることは容易に想像可能であり、別々に変更される可能性があるのであれば、それぞれクラスを用意した方が良いと思う。」とのことでした。
要するに「データ発生・変更が必ず同じタイミングで発生するプロパティは1つのクラスとして表現すればよいが、異なるタイミングで発生する場合は別々のクラスとして表現する。」とのことです。
この判断基準は非常にわかりやすく有用な気がしています。
◆単一責任（あとで修正）
設計スタイとして大きく、"単一責任（オブジェクトの役割分担）"と"データ + ロジック（オブジェクトの凝集度）"がある。（もちろん別の視点もある）
"単一責任"はメールクラスの中にメールの正規表現などのロジックを持たせるスタイル。
"データ+ロジック"はメールクラスは値だけ管理し、正規表現などのロジックは"Checker"のようなチェッククラスに分けるスタイル。
"単一責任"の方が変更が入った時の影響範囲が少なくなることが多く、良い設計になることが多いようです。
このように、設計の良し悪しを仕様変更時のクラスの影響範囲という判断も有効だと感じました。
"単一責任"はこちらに詳しくまとまっています。
http://d.hatena.ne.jp/asakichy/20090124/1232793592
【最後に個別に一つ質問をさせて頂きました】
◆質問
お客様やPMが良い設計を行なってコード品質を高めることを重視せず、とりあえず動くものを作ってくれと言われる場合や、プロジェクト開始当初からコード品質を高める時間がないような場合に、どのようにお客様やPMを説得すべきでしょうか。お客様やPMにコード品質の話をすると必ず、お金としてどれ程メリットを得られるのかと聞かれてしまい、期待に応えられる回答を導き出す方法を考えつきません。
◆回答
・そのような現場で働かない。
・自己責任でスケジュールに間に合わせつつコード品質を高める。
・プログラミングは職人芸なので、自分が納得出来るものは作るべきではない。
・コード品質をお金に換算するのは難しい。
・お客様やPMとコミュニケーションを取り、お金とは別の角度でアプローチする。
◆考えた事
コード品質をお金に換算するには難しいということで、コード品質を高められるプロジェクトを行うために必要な事を2つ考えました。
１．プロジェクトではなくプロダクトにフォーカスし、お客様（PMも含む？）の本当のニーズを引き出す。
プロジェクトにフォーカスしてしまうと「コード品質よりも低コストで動くもの作る」という発想になってしまうと思います。しかし、プロダクトはプロジェクトが終わった後も成長し、変化していきます。その際に、コード品質が悪い（テストコードがない事も含む）と変化に弱いプログラムとなり、変更のコスト（リスク）が大きくなり、結局変更（成長）できないプログラムになってしまいます。プロジェクト単位で考えるのではなく、プロダクトにフォーカスし、トータルコストを下げるという発想を持てれば、コード品質を無視したプログラミング（システム設計）はなくなると思います。この分野の話はリーン開発で語られていると思います。
２．品質の大切さを理解してもらうためには信頼してもらう。
お客様やPMから大きな信頼を得たエンジニアから"コード品質は大切です"と言われると、きっとお客様やPMは納得してくれると思います。結局、過去の実績（成果だけではなく）からくる信頼が、コード品質の重要性をお客様やPMに理解してもらうしかないかなと思いました。
以上、非常に有意義な時間を過ごすことが出来ました。
