アカウント名:
パスワード:
# リファクタリング＝善とは限らない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
難しい・・・ (スコア:1, 興味深い)
私はそんなに経験豊かではないですが
会社の方の言い分も一理あります
私の場合、リファクタリングする場合は
1 リファクタリングの意味を顧客が理解しており、
且、その作業分の金がでる
2 リファクタリングしてもシステム全体に
影響がないことに確信がもてる
(コードを最適化してバグがでたら、まずいです）
3 リファクタリングした結果何か発生しても
す
学生ですが (スコア:1)
> 且、その作業分の金がでる
マーチンファウラーの本だとたしか、
「リファクタリングすることで将来の保守・拡張を容易にし、
結果的にプロジェクト全体の
Re:学生ですが (スコア:1, 興味深い)
ですね、
だいたい「リファクタリングしたほうが・・・」
と提案した場合の反応はこんな感じか？
良い顧客
「将来的にそのほうがうち(顧客側)で開発やる場合も
都合がいいから、別見積もりでいいから、やってよ」
普通
「いまテスト終わって、ちゃんと動いているんでしょ？
こっちも上司と期日を約束してるから
余計なことはしなくていいよ、」
少し悪
「良くなるんだったらやってよ！もちろん納期も
いまのままで費用も当初の見積もりには
Re:学生ですが (スコア:1, すばらしい洞察)
「（あなたにとって）都合の良い顧客」「（あなたにとって）都合の悪い顧客」が正しい。
# リファクタリング＝善とは限らない
Re:学生ですが (スコア:0)
>「（あなたにとって）都合の良い顧客」「（あなたにとって）都合の悪い顧客」が正しい。
良いお客さん=都合の良い客、悪い客=都合の悪い
Re:学生ですが (スコア:0)
"良いお客さん=都合の良い客、悪い客=都合の悪い客"という考えを共有できているのならそれでいいんでしょうが、
"よい会社=仕様変更や無理難題を押し付けても、さんざん値切った当初の見積もりの金額内でやる会社"という人もいるかもしれないし。
Re:学生ですが (スコア:0)
限られた開発費のなかで、何とかして
いろいろやってもらおうと思いまネ
結局のところ開発側の都合とお客様の要望の
妥協点を模索し・話し合うことの連続のような気がします。
プログラムを作る技術も大事だけど
お客様とお話するのも大事なんだな～
と改めて思う秋の夜(飲みすぎた)