リファクタリングは趣味の世界？ 338
ストーリー by Oliver
明日は必ず来る 部門より
明日は必ず来る 部門より
Anonymous Coward曰く、"リファクタリング(マーチン ファウラー著 「リファクタリング」)とは「ソフトウェアの外部的振る舞いを保ったまま内部の構造を改善していく作業」のことで ここ最近、本屋さんでよく見かけるようになった開発手法XP(eXtreme Programming)の重要な要素の一つです。しかしながら、「動いているコードはむやみにいじくるな」というのは、どの会社でも暗黙のルールになっており、会社の人にも言われることだと思われます。
当方は新人プログラマなのですが手が空いた時にリファクタリングをしていると「きれいなコードだとかそういうのはどうでもいいから一度テストしたコードに手を付けるなボケ。自己満足は一人でおねがい。」と言われる始末です。たしかにリファクタリングは闇雲に行うと何日もの手戻りにもなりえます。しかし、体系化したリファクタリングを行うことにより「将来の機能拡張のために、コードを分かりやすくシンプルな状態に保つ」ことができ仕様変更が頻繁に発生する開発では長期的に見ると工数節約にもつながると思います。
Slashdotのリファクタリング支持者・反対者の皆さん、皆さんのリファクタリングに対する意見・経験をお聞かせください。"
JUnit, etc. (スコア:4, 参考になる)
ただし、「動いているものを触るな」文化においては、単体テストを自動化できているということそのものが幻想に近い、という現実があるように思えます。
とくに、既存のアプリケーションの改修において単体テストを自動化して導入しろ！といわれても、もともと単体テスト向きに実装されていなかったりして、リファクタリングもできずに泣きそうになることうけあいです。
# 単体テスト環境を整えろ！という状況におちいっているのでID
バージョン管理もね (スコア:2, すばらしい洞察)
テストなきリファクタリングはダメです (スコア:2, 参考になる)
単体テストがあれば、いつでもリファクタリングできます。予算ウンヌンの話が出ていますが、要求される納期に間に合わなければいくらテストがあってもリファクタリングはできません。ただし、リファクタリングすることによって要求される仕様の実現がスピードアップする場合はこの限りではありません。
プロダクトであれば、エンハンスのときに開発メンバが「自分たちのために」頑張って残業でもなんでもしてリファクタリングしてしまえばよいのです。ただし、この場合ひとりよがりなリファクタリングはいけません。あくまで、「コードの共同所有」ができることが前提です。
Re:JUnit, etc. (スコア:1)
単体テストの自動化は、新規開発時にやっておいたことがあります。
１年くらいの間は楽が出来ました。
まぁ、引継ぎを行って３ヵ月後には引き継いだ方々の無茶な改造で
まったく無意味になってしまいましたが。
かといって、途中から自動化ってのは、そのコストを負担するのがいやで
後々の世代までずるずる引き延ばされてしまうこと往々です。
まぁあとの世代で実施されたのを見たことはありませんし、
僕もやったことはありませんが。
単体テストは現実的？ (スコア:1)
「テストはリファクタリングに踏み出す勇気を与えるためのもの」
でテストコードで保証は取れないという話を見た記憶があります。
どこまで現実的なのかな～。。
それともテストコードがきっちり書けるクラス設計を、という事なのでしょうか。ん～。
Re:単体テストは現実的？ (スコア:2, 参考になる)
>でテストコードで保証は取れないという話を見た記憶があります。
XPでいう「勇気」は、ギャンブルに突入するための勇気…蛮勇…のことを指すのではなく、
ギャンブルでなくきちんとやれる目処をつけることを指す、のだったと思います。
＃実際できるかどうかはさておき、主張としてはそういうこと、だったと…
ところで、「テスト可能な」アプリケーションの設計 [ibm.com]なんてなwebページはいかがですか？
>それともテストコードがきっちり書けるクラス設計を、という事なのでしょうか。ん～。
「単体」をきちんと定義できているかどうか？っていう問題は、有ると思います。
どっからどこまでが単体なんだかワケワカなぐちゃぐちゃ設計だと、
XPだろうがなんだろうが、何持って来ようが救えないんだと思います。
上記ページによると、どうやら所謂狭義の「設計」だけをきちんとしてればテストができる、というものではないようです。
色々心がけるべき事柄が有るようです。
Re:JUnit, etc. (スコア:3, 参考になる)
自分も最初は同じ意見でしたが、
クラス設計以前のお客との意識あわせと要件の
煮詰めが一番重要で、その要求を満たすこと
"お客に上げてもらい"それをテストコードで記述するのです。
クラスの設計の前に、お客自身に自分の言っている
事の矛盾を自覚させ、自分自身の価値を再認識
させることが重要なステップです。
と、最近気付いてようやっと回り始めました。
開発形態の衝突 (スコア:4, すばらしい洞察)
リファクタリングという手法はコーディングとテストが早いペースで
回転している時、または開発工程に相当の余裕がある場合のみ有効な
手法です。
もし、あなたのいるプロジェクトがウォーターフォール型開発を
行っているのであれば、「テストが完了している」という状態で
コードに手をつけてしまうのはまさに自己満足に過ぎません。
# すでに目的の品質に達したものを、”未テスト”の工程に戻してしまうのですから。
仕事というのはチームで行うものですので、目の前のコードだけ
でなく、全体的な進捗やプロジェクト運営ポリシーも気にしてい
ないと、それはただの「オタのオナニー」であって、「プロの仕事」
では無いと心得ましょう。
んでまぁ、余談ですが。
現代のシステム開発では開発速度と品質が昔より
はるかに厳しい水準が要求されていますので。
たかが単体試験工程を手軽に（かつ迅速に）繰り返す事のできない
時点で私としてはそのシステムの品質はかなり怪しいと思います。
顧客は検収期間内にすべての試験を再現できるか？
-> 試験成績書の捏造がおこなわれていない事をどうやって
保証する気なのだろう。
-> 試験工程中に操作ミスがなかった事をどうやって（略
全てがすべて自動化できるとは思っていませんよ。えぇ。
踊る大捜査線 (スコア:3, すばらしい洞察)
正しいことをしたければ偉くなれ！ byいかりや長介
大ヒット御礼につきAC
Re:踊る大捜査線 (スコア:3, おもしろおかしい)
その映画は見てないのでID.
[udon]
Re:踊る大捜査線 (スコア:2, すばらしい洞察)
バランス感覚 (スコア:3, すばらしい洞察)
コスト（コーディングやテストなど）と効果（拡張性や技能の向上など）のバランス感覚は大切です。プロジェクトの一部しか見ていない人と、プロジェクト全体を見ている人の視点は異りますから、結論が異なるのが普通です。今のプロジェクトリーダーの考え方がベストかどうか分かりませんが、きっと将来の参考になると思います。
そういう問題意識をもって取り組むことが、きっと役に立つと思います。
（そんなの自分には関係ない、という人が多いので...）
私のところでも (スコア:2, 興味深い)
が数ヶ月続いておりましたが先日ようやく完了しました。
さっきシャンパン開けて乾杯したところです。
こういったこと（シャンパンじゃなくてリファクタリングね）
に対して肯定的なことはいいことだと思います。
ただし、ここの会社の場合、
「何！？機能はまったく変わらないのか？（愕然」
といった声も（営業側）少なからず聞こえます。
やはりシステム畑以外から見るとそういう考えをするのは
仕方ないのかなとは思ったり...
そいえば半年ほど前にガワだけデザイン方面の部課で
更新した時は社内は大変沸いていたように感じます。
# 他部とは裏腹にその時のシステム部のシラけムードは
# ある意味興味深いものがありました。
Re:私のところでも (スコア:1)
>「何！？機能はまったく変わらないのか？（愕然」
>といった声も（営業側）少なからず聞こえます。
営業さんからは、性能や保守性が上がることに対して、評価する向きが
少ないかったってことですか？
Re:私のところでも (スコア:2, 興味深い)
>少ないかったってことですか？
えぇ、そのへんの説明はしているはずですなんですけどね。
速度的な不満があるわけでない、とか、今までも保守出来てる
じゃないかという考えなのでしょう。
人の入れ替わりが激しく、かつまともな仕様書が無かったために
あちこちつぎはぎで...改変するにはまず解析から、
というこれまでの状態からするとかなり効率は上がるのは確実です。
ただ、プレゼンテーションが上手く出来ていないんじゃないかと
言われれば反論できないのかも。
Re:私のところでも (スコア:2, すばらしい洞察)
これまでと較べて目にみえて向上してこその
評価じゃないですか?
リファクタリングが修了しました。
ただそれだけじゃシステム部だって評価しないでしょ?
It's not who is right, it's who is left.
タレコミ人のリファクタリングはただの趣味だね (スコア:2, すばらしい洞察)
マネージャーになんて進捗報告してるんですか？テスト終わったって報告受けてるところがまた勝手にテスト中に戻ってたら、管理もくそもなくなりますよ。マネージャーの判断にも支障が出る。
プロジェクトメンバーの同意なしにテストの終わったコードをいじるなんて、もっての外です。
リファクタリングという手法に問題があるんじゃなくて、タレコミ人の姿勢に問題があるだけですね。
: 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
仕事だったらの話 (スコア:2, 参考になる)
後になって書き直したいなんてことは、山ほどあります。
ただ、仕事でやってる限りは、常にその作業をすることによって発生するコストも考えるべきであって、
リファクタリングをするにあたっては、その目的や効果を明確にした上で、その作業コストの確保の手段や、費用対効果を検討して、
やるかやらないかの判断をしなくてはいけないと思う。
新人だったら、上司に相談しましょう。
どうしてもリファクタリングしたいんなら、説得できるだけの十分な理由、根拠を提示しないと、ダメと言われるのは目に見えてる。
完了報告前なら (スコア:2, 参考になる)
ヘタクソなコード書いてると自分がプロジェクトから離れた後も質問がきて
現在の仕事が圧迫されかねない。
んで質問来ても昔に書いた自分のコードが読めないと..
# そんな人が近くにいるのでAC
ワインバーグさん風に (スコア:2, 興味深い)
これは誰の問題なのか。
- 新人プログラマ
- プロジェクトリーダー
- プロジェクトの他のメンバー
- 新人プログラマが勤める会社の上司
- 新人プログラマが勤める会社の社長
- システムを発注した会社の担当者
- システムを使うエンドユーザー
#あとが続かないけどID新人さん (スコア:1, 興味深い)
新人にリファクタリングさせるのは怖いね。
プロジェクト立てなさい (スコア:1, すばらしい洞察)
> 手が空いた時にリファクタリングをしていると
勝手に中身をいじっちゃったら、そりゃまずいでしょ。
きちんとリファクタリング・プロジェクトを立てて実行してるなら、問題はないと思いますが。
# うちの会社は、たぶんリファクタリングには予算つけてくれないだろうな。
# というか、時間的にも開発メンバーは余裕なさそうな……
Re:プロジェクト立てなさい (スコア:2, 興味深い)
>イライラすることはあります
そうなんですよね。
っていうか、イライラだけで済めばいいんですが、
実際にはそれ以上に…つまり品質に…直接響いてしまうわけです。駄目なコードは。
プロジェクト云々っていう方向性はちょいと危険です。
なまじ仕事のフォーマットにどっぷり則ってやろうとすると、
会社というものは元々「金について自らを最適化する」ものですから、
本質的に金にならない自分ちの掃除(^^;は、真っ先に経費を削っちゃうんですよね。
これが食い物業界なら、保健所が営業停止に*してくれる*ところなんですが、
ソフトにはそれが無いから、自助努力を放棄した企業は、いくらグチャグチャになってもおかしくない。
で、本当に生産性の良い(つまり恐らくは最終的に沢山稼げる)会社になるためには、
まずそういう自分ちの掃除が必要なのだとは思うのだが。
＃不要だと思ってる人が居るならお目にかかりたいのでG7
＃もちろんそんな人には俺の上司になってほしくないが。
余談：
駄目なコードを「自社の資産」と呼べる人は気楽ですねえ。
Re:プロジェクト立てなさい (スコア:2, すばらしい洞察)
しかないにせよ何にせよ、自分の果たす責任に対する対価を与えられている、という自覚を持つことはプロとして当たり前であり最低限の心構えであるかと思います。金貰ってるんだろうがと叱られるのは、ようするにそれが対価であるということがわかってないのではないでしょうか。志云々をいう以前の問題では。
難しい・・・ (スコア:1, 興味深い)
私はそんなに経験豊かではないですが
会社の方の言い分も一理あります
私の場合、リファクタリングする場合は
1 リファクタリングの意味を顧客が理解しており、
且、その作業分の金がでる
2 リファクタリングしてもシステム全体に
影響がないことに確信がもてる
(コードを最適化してバグがでたら、まずいです）
3 リファクタリングした結果何か発生しても
すべて自分で解決する覚悟・自身がある
ほかにもいろいろありますが、最低でこの3つ
をクリアしないと、よいと思っても手を出しません。
(他にやることはいくらでもありますし・・・）
プロと趣味のプログラマーについては、各人でいろいろ
あると思いますが、
みなさんはどうお考えですか？
学生ですが (スコア:1)
> 且、その作業分の金がでる
マーチンファウラーの本だとたしか、
「リファクタリングすることで将来の保守・拡張を容易にし、
結果的にプロジェクト全体のコストを下げることができる。」
と主張していたと思いますが、
親コメントのような発言が出ると言うことは、
まだまだ効果を実際に見ることができた人は少ないんですね。
Re:学生ですが (スコア:1, 興味深い)
ですね、
だいたい「リファクタリングしたほうが・・・」
と提案した場合の反応はこんな感じか？
良い顧客
「将来的にそのほうがうち(顧客側)で開発やる場合も
都合がいいから、別見積もりでいいから、やってよ」
普通
「いまテスト終わって、ちゃんと動いているんでしょ？
こっちも上司と期日を約束してるから
余計なことはしなくていいよ、」
少し悪
「良くなるんだったらやってよ！もちろん納期も
いまのままで費用も当初の見積もりには
いっているんでしょ？」
極悪∞
「ええ、よくなるんならお願いします(眩しいほどの笑い）」
：
後日、リファクタリングした箇所にちょっとした
ミスが出ると・・・
「ふざけんなよコラ！だったら値引きしろや！！(できればタダ)
もちろんサービスで保守半年無料もつけるよな！！」
まあ、極悪∞もたまに見かけるな
Re:学生ですが (スコア:1, すばらしい洞察)
「（あなたにとって）都合の良い顧客」「（あなたにとって）都合の悪い顧客」が正しい。
# リファクタリング＝善とは限らない
Re:学生ですが (スコア:1)
会社側としては作って稼働したらちょこちょこと調整してそれまでっていうシステムに
リファクタリングなんていう再生産の手間をかけたいとは思わないんじゃないかな？
-- 星を目指さない理由は何もない -- 「MISSING GATE」by 米村孝一郎
学生(計算機科学専攻)の意見ですが (スコア:1, 興味深い)
「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
と言われていると思えて仕方ありません。 ほんの少しデータ構造などを変更するだけで実行速度が劇的に速くなったりすることもあるので (ライブラリを使ってたとしても、それが今実行したいものに対して不向きだったりする場合もある) 完成品でも多少見直すくらいはしても良いと思います。
#現場を知らないど素人が！と言われそうなのでAC
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
自己満足でお金はもらえないんです。お客さんもよろこびません。
: 〜〜〜 パルナス、けだるい日曜日。 〜〜〜
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
現場を知らないど素人は「リファクタリングに必要なコスト」＝「プログラミングにかかる人件費」としか考えていない場合が多いですが、実際には検証にかかるコストやリファクタリングしたものを配布するコスト、配布が完了するまでに複数バージョンが並存する事によるサポートコストの方が何倍も（場合によっては何十倍、何百倍も）かかる事も珍しくありません。
また、人間が関与するものである以上、変更に伴う諸々のミスにより、動作しなくなるというリスクを0にする事はできません。
それだけのコストをかけてもなおメリットが得られる場合というのは、そうそうあるものではありません。
実行速度が劇的に速くなると言っても、今動いているものは、要求された時間内に終了しているのですから、それ以上を求めるのは趣味の世界です。
（要求された時間内に終了しなくなっているものに対しては「いじるな」とは言わないでしょう）
「速ければ速い程良い」というのは、まさに現場を知らないど素人の考え方、趣味の世界の考え方ですね。
Re:学生(計算機科学専攻)の意見ですが (スコア:2, 興味深い)
>「既にこの問題を解くアルゴリズムが出来てるんだから、新しいのは作るな」
>と言われていると思えて仕方ありません。
アルゴリズムやデータ構造で劇的に改善できるならば
プロジェクトマネージャとまず相談ですね。
劇的に改善されるならば、それはまだ完成していない状態ともいえます。
パフォーマンス（処理時間）も含めたテストで
ＯＫが出ているのですから一般的には改善の余地は無いと思います。
そんなアルゴリズムを考えられるほど余裕のあるプロジェクトは
ここ１０年お目にかかっていないですね。
Re:学生(計算機科学専攻)の意見ですが (スコア:1, 興味深い)
現場の細かい事情とか知らない人の方が本質を突いたことを言う
なんてのはよくあるよ。
Re:学生(計算機科学専攻)の意見ですが (スコア:2, すばらしい洞察)
『コード改善すればプロダクトの品質があがるのに、どうしてやっちゃいけないの?』という疑問は別にありえない質問ではないと思います。それが出来ないのなら「なぜできないのか」をきちんと挙げ、「できるようにはならないのか」を考える事も必要ではないでしょうか。
# なぜできないのか、は他のコメントで多くの方が言及されていますね
例えばリファクタリングコストでも、「機能のカプセル化」や「テストユニット」が出来ていれば、変更のコストや全体への影響は小さくなるはずです。方法論としては、eXtreme Programming や OOP, Design Pattern などが発展してきていると思っています。
仕事的にも「開発メソッドの改善」「QA方法の確立」等の形でやっている人もいると思います
現実的に難しいのは理解してますけどね。上や客まで巻き込む必要が往々にしてありますから。私だって勝手に検証済みのコードをいじられたら非常に困りますし、上に挙げたようなことも実現できてませんから。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
> >なんてのはよくあるよ。
> 別ACだが、それは偶々鉄砲の玉が的に当たったと言うだけ。
現場の人は色んな柵があって言えないことを、現場の細かい事情とか知らない人が口にしちゃう、ってこともありますね。
Re:学生(計算機科学専攻)の意見ですが (スコア:1)
個人的な研究や趣味の範囲はさておき、営利企業における開発なら、そういわれても仕方ないと思います。
ただし、その新しいアルゴリズムを顧客に説明し、理解してもらった上で、リファクタリングにかかる費用を捻出できるなら、新しいアルゴリズムでリファクタリングすることも認められると思いますよ。企画力・調整力・プレゼンテーション能力が必要です。
費用の捻出は、顧客から出してもらうことを含みますが、それ以外でも例えば、保守性が上がり社内の保守工数が減ることで相殺できると言ったことも含みます。
良くも悪くも、営利企業における開発とはそうしたものです。研究だって、チームでやる場合には、勝手にコードをいじることが許されない場合もあるんじゃないかな。私はそういう研究をやったことがないけど。
個人的な研究や開発であれば、どう行おうと自己責任で、でおしましです。
テストが終わるまでがリファクタリングです。(^^) (スコア:1)
>のはどうでもいいから一度テストしたコードに手を付けるなボケ。自己満
>足は一人でおねがい。」と言われる始末です。
それは当たり前。
特に君が新人君で「自分だけ」手が空いているなら。
私の場合のリファクタリング実践例としては、
機能を拡張しろと仰せつかったら訳わからんコードだった。
↓
拡張する前に整理しないと危なくて手が付けられないっす。
↓
リファクタリングするので時間ちょーだい。
↓
さっぱりしたし処理の流れも良くわかった。拡張しまーす。
て感じかな。大体。
仕事は何事にも「ホウレンソウ」が基本よ。
Re:テストが終わるまでがリファクタリングです。(^^) (スコア:1)
言うは易し (スコア:1, 興味深い)
「将来の機能拡張のために、コードを分かりやすくシンプルな状態に保つ」
というのはなかなか難しいのでは？と思います。
将来性を考えれば考えるほど、
余計なものをあらかじめ用意しなければならず､
コードはどんどん膨らんでいくような。
何も考えず、その場しのぎに作ったものの方が
バグも少なかったりすることも結構あります。
＃私が下手なだけかも。
Re:言うは易し (スコア:2, すばらしい洞察)
後で拡張する時の障害になりそうなもの、
初期の開発で埋め込まれた余計なコードや概念を片っ端から
取り除いて行く。
= 後の建増しの為にあらかじめさら地にしておく。
というのがリファクタリングだと思っていましたが、まちがって
ましたかねぇ。。。
wild wild computing
今使わない機能は後でも使えない (スコア:1)
今使わない余計な構造は入れず、現在の要求を満たすために十分な
機能だけを入れ、全体としてシンプルな状態に保つことによって、
結局は、将来機能拡張するときにかえって楽になる、
という考え方に基づいているように思います。
きっと使うだろうと思って用意した機能が、後になってみると
全然使われていない、ってことも結構ありませんか？
実際それを必要とするときになってみると、必要な機能と一致
していない、ということもあるように思います。
そういう意味では、「何も考えず」というので正解なのかもしれません^^;
ブランチ分けして (スコア:1, 参考になる)
片手間でやるならその辺が限度かなぁ。
いきなり本チャンのコードに反映されると困ると思う。
# なんて偉そうに言える立場でもないので AC
厭なものを見てしまったりしないの (スコア:1, 興味深い)
しかもそれは潜在バグなので修正代は別費用だろうし、直せばそれで他所がエンバグしたりするだろうし(鬱)
#世間一般のソースコードって品質高いのね…
大規模プロジェクトに関わってる皆様 (スコア:3, おもしろおかしい)
ためしに「とりあえず」でソース全体をgrepかけてみてください。
#38個ヒットしたのでAC
Re:自己満足は独りでお願いします (スコア:2, 参考になる)
＞考えて、周りとのコンセンサスや理解を求めるとか、そういう
＞社会人としての常識を先に覚えたら？
まあ、言い方は悪いですけど、その通りだと思います。
しかし、往々にして他人の書いたコードは汚く見えるし、自分の書いたコードでも、ちょっと前のコードを書き直したくなることもありますよね。新人さんなら特に、日々新しい発見があったりするでしょうし。
あと、ファウラーさんの言ってることはすごく正しく見えるし、若い方なら正しいことを実行するのがナニが悪い！みたいに思うこともあると思います。（だけど、テストが終わったコードに手をつけるな！というのも、正しい場合はありますよｗ）
ただやはり、他の方も言っているように、自分勝手な行動はまずいと思います。保守的であったり、新しい技術や考え方に理解を示さない上司はたくさんいて、あいつら間違ってる！と思うこともありますが、だったらまずはプロジェクトメンバーに積極的なアプローチを行って、リファクタリングの価値や必要性（本当に必要なら、ですが。）を浸透させてから行動に移す、というのが本筋だと思います。
# 頑張れ新人！ｗ
Re:自己満足は独りでお願いします (スコア:1)
>タレコミとはねぇ。青臭い同調意見でも欲しかったのかねぇ。
個人攻撃してもはじまらんよ。
よくある話でしょ？この業界じゃ。
* コード品質
* 性能
* 開発速度（納期厳守）
* 新人教育
のトレードオフってのはどの業界でも永遠のテーマだと思う
のだが、この業界じゃ特に厳しいような気がするよ。
wild wild computing
Re:それ正論 (スコア:3, 興味深い)
組織内での日常的な連携とバージョン管理システムがあれば、ソースを弄ることに問題は生じ難いでしょう。問題が生じるのなら、管理に問題があるのです。
私は、保守性の向上を目的とするソース変更は、積極的に奨励しています。書きっぱなしのコードはそのうち保守できなくなります。担当者が内容を覚えているうちに、長期の保守が可能な程度までソースを書き直さなければ危険です。
あと、インタフェイスの作り直しも重要です。内製ツールのメッセージ表示や操作手順が統一されているか、注意してみましょう。
Re:それ正論 (スコア:2, すばらしい洞察)
ちょっとちゃうんでは？
テスト完了したプログラムというのは、工程として既に製品用のリリースとして認定されたものって事なので、それをリプレイスするってのは単に「ソースを弄る」と言う物ではないですよ。
故に、工程管理の認可なしのソース変更は一切認められません。
否定的な意見も多いですが、皆単にそういう意味で言っているんだと思いますが。
私の経験した一番厳しい所だと、マネージャーからの許可なしのソース変更は違法アクセスと同様に扱うって所もありました。
自分で完結するようなものであれば自分の責任だけでどうにかなるでしょうけど、大規模になればなるほど、単なるソースに対する責任者と全体責任を取る人間との間の人間が増えるので、きちんとした手順を前提としなければ否定的な意見を出して来ると思われます。
が、それもまた、ソフトウェアの品質の維持の為の意見なんですよ。
ソフトの品質はソースの質だけで決まるものではないという事で。
Re:一般常識レベルの話では？ (スコア:2, 興味深い)
> はおかしいですな。手が空いているなら自分から
> 上司なり先輩なりに仕事をもらいに行けと。
仕事をもらう、という姿勢で仕事をするよりも「こういったことをやりたい」とアピールすると吉かもですね。
その時の状況次第でリファクタリングが適切かどうかも上司が判断してくれるでしょう。
駄目なら駄目で、その理由をきちんと上司から聞き出せればそれも勉強になりますし。