リファクタリングによってコードが単純になるのはなぜですか？

写真の記憶があり、プログラムのさまざまな部分がどのように組み合わされているかを思い出せれば、バグははるかに少なくなりますよね？メモリを構築するのは難しい場合があります。 しかし、一度に1つのことに集中できることで、同じメリットをたくさん得ることができます。

ソフトウェア開発の多くのベストプラクティスは、一度に頭に入れておかなければならないことの数を減らすことです。いくつかの例：

• 戻り値の一貫性 つまり、さまざまな状況でさまざまな種類のデータを処理するのではなく、1種類のデータを処理する方法を考えるだけで済みます。

• 抽象化 シンプルなインターフェースの背後にコードを隠す方法です。優れた抽象化により、抽象化がどのようにすべきかを考えることができます。 行動すれば、内部でどのように機能するかを心配する必要はありません。

• テスト 別の領域で作業しているときに、ある領域で誤ってコードを壊してしまうのを防ぐことができます。誤って壊したものはすべて捕らえられると想定できます。つまり、作業中のコードだけに集中して、後で壊れたものはすべて修正できます。

• テスト駆動開発 期待どおりに機能するコードを作成するのに役立ちます。テストに合格するメソッドの可能な限り単純な実装の作成に集中できます。単純すぎて実際に期待どおりに機能しない場合は、テストで検出されます。

これらのテクニックを正しい方法で使用すると、いくつかの適切な仮定を立てることができます。これらの仮定により、頭の前にいる必要はありません。コードがシステムに与える可能性のあるほぼ無限の影響について心配する必要がないため、より優れた、より信頼性の高いコードを記述できます。

一方、これらのテクニックを間違った場所で使用すると、非表示になります。 実際に見る必要のあるコード。コードを非表示にすることで、あなたが行う仮定が間違っている場合があります。これにより、さらに 壊してしまう可能性があります！

だからこそ、悪い抽象化はまったく抽象化されないよりも悪いのです。そして、魔法のように良くなるまで、コードに「extractメソッド」を投げることができないのです。

適切なリファクタリング、適切な場所

明確なコードとは、それが何をしているのかを前もって知っているコードです。 知っておく必要のあることを示すことは、知る必要のないことを隠すことと同じくらい重要です。 リファクタリングを実行するとき、またはソフトウェアのベストプラクティスを使用するときは、最終的に得られるコードと、それが複雑さを軽減するのにどの程度役立ったかを考える必要があります。残りのコードがうまく機能し、仮定が単純化されるのを助けていますか？それとも、単純すぎるインターフェースの背後に重要な知識を埋め込んでいますか？