細谷さんのブログ、「XDDPについての議論」を読みました。
XDDP のことも言葉だけ程度にしか知ってなくて、
「派生開発」という言葉のイメージから、私は表面的な捉え方しかしてなかったようです。
上記のページより（ブルーで）引用しつつ、感想を少し。
XDDPを適用する判断基準は次の通りです。
- 自分達でない誰かが作ったプログラムの変更である。
- 役に立つドキュメントがない。
- 長い関数が大量になるなど複雑なコードになっている。
- 変更にかけることができる期間やコストが少ない
なるほど。自分たちで作ってなければ、なのかぁ。
現在私は、組込みの分野でオープンソースをベースにしたポーティングや改造を行なっています。
まさにぴったり、なわけですね。
「派生開発」、ノーマークすぎでした。
私はXDDPとアジャイル開発の共通点は、
“チームでコードレベルまで共有することに対するこだわり”だと感じています。
これは「グッときちゃう」フレーズですねー！
私は、XDDPは“良くわからないコードをチームでハッキングするためのプロセスの一つ”と捉えています。(...)
あたりまえのことですが、他人が作った複雑なコードの変更影響を見落とさないためにもっとも必要なスキルは、
“コードを読む力”です。XDDPはコードを読んだ結果の残し方を定めたものであり、(...)
細谷さんは、
チームみんながコードにふれ、コードを理解するということが、
どれだけの開発力になるのかを、よくご存知なのだと感じました。
ソフトウェア開発が分業で行われていく中で、設計書が、
プログラムのわからない人のための資料になったり、
プログラムへの落とし方や、コードレビューのための解説資料になっていたりする場合もあるかと思いますが、
単にそれが標準プロセスだからという理由だけで作成されるのではなく、
必要であるからこそ作られる資料であってほしいと思いますし、
ソースコードのドキュメントとしての価値や役割というものを、
もっと我々自身が認めていかなければならないと思っています。
ググってみると、XDDP のことがたくさん出てきました。
派生開発のことをもっとしっかり勉強しようと思います。
