適切に設計されたアプリケーションを使用しましたか？
この質問 に触発されて、私は疑問に思い始めました-「うまく設計されたアプリケーション」のようなものはありますか、またはありましたか？アーキテクチャが完璧で、リファクタリングが不要なもの。プロジェクトに不慣れな人でも、コードは読みやすく、理解しやすいでしょう。変更は、何も壊さないという100％の確実性で行うことができます。等？
私が使用したコードベースが何であれ、それらはすべて多かれ少なかれ混乱していたことを認めなければなりません。私が自分で始めたコードでさえ、最初は整理されたままであり、時間の経過とともに徐々に劣化します。私はこれを人生の一部として受け入れ始めており、それについて心配すべきかどうかを理解することさえできません。
それで...「うまく設計されたアプリケーション」のようなものはありますか？または 私たちのコードはすべてとてもくだらないです とにかくそれは決して良くないので、それをより良くしようとしても意味がありませんか？
完璧に設計されたアプリケーションに出くわしたことはありませんが、完全に作成されたように見えるコードのブロックに出くわしました。ほとんどのアプリケーションには多くの開発者が関与しており、コードに関しては「完璧」という意見が非常に多いため、アプリケーションを完全に構築することは不可能です。
ただし、「HelloWorld！」にできる改善点は1つも考えられません。応用。それはすべての要件を完全に満たしているようです。
優れた設計にはいくつかの基本的な要素がありますが、多くは主観的であり、アプリケーションの現在の使用、アプリケーションを作成したチーム、保守する必要のある人、および将来の実装に関連しています（幸運を祈ります）。
ポリモーフィズムは、複雑になりすぎるまでは素晴らしいものです。 45文字の機能は明確ですが、入力するのは面倒です。
Basic forMSDOSで書かれたアプリを見ました。その時のためのエレガントなコード。それを何百もの顧客に販売し、8年間で主要なデータ構造を変更することはありませんでした。誰かがGUIが必要だと判断し、VBで完全に書き直しました。この混乱の山は、主要なバグを解決するためだけにほぼ1年かかりました。
コードがどんなに優れていても、最終的には破棄されると考えてください。すべてのiPhoneの99％が最終的に埋め立て処分されます。
何度かあります。実際、私の現在のプロジェクトでは、データベースへの接続方法を変更するだけで、わずか2、3日で（かなり重要な）変更を加えることができました。データベースコードはモジュール式で、十分にファクタリングされており（戦略パターンを使用して、DB固有のセクションを分離しました）、常にインターフェイスを介して呼び出すように注意しました。抽象化とデザインパターンFTW！
まあ、私はこのようなものを見たことがありません：
アーキテクチャが完璧で、リファクタリングが不要なもの。プロジェクトに不慣れな人でも、コードは読みやすく、理解しやすいでしょう。変更は、何も壊さないという100％の確実性で行うことができます。等？
そうは言っても、私はいくつかの非常にうまく設計されたプロジェクトに取り組みました。どちらも非常にモジュール化されており、単一責任の原則を課していました。私が気に入ったのは、やや単純なものでした。自家製のコンポーネントシステムがなく、実装の継承が少なく、コンパイル時のチェックが多くなっています。
しかし、ええ、これらの2つのプロジェクトを除いて、私が今まで見た他のすべては混乱です。