Green Bar Lover .NETコミュのXPのプラクティスについて

XP(eXtreme Programming)のプラクティスについて思うところがあればご自由に書いてくださいませ。

･計画ゲーム
･小さなリリース
･オンサイト顧客
･メタファ
･シンプルな設計
･リファクタリング
･テスティング
･ペア・プログラミング
･コードの共同所有
･常時結合
･コーディング規約
･持続可能なペース
･オープンワークスペース
･日ごとのスキーマ移行

.NET開発において、XPのプラクティスを実践してみて感じたこと、実践してないけど実際のところはどうなの？とか何でもOKです。

コメント(2)

最初
全て
最新の40件

[1] mixiユーザー 12月08日 11:04

リファクタリングに関して＠ITに記事が出てますね。

.NET開発者のためのリファクタリング入門
http://www.atmarkit.co.jp/fdotnet/special/refactoring/refactoring_01.html

[2] mixiユーザー 12月08日 11:59

テストファーストとリファクタリングに関して

レッド->グリーン->リファクタリングのサイクルで行なわれるテスト駆動開発だが、レッドは極力短くしグリーンの時間を長く保つ事に本質が隠れている。

レッドを極力短くしようとすれば、以下の様な手順を踏む必要がある。

１．小さなステップでテストを記述する
２．見栄えが悪いが、テストをパスするコードを素早く記述する。(極端な場合は固定値を返す。)
３．リファクタリングを行なう。(リファクタリングを行なっている間はグリーンのはずである)
４．上記を繰り返す。

「テスト駆動開発では設計を行なわないのか？」という質問をよく受けるが、これは大きな間違いだ。テスト駆動開発では、テストでインターフェースを設計し、リファクタリングで設計を改善する。先に紹介したリファクタリングの記事で「継続的なリファクタリング」としても紹介されているが、小さなリファクタリングを常に行なうことでミクロな単位で設計を改善し続ける。時には大きなリファクタリングも行なうことがあるが、基本的には小さな改善の積み重ねを繰り返す。不吉なにおいは塵も積もれば山となる。

テスト駆動開発のように、素早いフィードバックによって設計のブレを検知し、リアルタイムで設計改善ができる方法を私は他に知らない。

ログインすると、みんなのコメントがもっと見れるよ