一定規模以上のシステムで、プログラムが酷い状態の場合、

スクラッチから書き直しをすべきか、リファクタリングで
徐々に改善していくべきか、ご意見をお聞かせ下さい。

******
[ 所感 ]

■ 歴史的に見て、一定規模以上のプログラムでどれだけ
プログラムが酷い状態であっても、スクラッチから
書き直しをして、成功した事例が殆どないように思うので、
業界の通説では、「スクラッチからの書き直しはタブー」
ということになっている気がします。
(逆に、スクラッチから書き直しをして失敗した例は多数)

■ 最近、ソフトウエア工学の分野においても、
リファクタリングの手法が体系的に確立されつつ
あるように感じます

******
[ 疑問に思うこと ]

■ 以前、はてなが何かのシステムをスクラッチから
書き直しをしたと聞いた記憶がありますが、あれって
成功したのでしょうか?

■ プログラムはリファクタリングで頑張れるとしても、
DB構造が酷い場合、一時的に停止するとしても、これを
稼働させつつDB構造まで修正していくのは至難の技では
ないでしょうか?
リファクタリングの場合、DB構造の修正は
どうするのでしょうか?

******

回答の条件
  • 1人2回まで
  • 登録:
  • 終了:2007/07/28 01:45:03
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

回答3件)

id:garyo No.1

回答回数1782ベストアンサー獲得回数96

ポイント27pt

基本的に「動くものに触るな」というのが業界の常識でしたが、

TDDで「プログラムとテストケースを同時に書く」「テストは自動で行う」ということが可能になったため

「あるソースをリファクタリングした結果のデグレの有無」をxUnitによる自動検査で確認できるようになったため、リファクタリングが可能になったわけです。

よって、元々xUnitを使っていないようなソースをリファクタリングする場合はそのソース規模によっては自殺行為になるでしょう。

元々xUnitを使って自動テストができるように作ってあるソースであればリファクタリングも有効に使えると思います。

id:tomoyuki28jp

とても参考になる情報を

どうもありがとうございます。

ユニットテストについて

もう少し勉強してみようかと思います。

2007/07/21 13:57:32
id:cymneve No.2

回答回数261ベストアンサー獲得回数8

ポイント27pt

原則

(1)動作しているシステムには手を入れない。

(2)担当者が3代変わったシステムには関わらない。

(3)活きの良い若い兵隊さんを持ったとき、スクラッチで同等品や新作を作らせる。平行稼動させながら、蓄積データの移行を行う。

スクラッチからの書き直し大好きなのがLinuxでしょう。minixに仮想記憶を付ける改造から始まって以来、数え切れないくらい書き直されています。

昔と比べたらコンピュータは格段に大きく速くなったので、数万件程度のデータを扱うシステムなら、何も考えずに作っても実用に耐える性能が得られるでしょう。

経営陣が文系になれば、自社開発のコードなんて目の仇にされて

大手ベンダーのパッケージへ移行することになるようです。

id:tomoyuki28jp

原則3点とても参考になりました。

文面から察すると、ある時期では

書き換えをせざるを得ないという

ことかと思います。

ただ、スクラッチからやり直して

以降した後、バグが頻発しそうなので、

そこが心配ですねぇ。。

とても参考になるご意見、

どうもありがとうございます。

2007/07/21 13:59:14
id:KUROX No.3

回答回数3542ベストアンサー獲得回数140

ポイント26pt

リファクタリング (プログラミング)

出典: フリー百科事典『ウィキペディア(Wikipedia)』

に、DBに絡むものに関しては、「リファクタリングの課題」とし

てかかれてます。それ以外も、案外的をえたことをかいてます

ね(^^;

URL貼り付けるとうまくいかなかったので、検索してください。

おそらく、リファクタリングが可能かという視点でなくて

リファクタリング可能な設計・開発をすべきだと私は思います。

結論としては、リファクタリングを前提としてないものは

難しいと思います。

--------------------------------------------------

大体、醜いプログラム、DB構造なものって、

上流のシステム・DB設計から悪い場合が多いんですね。

■設計の問題

設計がまずい場合、リファクタリングしても個人的には

無駄かなと思います。

設計がうまい場合は、リファクタリングしやすいんですね。

まあ、設計がうまい場合は、大体、醜いとかといっても

前者の場合とはかなりの差がありますしね。

■開発モデルの問題

DBを用いた業務システムにウォーターフォールモデルの開発に

かかわってきた個人的な感触として書きます。

アジャイルソフトウェア開発とかだとリファクタリングと相性が

よいと思いますが、一定規模以上のシステムで業務知識が必要な

場合、どうやってやるのかな?という疑問は私もあります。

■醜い状態の落とし穴

(1)酷い状態に理由がある場合が存在するときがある。

  プログラムにおいてもDBにおいても、わざとそういう

  設計になっている場合があるので注意が必要

(2)バグにバグが重なって、なぜか仕様どおりの動きになって

 いる場合が存在する。(本当はそんなことありえたら駄目

  なんですけど)

■リファクタリングと自動テスト

単体テスト(関数レベル)

結合テスト(モジュールレベル)

総合テスト(プログラム・システムレベル)

にテスト段階をわけた開発を行うことを前提で。

|「プログラムとテストケースを同時に書く」

|「テストは自動で行う」ということが可能になったため

単体テストレベルではかなり効果があると思うんですが、

それ以上になると、すべてのテストケースが網羅されているか

があやしい思われます。特にDBが絡みだしたら、難しいかなと。

テストケースのプログラムの方が仕様を満たしてないとか、

1つ変更すると、テストケースのプログラムを数個書き直さないと

いけないと言う場合には、やっぱり安全性に問題があると思い

ます。

0から作る場合は、リファクタリングを「納期と予算」が許す限り

すべきだと私は思います。もちろん、各工程で妥当な範囲だけを

リファクタリングを行います。総合テスト工程に入っているのに

単体レベルのリファクタリングは仕事としては無理かも。

実運用に入ったシステムに関しては、正当な理由がない限りは、

触れないと思います。

DBに関しては、性能ネックとかない限り現実問題、修正は難しいかと。

■DBの変更の対応

Webアプリケーションとかは、MVCモデルで開発してるので、

理論上はDBの変更を吸収しやすい設計になってるはずです。

DB構造とプログラムの間にデータ層のような1クッション

あるシステムなら、対応はしやすいと思いますが、DB構造に

密接に結合したような設計だと、至難の業でしょうね。

id:tomoyuki28jp

参考になる情報を詳細に教えて下さって、

どうもありがとうございます!

DBまわりのことも丁寧に解説して下さって、

とても参考になりました。

やはり設計が根本から崩壊していたら

スクラッチからやり直さざるを得ない

ですよね。。

ただ、ゼロから一定規模以上のプログラムを

開発するのは熟練した人であっても難しいと

思っていますので、どちらにせよ大変そう

ですねぇ。

貴重な情報をどうもありがとうございました!

2007/07/22 01:30:05

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません