なぜクリーンでリファクタリングされたコードを書くのですか？
いくつかのJava=ベースのプロジェクトでの作業の経験から、私は「ダーティ」と呼ぶ大量のコードを見てきました。型破りなクラス/メソッド/フィールドの命名、例外の誤った処理方法、不必要に重いループや再帰など。しかし、コードは意図した結果を提供します。
汚いコードを見るのは嫌いですが、コードをクリーンアップするのに時間がかかり、最終的には「それは価値がありますか？望ましい結果が得られるので、クリーンアップのポイントは何ですか？」という疑問が生じます。
チームプロジェクトでは、明確なコードをリファクタリングしてチェックするために特別に誰かが必要ですか？または、「汚い」コードが意図した結果を提供できない、または顧客を不満にさせる状況はありますか？
WHYが意味するのは技術的な理由ではなく、動機について尋ねています。**技術的な観点からクリーンなコードを記述する必要がある理由は誰もが知っています。しかし、大学で悪いコードを書いたら、悪いマークが付くと想像してみてください。あなたの産業環境で、あなたとあなたのチームがクリーンなコードを書く動機は何ですか？そして、あなたやチームが悪いコードを書くのをやめさせるものは何ですか？
クラス内にメソッドを記述して必要な情報を取得するのはとても簡単で、周りを見回したり、同様のメソッドがあるかどうかを確認したりする必要はありません。結果？ 5000行以上のコードで、ほとんど同じようなタスクを実行するいくつかのメソッドがあります。
それは価値があり、それはチーム全体で行われるべきです。 「悪臭がしたら、変更してください」は、赤ちゃんとコードで機能します（ありがとう、ケントベック）。
一部の人は、少しの短期的なプロジェクトでは、やる価値がないと言っています。同意しません。そもそも、プロジェクトがどれだけ短期になるかはめったにわかりませんが、2番目は、臭いがしたときに変更します。それが悪臭を放つ場合、それは最初に臭いを書いたためであり、チームはその一般的なコーディングスキルに取り組み、リファクタリングはそのための優れたトレーニングです。その場合-明らかに短期的なプロジェクトではありません。悪臭を放つ時間があれば、時間をかけて変更してください。
リファクタリング-コードを悪臭から守ることは、チームの指定された1人の責任ではなく、悪臭を出した人の責任でもありません。それはあなたの責任であり、チームの全員の責任です。 それが悪臭になったら、それを変更してください。
質問はなぜきれいな食べ物を食べるをすべきなのかと似ています。ネットをgrepできる簡単なポイント：
- 保守性
- 読みやすさ
- 後で簡単に拡張できます。
- 開発者の性格を示します:)
しかし"それは価値がある"質問は少しトリッキーです。これを決定する際には、次のことを考慮する必要があります。
- このプロジェクトが実行されるまでの期間
- Mmoreの新機能が長期的にどのように追加されることが期待されるか。
- 危険因子;製品の場合、変更するのはどれほど危険か（怖い）
- 「無駄にする」（？）ための十分なリソースがありますか？.
私は生徒たちに、これがコードが記述されることを期待する順序であることを伝えます（私が最も気にかけていること）。
- ドキュメンテーション-何をすべきかわからない場合、それが適切に行われているかどうかはどうすればわかりますか？
- 書式設定と規則-読み込めない場合、何をしようとしているのかをどのようにして知ることができますか？必要があって混乱した場合、どうすれば修正できますか？
- 正解-間違った結果を生み出すプログラムがあることに意味がない
- 速い（遠い四分の一）-ここで言うことはあまりない
簡単に言えば、コードは、読み取られるよりもはるかに少なく書かれています。規則（スタイル）に従わず、迅速でダーティーなコードを記述すると、読みにくくなります。 SInce読み取りは、コードが明確である場合、全体的な時間を大幅に節約する主要なアクティビティです。
ここでは実際にいくつかの異なる質問をしています。
なぜクリーンでリファクタリングされたコードを書くのですか？
結果の保守と検証が容易になるため、これを行う必要があります。誰もあなたのコードが大規模な時間のシンクなしでどのように機能するかを理解できる場合、彼らはあなたのWordをそれのためにしかとることができません。重大な問題が見つかったときに利用できない場合は、修正された場合と同様に悪化する可能性があります。
mainabilityabilityを目指すことは、ソフトウェアエンジニアリングの戒めの1つでした。
それは望ましい結果を与えているので、クリーニングのポイントは何ですか？
プロジェクトの予想タイムフレームによっては、そうでない場合があります。プロジェクトが非常に明確な時間枠で6か月しか続かない場合は、恐らく物事を混乱させずに済むでしょう。顧客は通常、内部で何が行われているのかを気にせず、ビープ音を鳴らして適切なタイミングでツイートすることを望んでいます。
ただし、長期的には、保守性が大きな要素になります。平均して、6か月を超える期間にいる場合は、主要なスタッフを失うことが予想され、計画する必要があります。
チームプロジェクトでは、明確なコードをリファクタリングしてチェックするために特別に誰かが必要ですか？
いいえ、そうは思いません。コードを「リファクタリング」する人は、最初にコードを書いた人でなければなりません。そうしないと、誤解が生じます。データベースの正規化のルールと同様に、少し時間をかけてリファクタリングを行う場合（コードを作成するときに、そうする機会は明らかであるべきです）、だらしのないコードがたくさんあるはずはありません。君は。
確かにコードが完成した後はそのままにしないでください。開発者の観点から見ると、仕事が完了し、機能が作成され、チケットを閉じることができます。
内部品質を低下させると、速度が低下します。
内部品質を低下させると、将来的に望ましい結果が得られるまでに時間がかかり、リスクが増大します。
最初に適切なものを慎重に選択した場合-最初に最大の価値を得る-次に、私の意見では、正しいことをすることはほとんど常に価値があります。
また、Martin Fowlerの優れた記事もご覧ください。 http://martinfowler.com/bliki/TradableQualityHypothesis.html
（言い換えると、内部品質が取引可能であると見なされるとすぐに、開発者、管理者、およびその顧客はすでに失っています。）
汚いコードは、それを扱う必要があるときに傷つきます。これに取り組むことは、コードに関連するバグを修正するか、ダーティーコードの周りに機能を追加することを意味します。コードを入力して任意にリファクタリングすることに大きな価値があるとは思いません。バグを修正したり機能を追加したりするには、コードに触れたときにコードをリファクタリングする必要があります。一般的に、私は クリーンコードブック スカウトの発言に関連するアイデアが大好きです。キャンプを見つけた方法よりもきれいにしてください！
これを実行すると、全体的なクリーン度（および品質）が時間の経過とともに改善され、現在動作しているコードを（クリーン度以外の理由で）変更するリスクが最小限に抑えられます。
私は、コードがクリーンであることを確認するための事後のレビューがうまくいくとは思いませんし、リファクタリングのみを行う人がいるとうまくいきません。開発者として、私たちはみんな自分の食べ物を食べるべきだと思います。だから私たちはおいしい料理を作る責任があります。
誰かが腐ったリンゴを持ち寄りに持ち続けた場合、残りは彼/彼女を変えたり、彼/彼女を行ったりする義務があります...誰も腐ったリンゴを食べたくありません。私たちは皆、素晴らしい料理を鍋運にもたらすべきです。
誰もがすでに質問によく答えています。しかし、それが価値があるかどうかに関する私にとっての決定ポイントは、アプリが時間とともにさらに変化するかどうかに大きく依存します。他の皆が言ったように、それが機能し、変更する必要がない場合は、より優先度の高いものに進みます。しかし、変更を続ける必要がある場合は、クリーンさと効率のためにリファクタリングしないと、将来問題が発生します。
もともと書かれたときは小さくて扱いやすかったので、私は本当に腐ったアプリに取り組みました。何年にもわたる追加機能やハッキング、そしてずさんな修正が追加され続けているため、チームのアナリストは一度コメントしました。「アプリで今最も難しいと思うのは、変更にかかる時間です。」新しい変更の影響分析を行うことでも、コストがかかる可能性があります。
ただし、質問の答えは、特に動機の部分を考える場合、質問する人によって異なります。無料の残業時間で費用が支払われる内部ITアプリの場合、開発者は内部を改善したいと考えていますが、マネージャーの変更に関心のあるマネージャーはほとんどいません。市場投入までの時間内に進化の速度が重要であるショップの場合、しっかりと構築されたアプリの変更速度が新機能のハッキング速度を超えていると経営陣が考えている場合、品質は戦略的な利点をもたらす可能性があります。そして、悲しいことに、一部の真のソフトウェアショップでは、ハッキングの方が速いと多くのマネージャーが判断しているように感じます。おそらくそうですが、繰り返しますが、進行中の痛みは通常、開発者によって感じられ、組織内の他の人には感じられません。
プロジェクト次第だと思います。 1週間の間に1人で行う固定価格プロジェクトの場合は、必要に応じてコードを記述します。
しかし、チームが大きくプロジェクトの開発に時間がかかる場合は、開発中にチームメンバー間の何らかのリファクタリングと協力が間違いなく必要になります。これらは、より良いデザインとよりクリーンなコードを楽しむために開始するポイントです。
私の意見：
場合によります！ -コードが一回限りの火のスタイルでの1回限りの開発を意味している場合は、忘れてしまいます...と私は言うでしょう...いいえ、それをリファクタリングする価値はありません。 -コードを長く使用して再利用することを意図している場合は、コードを変更または拡張する必要があるか、コードのダーティな部分を使用すると同時に、ユニットテストを記述して段階的にリファクタリングします。
作業コードを壊すリスクと、クリーンアップによって発生するメンテナンスおよびパフォーマンスコストの面での利点との適切なバランスを見つける必要があります。
あなたのコードは他の開発者によって使用されます。さらに、あなたは将来あなたのコードを使うでしょう。したがって、最初にクリーンなコードを作成することにある程度の時間を費やすと、他の人（そしてあなた）は、コードのデバッグまたは変更中に、さらに多くの時間を節約できます。
他の回答で指摘された良い点を少し違う方法で表現します。
それは望ましい結果を与えているので、クリーニングのポイントは何ですか？
つまり、「壊れていない場合は修正しないでください」です。どちらが正しいように聞こえますが、それは考慮に入れませんコードはいくつかの異なる方法で破壊される可能性があります-それは可能性があります：
- 機能的に壊れている（最も明白）：本来の動作をしません。
- 不可解：読んで理解するのが難しいため、何をすべきか仮定さえ明確ではありません。
- テスト不可能：単体テストするのは困難または不可能です。
- nmaintainable：保守および拡張が困難です。これは通常、読み取りやユニットテストが困難であることによる密接な結果です。
これらのいずれも、長期的にプロジェクトを妨害または停止する可能性があります。
ビジネスの観点からは、1回限りのダーティーコードが機能するかどうかについては、大きな異論はありません。ビジネスのためにお金を稼ぐくだらないソフトウェアがたくさんあります。
しかし、良い習慣やプログラミングスキルはどこからともなく生まれてくるものであり、開発する必要があります。良いコードを書くことは良いコードを書くための素晴らしい練習です。より良いコード開発者が書くほど、それはより簡単になります。良いコードを書くのはごく自然なことであり、汚れたコードを書くことより難しくも遅くもありません。これは単なる経験+良い習慣であり、この経験と習慣は、汚れたコードを書くことや本を読むだけでは得られません。だから、汚いコードを書かないでください、そしてあなたのチームにそれをさせないでください、そしてあなたはしばらくしてより良いチームでより良い開発者になるでしょう。ビジネスタスクと期限が過ぎても、スキルは維持されます。
この記事 のFizzBuzzの例の意味を考慮してください。 2つのバージョンとそれらの変更により、それぞれ同じ出力が得られますが、特に要件が常に変化する環境では、どれを維持しますか？
私のアドバイス：厳しいスケジューリング制約下にある場合、コードが壊れていなければそれを修正しないでください。スケジュールが緩くなり、締め切りが迫っていない場合は、時間をかけて最も問題のあるコードまたはモジュール式のコードを修正してください。ただし、常にシステムアーキテクチャ全体のガイドラインの範囲内で行ってください。
「クリーン」または「ニート」にするためのコードの書き直しは、軽く行うべきではありません。最初にコードを実際に理解する時間がなければ、間違いを犯しがちですが、何年も信頼できるシステムの一部を不思議な方法で失敗させてしまう可能性があります。
私は自分でそのようなタスクに取り組んでいますが、手に負えなくなっていました（神クラスのアンチパターン、誰でも、大規模なコピー/ペーストプログラミングなど）。そこでは時間がありましたが、すべてを実行する自信がないため、本当にやりたかったことのほんの一部しか行いませんでした。高品質のコードを実際に作成するために必要な変更は、大きすぎて効果的になります。このプロジェクトの範囲外の書き直しを意味します（私がやったことは、主にコードを少し読みやすくすることで、プロジェクトに向けた変更を行うために必要な場所を見つけ、それらの変更を分散させるのではなく一元化することですいたるところにあります）。そして、そのような限定された変更（既存の9500行クラスを8100行に減らす場合のように、実際のリファクタリングはそれを数十の他のクラスに分割し、おそらくiBatisのような完全なデータベースアクセスフレームワークを導入する）でさえ、それらに付随するリスクがありますアプリケーション全体を完全に再テストする必要があるため、変更によって問題が発生する可能性があります。私がやったのは、システムの機能（技術的な実装ではなく）に加えた非常に小さな変更の影響により、完全な再テストが既に要求されていたためです。
主な動機は2つあります。
保守性
コードを維持する必要がある人は、あなたがどこに住んでいるかを知っているサイコパスかもしれません。またはさらに悪い、あなたはそれを維持しているかもしれません、そしてそれまでに、あなたはそれが内部的にどのように構造化されているかについてすべてを忘れているでしょう。
デバッグが容易
これにより、機能を追加する必要がある場合に基盤を築くことができ、バグの原因をすばやく特定できます。
それは本質的にお金の問題です。
コードが優れているほど、保守が容易になります（そしてcheaper）。他の人のためだけでなく、最初にそれを書いた人のためにも。
残念ながら、このエクスペリエンスは実際に試してみないと適切に伝達することができません。つまり、合理的な状態になるまでに多くの作業を必要とする非常に大規模なコードベースが存在する可能性があります。再構築しすぎる必要があるかもしれません。 つまり行き止まりの多くの経験。
これを非技術者に説明する必要がある場合は、家と比較してください。基本的な青写真が適切でない場合は、多くの追加作業を行う必要があり、それでも劣った家があります。
最初に一連の要件があるプロジェクトから始めます。プロジェクトが要件に移行すると、変化し続け、コードを拡張する必要があります。
コードの作成を開始するときは、現在の要件と表示される可能性のある要件に合わせてコードを機能させます。
コードをリファクタリングしないと、コードを拡張したり、他の人が読みやすくしたりするのが難しくなるリスクが高くなります。
さらにコードをリファクタリングすることで、自分が何をしたかが明確になり、潜在的なバグを修正する機会が与えられます。
実際には、この質問は「なぜより小さなコードを書くのですか？」と解釈されます。実際には、より小さく、よりユニット化可能なコードのブロックが、より優れた、よりクリーンなデザインの可能性を招くからです。これらの小さなブロックを操作することは、大きなブロックを操作するよりもはるかに簡単になり、必要に応じてリファクタリングすることがより魅力的になります。
今、私の答え：
かなりまともなレガシーコードベースのリファクタリングを検討した後、コードの大きなブロック（クラス、関数など）がより多くのコードを招待することが私の経験でした。より多くのコードを無差別に適用すると、責任の原則やその他のベストプラクティスなどが分解されます。
だから、なぜより小さなコードを書くのかについての私の答えは？
それはあなたにあなたのコード構造とレイアウトについてもっと考えることを強いる一方で、「このコードブロックにより多くのものを詰め込もう」という考え方（そして時には必要性）を防ぎます。巨大なブロックに遭遇したとき、時間のプレッシャーのために、リファクタリングに時間をかけるのではなく、今物事を機能させる必要があるかもしれないので、私は必要性を言います。
醜い場合でも、一連の小さな自己完結型コードのリファクタリング作業を行う方が、絡み合った醜い巨大なメソッドを分割するよりも簡単です。
コードベースに取り組む将来のプログラマーがあなたが何をしていたかを理解するのに役立ちます。常に正しいとは限りませんが、目的があり、十分に自己完結している小さなコード単位は、コードがまたがるあいまいな長いすべてのものよりも速くメンタルモデルを構築するのに役立ちます。
これは、将来のプログラマーが、このコードが何をしているはずだった瞬間を防ぐのですか？そして、なぜこれまたはそのコード部分は、この特定の特異な方法でこれらのことを行うのですか？大きなコードブロックは、悪い習慣やさまざまなバグやロジックエラーを隠す傾向があるためです。