【エンジニアあるある】コードレビューで指摘された箇所、直すより書き直した方が早い
こんばんは！IT業界で働くアライグマです！
エンジニアにとって、コードレビューは欠かせないプロセスです。品質向上やバグの防止、チーム全体のコードの統一感を保つために重要な工程ですが、指摘を受けた修正をしているうちに「これ、直すより書き直した方が早いのでは？」と感じたことがあるエンジニアは多いのではないでしょうか。
「ちょっとした修正のはずが、次から次へと問題が出てくる…」「レビューの指摘に対応したら、結局全体の構造を見直すことになった…」といった経験は、エンジニアなら一度はあるはずです。
本記事では、コードレビューで「書き直した方が早い」と感じるケースと、その対処法について解説します。
コードレビューで「直すより書き直した方が早い」と感じる瞬間
指摘が多すぎて、どこを直せばいいのかわからない
レビューで受けた指摘が多すぎると、どこから手をつければいいのかわからなくなり、修正よりもゼロから書き直した方がシンプルに思えることがあります。
特に、以下のようなケースでは、修正よりも書き直した方が効率的な場合が多いです。
- 変数名の変更、ロジックの簡略化、処理の分割など、多岐にわたる指摘がある
- 修正を進めるうちに、別の修正が必要になり、収拾がつかなくなる
- もともとコードが複雑で、手を加えることでさらに読みにくくなる
設計の問題が根本にある
コードの構造自体に問題がある場合、局所的な修正ではなく、根本から見直した方が結果的に良いコードになることが多いです。
例えば、以下のような状況です。
- そもそもメソッドの分割が適切でなく、可読性が低い
- クラスや関数の責務が曖昧で、修正を加えるたびに影響範囲が広がる
- 依存関係が複雑で、変更すると他の部分に影響が出る
このような場合、無理に修正を重ねると、かえってコードの品質が下がる可能性があります。
短期間で実装したコードの後始末
納期が迫っていたり、プロトタイプの段階でとりあえず書いたコードは、後で見返すと「なんでこんな書き方をしたんだろう…？」と思うことがあります。
このようなコードは、修正するよりも最初から書き直した方がシンプルにまとまることが多いです。
「書き直した方が早い」と感じたときの対処法
修正と書き直し、どちらが適切か判断する
すべてのケースで書き直すのが正解とは限りません。修正で対応できる範囲なのか、それとも根本的に作り直した方が良いのかを冷静に判断することが重要です。
判断基準として、以下の点を考慮すると良いでしょう。
| 項目 | 修正で対応すべき場合 | 書き直した方が良い場合 |
|---|---|---|
| 指摘の範囲 | 限られた部分のみ | コード全体に影響する |
| 修正の影響範囲 | 既存の動作に影響が少ない | 他の部分への影響が大きい |
| 可読性の向上 | 修正後も可読性が維持できる | 修正すると可読性が低下する |
| 時間と工数 | 修正の方が短時間で済む | 書き直した方が効率的 |
書き直す場合のポイント
もし「書き直した方が良い」と判断した場合、ただ一から書き直すのではなく、以下のポイントを意識すると効率的に進められます。
- コードの目的を整理し、無駄な処理を省く
- テストを活用し、修正前と同じ動作を保証する
- 小さな単位で書き直し、影響範囲を最小限に抑える
- 必要であれば、設計を見直し、より良いアプローチを採用する
チームと相談する
コードを書き直すかどうかは、自分だけで判断せず、チームメンバーと相談することも大切です。
- レビューをした人に、「書き直した方がシンプルになりそう」と提案する
- チームのコーディング規約や方針に沿った方法を選ぶ
- 時間的な制約を考慮し、スケジュールに影響がないか確認する
特に、プロジェクト全体の方針や他のコードとの整合性を考えると、個人の判断だけで大幅な書き直しをするのはリスクがあるため、チームの合意を得ることが重要です。
まとめ：書き直すかどうかの判断が重要
コードレビューで「直すより書き直した方が早い」と感じることは、エンジニアなら誰もが経験することです。しかし、すべてのケースで書き直すのが正解とは限らず、状況に応じて適切な対応を取ることが重要です。
この記事のポイント
- 指摘が多すぎる場合や設計に問題がある場合は、書き直した方が効率的なこともある
- 修正と書き直しのどちらが適切か、影響範囲や工数を考慮して判断する
- 書き直す場合は、無駄を省き、テストを活用しながら進める
- 個人の判断ではなく、チームと相談しながら進めるのがベスト
コードレビューは成長のチャンスでもあります。書き直すべきかどうかを冷静に判断し、チームと協力しながらより良いコードを目指しましょう。