9

私の現在の職場では、次世代のフレームワークとして宣伝されている、本当に衝撃的なコードがいくつかあります。

つまり、この意見を持っているのは 1 人だけで、そのほとんどを書いたのはその人です。部門の残りの部分は、コード化が不十分で、デバッグが面倒で、一般的に少し面倒だという印象を受けます。

それを書いた人は経営陣にかなり影響力のある立場にあるので、彼らはキャンプのその側にいます.

経営陣への (本当の) 懸念を強調しましたが、明らかに、経営陣は収益に直接貢献しないプロジェクトにより多くの時間を費やすことを望んでいません。

このフレームワークにはいくつかのアプリケーションがデプロイされているため、リファクタリングにはそれらのアプリケーションを含める必要があります。

全体が非常に絡み合っているため、特定のクラスの実装を切り取ってそのように書き直すことはできないため、コア API への単純な変更でさえ大規模なプロジェクトを意味します。

ただし、3 年間のライブ展開があり、多くのバグ修正、コーナー ケース、および境界条件に対応しています。

部分的に書き直して、それがいくつかの大規模なプロジェクトになることを考慮して、時間の経過とともにリファクタリングを試みますか、それを形にするのにさらに3年かかる可能性がありますか、それとも既存の要件の上に特定の要件を書き直すだけですかフレームワーク？

4

6 に答える 6

6

何かを書き直すことは、ほとんどの場合、悪い考えです。何ヶ月もかけて作業し、書き終わるまでは何も表示されません。これは、第 2 システム効果の餌食にならず、実際に終了することを前提としています。

リファクタリングはほぼ間違いなく正しい答えです。PHP のリファクタリングの経験がない (C++ と C# を使用している) ため、具体的なアドバイスを提供することはできません。ベイビーステップを進めていく必要があります。

  • まず、最も気分を害するコードの部分を特定します。私にとって、C++ では、これはグローバル変数です。
  • 次に、小さなリファクタリングを行い、一度に 1 つの問題を取り除きます。そのコードの古いクライアントを壊さないようにするために、ファサードを配置する必要があるかもしれません。古いコードに新しいファサードを配置することも、新しいコードに古いファサードを配置することもできます。
  • 3 番目に、そして最も重要なことですが、本当に自信がある場合を除き、リファクタリングしようとしているコードの単体テストのセットがしっかりしていることを確認してください。

ただし、コードを書き直すためにすべてを削除しないでください。徐々にリファクタリングします。少し遅くなりますが、それでも価値を提供し続けます。

経営陣に技術的負債を説明するのに役立つこの記事を参照してください。また、彼らが気にしないように見える理由も説明します。

于 2009-02-23T10:12:48.203 に答える
1

リライトの利点は、分析フェーズですべての新しいものを考慮に入れて、現在のニーズにより適合したモデルを作成できることです。一方、コーディングが不適切で、設計が不適切でない場合は、完全な書き換えを行っても意味がありません。コードをサニタイズ/リファクタリングするだけです。

于 2009-02-23T11:00:52.643 に答える
0

小さなレベルでは、はい: 関数の新しいバージョンを提供し、古いものだけでなく新しいものでも動作することを確認し、古いものを削除します。多くの場合、関数自体をリファクタリングするよりも十分に高速です。しかし、そのレベルでは、リファクタリングです:)

リライトの戦略的コストは、ほぼ常にリファクタリングを上回ります。

お届けできません。新しいバージョンを開発している間は、古いバージョンを維持する必要があります。財政が書き直しプロジェクトを中止しなければならないと言うなら、あなたは何も達成していません - あなたの作業中のコードベースはまるで何もしなかったかのように悪い形になっています. おそらくさらに悪いのは、「とにかく書き換えが終わったら捨てる」という理由で、すべての変更が取り残されていたからです。

はい、書き換えの方が安価なシナリオを構築できます。

  • 元のコード ベースは非常にスパゲッティであるため、ローカルで変更を加えると一見無関係な機能が壊れます。
  • あなたは本当に素晴らしい新しいチームを持っています。古い人たちよりもはるかに優れていますが、彼らは既存のコードベースの経験がなく、既存のコードベースは混乱しているか、彼らが知らない言語であるか、またはそのようなものです。

それでも、コードが悪いのには理由があり、それが常にコーダーにあるとは限りません。原因を特定して変更しないと、書き直しは歴史を繰り返す練習になります。

于 2009-02-23T11:23:02.433 に答える
0

書き換えは非常に危険です。十分にデバッグされた古いコードを、まだデバッグされていない新しいコードに置き換えます。これにより、多くのバグが発生し、それらを修正する必要があります。徐々にリファクタリングすることをお勧めします。まず、ある部分が何のためにあるのかを非常に詳細に理解してから、それをリファクタリングします。このようにして、置き換えるコードを減らし、新しいバグが多すぎるリスクを軽減します。

于 2009-02-23T11:24:38.200 に答える
0

それは本当に難しい決断です...

ここで私が目にする問題は、フレームワークが長い間使用され、修正されているため、多くの知識が必要であり、実行中のプロジェクトの品質が明らかに許容できることです。したがって、知っているすべての要件を使用してゼロから書き直すと、すでに機能していたことを忘れてしまいます (顧客や上司に説明するのは難しいものです ;))

コード内の接続を本当に知っている人は1人しかいないため、コードを変更したくないため、リファクタリングも難しい作業です...

次の 3 つのオプションがあります。

  • それと一緒に暮らす
  • 彼だけでなく誰もがそれを使用/維持できるようにリファクタリングが必要であることをその人に納得させる
  • 書き直しが必要であることを経営陣に納得させますが、これは書き直し/リファクタリングに反対している人を本当に動揺させます

いずれにせよ、これは誰にとっても悪い状況です...時間が経つにつれて、フレームワークの責任者が自分で対処しなければならなくなり、おそらく手遅れになるからです。

于 2009-02-23T10:15:57.587 に答える
0

すでに述べたことに加えて、経営陣の賛同を得るようにしてください。リファクタリングを行うと、最終的にはメリットがあります。新しい機能をプログラミングするための工数は、時間の経過とともに減少するのではなく減少するため、給与のコストが削減され、サーバーのコストも削減される可能性があります。リファクタリングがなぜ価値があり、仕事をより楽しくするのかを経営陣の誰も理解していない場合、あなたは適切な場所で働いていますか?

于 2009-02-23T15:26:32.957 に答える