スクラッチから書き直しをすべきか、リファクタリングで
徐々に改善していくべきか、ご意見をお聞かせ下さい。
******
[ 所感 ]
■ 歴史的に見て、一定規模以上のプログラムでどれだけ
プログラムが酷い状態であっても、スクラッチから
書き直しをして、成功した事例が殆どないように思うので、
業界の通説では、「スクラッチからの書き直しはタブー」
ということになっている気がします。
(逆に、スクラッチから書き直しをして失敗した例は多数)
■ 最近、ソフトウエア工学の分野においても、
リファクタリングの手法が体系的に確立されつつ
あるように感じます
******
[ 疑問に思うこと ]
■ 以前、はてなが何かのシステムをスクラッチから
書き直しをしたと聞いた記憶がありますが、あれって
成功したのでしょうか?
■ プログラムはリファクタリングで頑張れるとしても、
DB構造が酷い場合、一時的に停止するとしても、これを
稼働させつつDB構造まで修正していくのは至難の技では
ないでしょうか?
リファクタリングの場合、DB構造の修正は
どうするのでしょうか?
******
基本的に「動くものに触るな」というのが業界の常識でしたが、
TDDで「プログラムとテストケースを同時に書く」「テストは自動で行う」ということが可能になったため
「あるソースをリファクタリングした結果のデグレの有無」をxUnitによる自動検査で確認できるようになったため、リファクタリングが可能になったわけです。
よって、元々xUnitを使っていないようなソースをリファクタリングする場合はそのソース規模によっては自殺行為になるでしょう。
元々xUnitを使って自動テストができるように作ってあるソースであればリファクタリングも有効に使えると思います。
原則
(1)動作しているシステムには手を入れない。
(2)担当者が3代変わったシステムには関わらない。
(3)活きの良い若い兵隊さんを持ったとき、スクラッチで同等品や新作を作らせる。平行稼動させながら、蓄積データの移行を行う。
スクラッチからの書き直し大好きなのがLinuxでしょう。minixに仮想記憶を付ける改造から始まって以来、数え切れないくらい書き直されています。
昔と比べたらコンピュータは格段に大きく速くなったので、数万件程度のデータを扱うシステムなら、何も考えずに作っても実用に耐える性能が得られるでしょう。
経営陣が文系になれば、自社開発のコードなんて目の仇にされて
大手ベンダーのパッケージへ移行することになるようです。
原則3点とても参考になりました。
文面から察すると、ある時期では
書き換えをせざるを得ないという
ことかと思います。
ただ、スクラッチからやり直して
以降した後、バグが頻発しそうなので、
そこが心配ですねぇ。。
とても参考になるご意見、
どうもありがとうございます。
リファクタリング (プログラミング)
出典: フリー百科事典『ウィキペディア(Wikipedia)』
に、DBに絡むものに関しては、「リファクタリングの課題」とし
てかかれてます。それ以外も、案外的をえたことをかいてます
ね(^^;
URL貼り付けるとうまくいかなかったので、検索してください。
おそらく、リファクタリングが可能かという視点でなくて
リファクタリング可能な設計・開発をすべきだと私は思います。
結論としては、リファクタリングを前提としてないものは
難しいと思います。
--------------------------------------------------
大体、醜いプログラム、DB構造なものって、
上流のシステム・DB設計から悪い場合が多いんですね。
■設計の問題
設計がまずい場合、リファクタリングしても個人的には
無駄かなと思います。
設計がうまい場合は、リファクタリングしやすいんですね。
まあ、設計がうまい場合は、大体、醜いとかといっても
前者の場合とはかなりの差がありますしね。
■開発モデルの問題
DBを用いた業務システムにウォーターフォールモデルの開発に
かかわってきた個人的な感触として書きます。
アジャイルソフトウェア開発とかだとリファクタリングと相性が
よいと思いますが、一定規模以上のシステムで業務知識が必要な
場合、どうやってやるのかな?という疑問は私もあります。
■醜い状態の落とし穴
(1)酷い状態に理由がある場合が存在するときがある。
プログラムにおいてもDBにおいても、わざとそういう
設計になっている場合があるので注意が必要
(2)バグにバグが重なって、なぜか仕様どおりの動きになって
いる場合が存在する。(本当はそんなことありえたら駄目
なんですけど)
■リファクタリングと自動テスト
単体テスト(関数レベル)
結合テスト(モジュールレベル)
総合テスト(プログラム・システムレベル)
にテスト段階をわけた開発を行うことを前提で。
|「プログラムとテストケースを同時に書く」
|「テストは自動で行う」ということが可能になったため
単体テストレベルではかなり効果があると思うんですが、
それ以上になると、すべてのテストケースが網羅されているか
があやしい思われます。特にDBが絡みだしたら、難しいかなと。
テストケースのプログラムの方が仕様を満たしてないとか、
1つ変更すると、テストケースのプログラムを数個書き直さないと
いけないと言う場合には、やっぱり安全性に問題があると思い
ます。
0から作る場合は、リファクタリングを「納期と予算」が許す限り
すべきだと私は思います。もちろん、各工程で妥当な範囲だけを
リファクタリングを行います。総合テスト工程に入っているのに
単体レベルのリファクタリングは仕事としては無理かも。
実運用に入ったシステムに関しては、正当な理由がない限りは、
触れないと思います。
DBに関しては、性能ネックとかない限り現実問題、修正は難しいかと。
■DBの変更の対応
Webアプリケーションとかは、MVCモデルで開発してるので、
理論上はDBの変更を吸収しやすい設計になってるはずです。
DB構造とプログラムの間にデータ層のような1クッション
あるシステムなら、対応はしやすいと思いますが、DB構造に
密接に結合したような設計だと、至難の業でしょうね。
参考になる情報を詳細に教えて下さって、
どうもありがとうございます!
DBまわりのことも丁寧に解説して下さって、
とても参考になりました。
やはり設計が根本から崩壊していたら
スクラッチからやり直さざるを得ない
ですよね。。
ただ、ゼロから一定規模以上のプログラムを
開発するのは熟練した人であっても難しいと
思っていますので、どちらにせよ大変そう
ですねぇ。
貴重な情報をどうもありがとうございました!
とても参考になる情報を
どうもありがとうございます。
ユニットテストについて
もう少し勉強してみようかと思います。