アカウント名:
パスワード:
# リファクタリング＝善とは限らない
リファクタリングの意味を理解したところで「はじめから綺麗なコードを書いておけば良かったはずなのに、敢えて最初から汚いコードを書いて二重取り詐欺をする気か」と言われる可能性が大。。。
そういう顧客に限ってコロコロ仕様が二転三転するんだよな。。
愚痴なのでAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
難しい・・・ (スコア:1, 興味深い)
私はそんなに経験豊かではないですが
会社の方の言い分も一理あります
私の場合、リファクタリングする場合は
1 リファクタリングの意味を顧客が理解しており、
且、その作業分の金がでる
2 リファクタリングしてもシステム全体に
影響がないことに確信がもてる
(コードを最適化してバグがでたら、まずいです）
3 リファクタリングした結果何か発生しても
すべて自分で解決する覚悟・自身がある
ほかにもいろいろありますが、最低でこの3つ
をクリアしないと、よいと思っても手を出しません。
(他にやることはいくらでもありますし・・・）
プロと趣味のプログラマーについては、各人でいろいろ
あると思いますが、
みなさんはどうお考えですか？
学生ですが (スコア:1)
> 且、その作業分の金がでる
マーチンファウラーの本だとたしか、
「リファクタリングすることで将来の保守・拡張を容易にし、
結果的にプロジェクト全体のコストを下げることができる。」
と主張していたと思いますが、
親コメントのような発言が出ると言うことは、
まだまだ効果を実際に見ることができた人は少ないんですね。
Re:学生ですが (スコア:1, 興味深い)
ですね、
だいたい「リファクタリングしたほうが・・・」
と提案した場合の反応はこんな感じか？
良い顧客
「将来的にそのほうがうち(顧客側)で開発やる場合も
都合がいいから、別見積もりでいいから、やってよ」
普通
「いまテスト終わって、ちゃんと動いているんでしょ？
こっちも上司と期日を約束してるから
余計なことはしなくていいよ、」
少し悪
「良くなるんだったらやってよ！もちろん納期も
いまのままで費用も当初の見積もりには
いっているんでしょ？」
極悪∞
「ええ、よくなるんならお願いします(眩しいほどの笑い）」
：
後日、リファクタリングした箇所にちょっとした
ミスが出ると・・・
「ふざけんなよコラ！だったら値引きしろや！！(できればタダ)
もちろんサービスで保守半年無料もつけるよな！！」
まあ、極悪∞もたまに見かけるな
Re:学生ですが (スコア:1, すばらしい洞察)
「（あなたにとって）都合の良い顧客」「（あなたにとって）都合の悪い顧客」が正しい。
# リファクタリング＝善とは限らない
Re:学生ですが (スコア:0)
>「（あなたにとって）都合の良い顧客」「（あなたにとって）都合の悪い顧客」が正しい。
良いお客さん=都合の良い客、悪い客=都合の悪い
Re:学生ですが (スコア:0)
"良いお客さん=都合の良い客、悪い客=都合の悪い客"という考えを共有できているのならそれでいいんでしょうが、
"よい会社=仕様変更や無理難題を押し付けても、さんざん値切った当初の見積もりの金額内でやる会社"という人もいるかもしれないし。
Re:学生ですが (スコア:0)
限られた開発費のなかで、何とかして
いろいろやってもらおうと思いまネ
結局のところ開発側の都合とお客様の要望の
妥協点を模索し・話し合うことの連続のような気がします。
プログラムを作る技術も大事だけど
お客様とお話するのも大事なんだな～
と改めて思う秋の夜(飲みすぎた)
Re:学生ですが (スコア:1)
会社側としては作って稼働したらちょこちょこと調整してそれまでっていうシステムに
リファクタリングなんていう再生産の手間をかけたいとは思わないんじゃないかな？
-- 星を目指さない理由は何もない -- 「MISSING GATE」by 米村孝一郎
Re:学生ですが (スコア:1, 参考になる)
ある程度長期にわたって使用することを考えるなら何らかの
機能拡張は必要でしょう。そうしなければそのシステムを使う
業務そのものが陳腐化してしまうわけで。
# 「ちょこちょこと調整」でも、それをしやすくするための
# リファクタが有意義なケースは多いはずです。
Re:学生ですが (スコア:0)
その根拠は何でしょう？
この言葉は、自分の頭で考えることのできない人向けの営業トーク（コンサルティングのダマシ用語ともいう）という認識でいます。本当に自分の身の回
Re:学生ですが (スコア:1)
>少なくとも私が見てきた範囲では、陳腐化発生のタイミングは、「経営環境（3M）が変化したとき」に限られていると思います。
仰るとおりですが、さらに「コンサルのダマシ用語」を重ねるなら、経営環境が変化する速度が加速しているから、陳腐化のタイミングも早くなってきている、ということになりますね。
これはこれで正しいとは思います。
M&Aが頻発するような会社のシステムの面倒を見つづける場面を想像してみると実感が伝わるかな。
「システムが繋がらないから事業引継ぎできません！」って、経営に対してシステム屋は云えませんよね。
Re:難しい・・・ (スコア:0)
リファクタリングの工数を別途顧客からもうらには、今のご時世かなり
Re:難しい・・・ (スコア:0)
リファクタリングの意味を理解したところで「はじめから綺麗なコードを書いておけば良かったはずなのに、敢えて最初から汚いコードを書いて二重取り詐欺をする気か」と言われる可能性が大。。。
そういう顧客に限ってコロコロ仕様が二転三転するんだよな。。
愚痴なのでAC
リファクタリングに必要な環境への反論 (スコア:0)
> 且、その作業分の金がでる
いいえ。それは正しくありません。リファクタリングが内部的な開発効率を引き上げることをよく知りましょう。
ソースコードを探し回り、やっとのことで見つけた関数の名前が、以前の仕様に基づいた誤ったものだったとき、どれだけの時間が過ぎ去ったでしょうか。
その無駄が消えるのです。
関数名の変更が容易に実現出来る環境は、開発効率の向上に何の効果ももたらさないと思いますか？
>2 リファクタリングしてもシステム全体に
> 影響がないことに確信がもてる
> (コードを最適