数日前、私は古いコードの主な特徴に関する記事を書きました 。 しかし、古いコード環境での生活方法に関する具体的な実践的な推奨事項は少なすぎました。
今日は、途方もない量のレガシーを備えたシステムを開発する際に耳にする最も一般的な質問の1つに答えようとし、ビジネスにリファクタリングする方法についての私の見解を共有します。
この記事では、基本的にビジネスとのやり取りの説明に限定し、技術的な詳細（リファクタリングの実行方法）には触れません。 この投稿は、個人の成功についてのみ書かれており、さまざまなチームやさまざまな企業でのリファクタリングの「販売」や「購入」の経験ではありません。
背景
つまり、より具体的には、数年（10年も）稼働しており、会社の収益の大部分を占める主力製品があると想像してみましょう。
通常、およそ次の製品機能が観察されます。
- 「プラスチックアーキテクチャ」 -製品の寿命にわたって、急いで追加された多数の追加機能を取得しました。 これは、システムのロジックがコード全体に均一に分散しているという事実につながりました。一部の場所には、元のアイデアをバイパスして「奇妙に」できる「ハッキング」があります。
- 単体テストの欠如 -現在のロジックは、テストによって完全にはカバーされていません。 「システムの寿命の3年目に単体テストを検討したため、どのように、どこで構築するかはまだ明確ではなく、テストの時間も十分ではありませんでした。」
- 専門家の不足 -製品を最初に書いた人々は、大きなマネージャーの地位にあるか、辞めるか、長年にわたってすべてが内部にどのように配置されているかをすでに忘れていました。
さまざまな企業に膨大な数の製品が存在する典型的な状況を説明しました。 さらに、これは典型的なことですが、開発者のレベルは非常に高くなる可能性があります。 毎年、コードがますます混乱するようになっているだけです。
遅かれ早かれ、そのようなコードをリファクタリングする必要があることは明らかです。 しかし、製品タスクの絶え間ないフローでこのタスクの時間を取得する方法は？ これについては、以下で説明します。
それとも、すべてをゼロから書き直しますか？
あなたはそれについて夢を見ることができますが、これをだれにも納得させることができる可能性はほとんどありません。 さらに、管理者に古いコードを捨ててすべてを書き直すように説得することができた場合、このマニュアル自体がリスクを評価する方法を知らないか、会社が非常に豊かで長い時間（時には数年）を過ごすことができることを示しています現在の利益をもたらさないプログラマーの並行「戦略的」チームを含む。
一般的に、 Joel Spolskyを読んでください。 彼はそのケースを言います（公式バージョンによると、Netscapeは無料のIEでまだ市場からノックアウトされており、アップデートの遅れではありません）。
そしてもう1つ、「ゼロからすべてを書き換える」プロジェクトには何年もかかる可能性があることを理解する必要がありますが、現時点では古いコードのサポートに対処する必要があります。 そのため、どのような場合でも以下に書かれていることが重要です。
それでは、リファクタリングがまだ必要であることをどのようにビジネスに納得させることができますか？
ヒント1.リファクタリングをビジネスに販売しないでください！
私が意味することを理解するために、ファウラーの古典的な定義を思い出さなければなりません： リファクタリングは、ソフトウェアの内部構造の変更であり、その動作の理解を促進し、観察された動作に影響を与えずに変更を簡素化することを目的としています 。
2つの点に注目しましょう。
- リファクタリングの目標は、コードの理解と変更を単純化することです-純粋に技術的であり、ビジネスではありません
- 動作は変更されません。つまり、ビジネスの結果は目立ちません。
つまり、リファクタリングが成功しても、変更はありません。 なし！ 成功しない場合、作業コードにエラーと動作の違いがあります。 つまり、「10個のバグを修正し、非常に優れたトリックを実装しました」とは言えません。 「コードがより美しくなり、アーキテクチャがよりシンプルになり、理解しやすくなりました。 まあ、はい、そしていくつかのバグが現れました...しかし、我々はそれらを修正します！」
ここで、ビジネスの場にいる自分を想像してください。 高価な専門家のチームは、ユーザーとお金をもたらすわかりやすい機能を作成する代わりに、「美容指導」に多くの時間を費やしました。 これは、自動車サービスに自動車を提供し、変更せずに、500ドルの請求書に「サスペンションを通過し、ラックを3倍速く変更できるようになりました」というメモを付けたのと同じです。 おそらく最初にタップするものになるでしょうが、それは一ヶ月で通過するはずです。 うまくいかない場合は、お手頃な料金で修正します。」 私はあなたについて知りませんが、私はそれがあまり好きではありません。
一般に、最初のルールはこれです：彼らは買い手にとって興味のあるものまたはあなたが興味を持っているものだけを買います。 コード自体の変更はビジネスにとって価値がなく、開発者以外の誰にとっても興味の対象ではありません 。 したがって、あなたが犯す可能性のある主な間違いは、「コードが不良で明確なものがないため、リファクタリングを行う必要がある」と言うことです。
次に何を言いますか？
ヒント2.ビジネスチャンスと問題解決を売り込む
悪いコードの問題は、それを使用する開発者の苦痛だけでなく、ビジネス上の特定の問題にもつながることを私たち一人一人が直感的に理解していると思います。 この理解を形式化しようとすると、2つの最も深刻な問題に直面します。
まず、これはシステムの不安定な動作です -奇妙なバグ、パフォーマンスの問題、予測できない動作、データ損失（これはおそらく最悪です）などです。 これは、モバイルアプリケーションの場合、ユーザーの不満、拒否、悪い評価、低い評価につながります。 一般的に、利益に最も直接的な影響を及ぼします。
第二に、 変更を行う非常に長いプロセス 。 つまり、機能がコードに表示される前に考案された瞬間から、多くの時間が経過します。 その結果、これにより開発プロセスが長くなり、製品チームにとって苦痛になるだけでなく、多くの機能をすばやく表示したり、多数のさまざまなオプションを試したり、変更をすばやくプロトタイプ化したり、ユーザーにロールアウトして反応を確認したりすることもできません。 さらに、システム全体をコグで完全にソートしないと、変更したいことの一部がまったく不可能な場合があります（実際、これは既にリファクタリングと呼ばれるものに近い）。
したがって、これらの2つの問題の少なくとも1つが明らかになった時点で、リファクタリングのアイデアでビジネスを開始する必要があります。 ただし、まだ問題がなく、これらの領域のいずれかで潜在的な危険性が見られる場合は、事前に取引を開始できます。 しかし、それからもっと説得力のある議論を準備する必要があります。
結果として、 リファクタリングの目標は、コードの構造を改善するのではなく、システムを安定させるか、ユーザーへの機能の提供を加速することを述べる必要があります 。 したがって、リファクタリングの結果としてバグが減少せず、単純な機能がそれぞれ2か月間追加されて追加された場合、時間が無駄になり、ビジネスの観点からは、主なタスクに対処できませんでした。
ヒント3.ビジネス開発を見てみましょう
すでに上で述べたように、議論の最初のルールは、対話者の価値を理解することです。 この場合、ビジネス側からリファクタリングを見ることは理にかなっています。
ビジネスの観点から見ると、どの機能にも開発コストと実装利益があります。 コストはいくつかの部分から成ります。 まず、これはチームが機能の開発に費やすお金です。 これには、開発者の給与、税金、オフィス賃料、機器、電気などが含まれます。 あまり明らかではありませんが、利益の損失に関連するコストも重要です。現在の機能の開発中、お金をもたらさず 、新しいユーザーを引き付けない他の機能は製品に表示されません 。
明らかに、機能の重要性は、それからの計画利益とその実装コストを比較することで簡単に推定できます。 この観点から、リファクタリングは最も純粋な形への投資です。 リソースは無駄になりますが、結果として新しいユーザーも新しい機能も製品に表示されません。
そしてあなたの主な仕事は、リファクタリングへの投資が合理的な時間で利益をもたらす理由をビジネスに示すことです。
この利点をどのように示しますか？
ヒント4.数字で操作する
リファクタリングに関する決定を下すには、ビジネスでは、まず、それを実行するための人件費の見積もりを取得する必要があります（定期的にこれを行う可能性が高い）。次に、結果から利益を理解する必要があります。 そして、これは難しい瞬間の一つです。 「 多くのバグがある」または「リファクタリングすれば、さらに変更を加えるときに時間を節約できる」と言っても、これらの言葉はビジネスにとって意味がありません。
通常の数値的正当化を実現するには、管理作業を行う必要があります。 たとえば、現在の実装では妥当な時間内に修正できないバグ、およびリファクタリング後に修正されるすべてのバグを1つのリストに収集します。 より複雑で骨の折れる作業は、各変更にかかる時間を追跡し、リファクタリング後にシステムでこの変更にかかる時間を各桁に追加することです。 これは桁違いに複雑ですが、結果はより明確になります。 というのは、「先月の開発でX工数を節約でき、将来同じくらい節約できる変更」は、「コードを順番に並べる」必要性よりも理解しやすく、ビジネスに納得させるからです。
別の微妙な点があります。 評価する際の主なことは、装飾することではなく、実際よりも明るい未来を作ることではなく、リファクタリングのコストを過小評価しないことです。 結局のところ、リファクタリングのための切望された「良い」が受け取られた後、あなたはまさに明るい未来を約束し、予算を費やした人になります...
...そして結果として、それはすべてあなた次第です。 リファクタリングが古いバグをキャッチし、開発をスピードアップし、コードをよりわかりやすく理解しやすくし、ユーザーをより幸せにするのに役立つと確信しているなら、先に進んでください。
そして幸運を！