私たちのチームの多くの開発者はリファクタリングを避けています。この状況についての議論は、以下の理由を明らかにしました。
多くの人がリファクタリングしない理由
既存の機能を壊すのが怖い
時間のかかる：リファクタリングするコードが変更された場合、メインブランチから（複数回）マージするのは面倒になります
タスクの期限に間に合わないリスクがあります
同時に、リファクタリングは開発プロセスのほぼ不可欠な部分です。その必要性は、次の前提条件に関連しています。
初期要件が完全になることはほとんどなく、開発は特定の仮定に従って実行されます。その一部は後で不正確または不正確であることが判明します。
多くの場合、それ以上のサポートを考慮せずに、今ここで機能させるためにすばやく編集する必要があります
リファクタリングが必要な場合（必要）
コードの構造を変更する理由は次のとおりです。
重複コード
コードが重複している理由はいくつかありますが、多くの場合、それを取り除く必要があります
普遍化
コードを理解しやすくし、運用上の問題を減らすために、多くの場合、類似したコードを組み合わせた抽象化を作成できます。この抽象化には少なくとも3つのプロトタイプを用意することが重要です。そうしないと、正確でない可能性があります。
, GooglePay. , ApplePay SamsungPay . VendorPay
,
/
, 50 500 ,
: , , .
, . , , , , . , () , .
?
, , :
(unit )
-
, -
feature- master' .
, , , . , , , . , , .
- (- + ) , , ( master'), - - .
, master rebase - master.
このアプローチにはある程度のオーバーヘッドが発生しますが、リファクタリングの主な問題が軽減されます。
リファクタリングのレビューとマージは、基本的に機能の変更をもたらさないため、またはこれらの機能の変更が小さなプルリクエストで明確に表示されるため、それほど怖いものではありません。
変更はほぼ即座にメインブランチにマージされるため、他の開発者の変更をサポートする必要はありません。
締め切りが迫った場合は、次の2〜3日周期でリファクタリングを停止できます。