あなたのペニーピンチのボスにリファクタリング作業をどのように正当化しますか？

Question

あなたは、圧力の下で重要な機能を提供するコードを書きました。あなたはいくつかのコーナーを切り、SerialIndirectionShutoffManagerのような名前を持つ過度に肥大化したクラスにいくつかのコードをマッシュアップしました。

あなたは上司にこのことをきれいにするために1週間必要とします。

"何をクリーンアップしますか？"

"私のコード - その豚のような！"

「もう少しバグの修正がありますか？」

「そうでもない、そのようなより多くの..」

「あなたはそれをより速く走らせるつもりです？」

は「おそらく、言い訳はないthatsの..」

あなたはチャンスがあったとき、「次にあなたはそれを正しく書かれているはずです。今、私はあなたがここにいるうれしいです、ええ、私はつもりは行かなければなりませんよ先にこの週末に来るように頼む.. "

私はMatinのファウラーの本を読んだが、私は、私はこの問題について彼のアドバイスに同意するかわからない：

• は、定期的なコードレビューを奨励、リファクタリング作業は開発プロセスの自然な部分として奨励されています。
• あなたは開発者であり、あなたの義務の一部です。

これらの両方の方法は、あなたのマネージャーと通信する必要がなくなります。

あなたの上司に何を伝えますか？

Answer 1

リファクタリング時間を元の見積もりに含めることが重要です。あなたが商品を納品した後、あなたの上司に行って、あなたが実際にやっていないことを彼に伝えることは、行かれたことについて嘘をついています。あなたは実際にデリバブルを締め切りにしていませんでした。それは外科医が手術をした後、すべてのものを元に戻すことを確実にしていないようなものです。

元のスケジュールには、開発のすべての部分（リファクタリング、ユーザビリティリサーチ、テスト、QA、リビジョンなど）を含めることが重要です。最終的には、これはプログラマーの問題としての管理上の問題ではありません。

しかし、あなたは混乱を受け継いだとしたら、上司に説明しなければならないでしょう。しばらくの間、問題をしっかりと解決することができますが、それぞれのバンド・エイドは問題を遅らせるだけで、最終的に問題を解決するのにかかるコストをはるかに上回ります。

あなたの上司に正直で、プロジェクトが完了するまでプロジェクトが完了していないことを理解してください。

Answer 2

거짓。新技術の研究だと教えてください。その後、費用が利益を正当化しないと判断したことを伝えてください。彼はあなたが素晴らしい仕事をしたと思うでしょう。

lol @ peopleダウンモデリング/マーキング攻撃。

安価なソフトウェアから良いソフトウェアを理解していないペニーのピンチのボスなら、彼が知らないものは最終的に彼をもっと幸せにするでしょう。それが私だったら、私は会社を離れ、開発者が良いコードを書く能力を尊重するところに行くだろう。しかし、再び、これが私が上級職にいる理由です。

Answer 3

リファクタリングは常に行う必要があるため、正当化する必要はありません。 、大きな台無し/再設計が制御の下でそれを得るためにリファクタリング含むことができ、しかし、そのない「リファクタリング」は

リファクタリングは瞬間の問題である必要があります...またはあなたは何のツールをサポートしていない場合は分をクリーンアップ

。

Answer 4

マーティン・ファウラーの「リファクタリング」の答えが気に入っています。上司に、あなたが知っている最速の方法でソフトウェアを開発しようとしていることを伝えてください。ほとんどの場合、ソフトウェアを開発する最速の方法は、あなたが行くにつれてリファクタリングすることです。

あなたの上司に話すもう一つのことは、今後の改善のためのコストを削減することです。

Answer 5

ソフトウェアプロジェクトに関連するコストの80％がライフサイクルのメンテナンス段階に入っていると伝えます。将来の問題を緩和するためのリファクタリングやいくつかの例があれば、後でそのコードを維持する必要が生じたときに実質的なコストメリットが得られます。

これは、あなたが理由でリファクタリングしていて、プログラマの虚栄心がないと仮定しています。

Answer 6

これを実行して通常のプロセスにスケジュールします。リファクタリングの時間を見積もって、新しい変更を開始するか、変更を終了する（理想的）。 私は最初に新しいコード（メソッドの抽出など）を探求していますが、私は常にリファクタリングしています。

Answer 7

彼が理解できる言語で話す。

リファクタリングは設計負債を支払っています。

あなたの上司に、毎月会社のクレジットカード請求を支払う理由と、コレクションの通知があるまで支払いをしない理由について相談してください。リファクタリングは毎月の支払いをするようなものだと教えてください。

Answer 8

少ないお金今私は後で間違っていると私はリファクタリングするために行くものは何でも解決するために...

以上のお金をリファクタリングするため。

Answer 9

ロバート・グラスの最近の書籍（参考文献を参照する必要があります）の1つで、彼はよく管理されたコードのコストに関する研究を述べました。彼らが見いだしたことは、よく維持されたコードが、維持管理されていないコードより頻繁に編集されたことです。それは直感的ではないように聞こえるが、彼らが深く掘り下げたときに理由が発見された：

よく管理されたコードは、維持管理されていないコードと同じ時間フレームで追加されている。

あなたのボスのような機能はありますか？確かに、彼らは皆です。コードの保守性を向上させるほど、限られた予算でより多くの機能を提供できます。

Answer 10

時には、新しい仕事をする時があります。あなたが「完了させる」ことを欲しがっている証人がいます。あなたがそのような状況の1つにいて、私がそこにいたならば、ただ出発してください。

しかし、ええ、将来のコストなどについては他のすべてが良い考えです。私はちょうど彼らがそれがほしいと思うときほしいと思うので、ほとんどの上司が自分自身に横たわっていると思います、そして、彼らは将来何が起こるかを見ることができません。

あなたの上司と幸運を祈る。うんざり彼または彼女は合理的です。

Answer 11

私はちょうどあなたと同期してより多くの場所thatsで新しい仕事を得るために行く。

Answer 12

私はあなたの上司に言わせずに作業を開始するべきだと思います。これは本当に私がどのようにして最善の仕事をしたかです。私は上司に私が何をしているのかを伝えず、時間があれば悪い/遺産のコードをゆっくりと置き換えるだけです。

これは複数の機会に私のお尻を救いました。

Answer 13

あなたの上司がコードをリファクタリングまたはクリーンアップする必要性を理解していない場合、彼はエンジニアリングマネージャであるために十分なエンジニアリング知識を持っているか疑問に思う必要があります。

Answer 14

リファクタリングの時間を与える上司を見つけるのはまれです...あなたが進むにつれてそれをやってください。

Answer 15

私の意見では、リファクタリングのための最も簡単なケースは、過度に複雑なコードを修正することです。問題のソースコードのMcCabe循環的複雑さを測定します（ソースモニタは、このような問題の優れたツールです）。サイクロマティック複雑度の高いソースコードには、強い相関の欠点と不具合があります。簡単な言葉でこれが意味することは、複雑なコードは修正するのが難しく、修正が悪い可能性が高いということです。これがマネージャーにとって意味することは、製品の品質が悪化する可能性が高く、バグの修正が難しく、プロジェクトのスケジュールが最終的に悪化することです。しかし、複雑さのリファクタリングでは、コードの透明性を向上させ、不明瞭な/困難なバグの可能性を減らし、メンテナンスを容易にしています（メンテナンスプログラマーはこれによりメンテナンス範囲を拡大できます）。

さらに、メンテナンスサイクルで死んでいる製品でない場合は、プロジェクトに新しい要件が追加されたときにアプリケーションの拡張が容易になります。

Answer 16

上司は、技術的な意思決定（リファクタリングを含む）を行うために開発者を信頼しなければなりません。

信頼を確立するか、ボスを交換するか、devを置き換えてください。

Answer 17

別の良いアナロジーは、きちんとした建築現場の維持です。ここで唯一のキャッチは、プログラマーが建設労働者を代表していないことであり、マネージャーは監督を代表していないということです。そうであれば、有能で良心的な建設労働者が自分たちの仕事場で良い順序を維持する責任があるので、彼は「最初に正しいことをする」というカウンターを適用します。

本当にコードそのものは労働者を表し、開発プロセスは監督です。混乱は、お互いの周りのビジネスについて起こっている様々な取引によって生成されます（つまり、各機能はうまく機能しますが、それらの間の縫い目は混乱します）、しっかりと手を携えて監督が掃除します。障害が起こっている場所に目を留め、それを浄化するために行動する（すなわち、リファクタリングを要求するソフトウェアプロセス）。

Answer 18

私が最近行ったことは、コードがより良い順序と構造を持っているため、新しい機能を迅速に開発し、新しいバグの確率を減らすために、リファクトプロセスが役立つことをビジネスカウンターパートに説明することです。これまで以上に簡単にコードを検査できるため、速度を向上させることができます。

ビジネスマンがそれを得たら、彼らが賢いとすれば、彼らはあなたに絶え間ない再工場プロセスを勧めます。

建物のメタファーで説明できます。もしあなたがリファクタリングをしなければ、あなたは悪いコアを持つ馬鹿らしい建物で終わります。パイプ、窓、ドアに問題があります。