チーム開発力強化セミナー 〜 オブジェクト指向設計の基本を学ぶ 〜 に参加してきました

ギルドワークス社主催の「チーム開発力強化セミナー 〜 オブジェクト指向設計の基本を学ぶ 〜」に参加してきた。
http://guildworks.doorkeeper.jp/events/13967

参加者の内訳は
開発歴１年未満…10％
開発歴2~3年未満…20％
開発歴5年未満…20％
開発歴5年以上…50％（私は一応ココ）
だった。

「想定と違うな〜」とおっしゃっていたが、オブジェクト指向をちゃんと学び始めてまだ1~2年しか経っていないから私のなかでは想定どおり。

開発歴３年未満でこういうセミナーに来る人はすごいな〜、自分も開発しはじめたころからもっと自分に投資しておけばよかったと周りの人を見て感じた。

セミナーの内容はリファクタリングの方法となぜリファクタリングをするのか、に焦点をあてて解説と質疑・応答が中心。

リファクタリングをする理由は「変更コストを下げるため」。

今日、個人的に響いたことを３つ書き記してみる。

自分が昨日書いたコードの続きを今日書くのは、既存コードの修正

まっさらな状態からコードを書くのと、既に存在するコードを修正する機会はどちらが多いか？
既存コードの修正が多いからリファクタリングをする必要性もでてくるのだが、
昨日の自分のコードの続きも既存コードの修正で、常にリファクタリングを続ける必要がある。
そう考えると、ゼロからコードを書く機会なんてほとんどないなぁ。

「変更」の前にリファクタリングする。

リファクタリングせずに変更すると、5日かかるかもしれないが、
リファクタリングを1日かけてやったあと、変更すると1日ですむ。
変更コストが（大幅に）下がるため。

クラス図には業務の構造やビジネスルールが表現される。

逆にクラス図を見ても業務の構造やビジネスルールがわからなければ、設計に失敗している。
こういう視点でクラス図を見ていなかったので、目から鱗だった。
これからは、業務が表現できているかどうかをクラス図をみるポイントにしよう。

最後にリファクタリング（refactor*ing*）のing部分に込められているニュアンスも知った。
ingがついている場合は、「常に進化している・継続している」という意味であり、その意味でも、リファクタリングは１回やっておしまいではなく、毎日のコーディングのなかで常に行うものである。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)