後で自分が書いたコードを見たら、混乱しませんか?

多くのプログラマは、コードを整理する方法、効率を高める方法、コードの保守性、再利用性、拡張性、柔軟性を向上させる方法を知りません。彼らが書くコードは混乱していますが、そのような混乱したコードでも実際には正常に実行できます。

このようなコーディング経験はありませんか?

私の周りの多くのプログラマーはそのような経験をしているでしょう。1年半後に自分が書いたコードを見ると、とてもひどいと驚きます。 . そのコードは本当に私が以前に書いたものですか? 私は実際にこのようなひどいコードを書くことができます

まだメンテナンスされているコードに関しては、この時点でそれをリファクタリングするアイデアが生まれるか、より良い方法があるでしょう。それを達成するために。この時点で、コードに対する愛憎の関係はすでに始まっています...

この映画では、主に 6 つの基本原則から始まり、デザイン パターンの入門として、6 つの基本原則とデザインの関係について説明します。以降の章では、デザイン パターンと日々の開発について詳しく説明します。

基本的な仕様と制約

基本的な仕様と制約については、資格のあるすべてのチームが独自の設定を持っていると思いますが、一方では標準が統一され、可読性と保守性が向上します。後でバグが発生した場合、後発者は問題をより早く見つけて解決できます。

この乱雑なコードは、後発者がそれを保守するために、間違いなくすべての先祖に心からの挨拶をするであろう大きな機能を実装しています。優れたコーディング習慣は、資格のあるプログラマーの自己修養に属し、害を及ぼすことなく、自分自身と他人にとって有益です。

開発における仕様と制約について、最初に言うべきことは名前です。

過去 5 年間の仕事の中で、私はあらゆる種類の人々と協力してきましたが、一番覚えているのは、暇なときに同時に 5 つのプロジェクトを開発し、維持したことです。お互いに学び、共に進歩していく人生、その過程で私にとって最も厄介なことは、いくつかの名前の不規則さです。

あらゆる種類の奇妙な名前が付いた非標準的なスタイルがたくさんあります。このような名前のリストには 2 つの機能があり、1 つは列の詳細と呼ばれるもので、もう 1 つは「ZhuanLaiDetalActivity」と「ZhuanLaiLiuYanActivity」という名前です。

そのような名前を恐れているのなら、あなたは本当に世界を見たことがありません。これで、少なくとも中国語のピンインの略語をいくつか見たことがあります。以前は、動物検査証明書の名前が djz だったので、さらに紛らわしいようです。

ピンインの命名について、ここで何か言うと批判されるかわかりませんが、いつもピンインの命名が好きな友人に会いました。ピンインは中国文化を促進するための中華民族の素晴らしい取り組みです。プログラミング時のピンインって本当に…とても落ち込んでいます。

たとえ最も強力なテクノロジーをサポートしていても、書かれたコードは小学生の作品のように見えます。ここで中国語のピンインを軽視するつもりはありません。私の心の中のいくつかを表現しているだけです。

推奨: 大きなハンプ、小さなハンプ、またはアンダースコアの名前付けは許容されます。統一された標準がない場合は、業界に参入したばかりの友人の場合は、「Alibaba Java 開発マニュアル」を参照してください。彼らの将来の成長に大きな助けとなるでしょう。

開発マニュアルのダウンロードアドレス: https://pan.baidu.com/s/1mjZxvSW。

次に強調すべきことはコメントです。多くの人はコメントが多ければ多いほど良いと考えているかもしれません。以前、コメントを増やすことを推奨する本を見たことがありますが、コメントは私たちに多くの負担と誤解を与える場合があると思います。

前回のレビュー中に、同僚の一部が私のコードの一部をコピーしたときに、実際には別の関数を作成したかっただけであることがわかりました (私は車輪の再発明は好きではありません)。いくつかの同様の関数)、より柔軟にしてコードの再利用性と柔軟性を向上させることが最善です)。

実際、再利用できる場所はほとんどありません。なぜ自分で数行のコードを書かなかったのかわかりません。大したことではありません。そのクラスに取り組んでいたときに、作成者が私であることがわかりました。これは私とは何の関係もなく、機能の説明もこれとはまったく関係ありませんでした。 class...

コメントに関して、もう 1 つ言うべきことは、必要性と名前付けの組み合わせと呼ばれる冗長なコメントです。優れた名前付け標準では、ログインと登録のコメントやログインと登録のコメントなど、多くの不要なコメントを省略できます。 、これらは完全に不要です。

良い習慣は開発に多くの利便性をもたらしますが、テキストビュー 1 とテキストビュー 2 という名前を付けることを好む人もいます。たとえコメントされていても、以下で使用すると、依然として上下に走るアルパカのグループになります。親切。

1.for (int i = 0; i

2. // TODO

3. }

このようなコードについては、多くの人はそれが正常であると考えるかもしれません。 Tan Haoqiang 先生のせいです。確かに Tan Haoqiang の本には多くの問題がありますが、これがこの種のコードを書く理由ではありません。

日常の開発では、他人のコードをメンテナンスしながら、いつもfor文をデバッグしますが、そのようなコードはひどいものであり、コメントを追加してもまだ混乱していると思いませんか？

各チームには独自の規範と制約があるため、大企業には各チームで統一された独自の規範があるため、将来時間があれば詳細を書きます。仕様に関する無料のブログ。

この分野については、本当に書きたいことがたくさんあります。case、1、2、3の後の無差別使用など、常に混乱を招きます。必要な定数置換変数、スレッドプールをスレッドに置き換えるなど、シングルトンについては本当にたくさんあるので、ここでは詳しくは説明しませんが、名前付けとアノテーションという 2 つの重要な点について説明します。

推奨: コメントは合理的に使用してください。初心者の場合、なじみのないコードや不明瞭なロジックを学習する場合は、理解を容易にするためにできるだけ多くのコメントを使用してください。できるだけ標準化された名前を使用してください。

コメントの効果は名前を付けることによって実現されますが、ロジックが複雑な場合や動作状態が多すぎる場合、メンテナンスコストを削減するために必要なコメントは依然として非常に重要です。

知っておくべきいくつかのプログラミングのアイデア

プログラマーがプログラムの作成に費やす時間は、作業時間の約 10 ～ 20% を占め、ほとんどのプログラマーは毎日約 10 ～ 12 行のコードを書くことができ、最終的なコードを入力できます。技術レベルがどれほど高くても、製品のコードは変わりません。

優れたプログラマーは、最適なソリューションを見つけるために思考、調査、実験に時間の 90% を費やします。ダメなプログラマは、特定の書き方がうまくいくことを期待して、問題のあるプログラムのデバッグと盲目的なプログラムの変更に時間の 90% を費やします。

優れたプログラマにとって、ロジックは最も重要です。そうすることで、バグの発生が減り、バグの発生率を非常に低いレベルまで下げることができます。

私はあまり優れた開発者ではありませんが、複雑な機能や多様な機能については、常に最初に自分のアイデアを明確にし、どのような操作があり、どこにバグがあるのかをリストアップします。私はよくチームメイトに「百聞は一見に如かず」と言いますが、始める前に自分の考えを明確にしておけば、半分の労力で2倍の結果が得られます。

ビジネスロジックが複雑かどうかに関係なく、何かが間違っている場合は修正し、コードが常に山積みになります。多くの修正を経て、それは認識を超えたものになり、それを維持する人にとってはさらに悲惨です。

ここで著者は、読者が最初に描画を試み、引き続きモジュールをインターフェースに分解し、インターフェースを実装することでモジュールを実装し、インターフェース指向のプログラミングを達成することで、保守性が向上することを示唆しています。 ...

モジュール間の通信は、クラス間の関連付けではなく、抽象化によって相互作用を実現する必要があります。抽象化は詳細に依存する必要はなく、詳細は抽象化に依存する必要があります。実装指向のプログラミングではなく、インターフェイス指向のプログラミング。

この利点は、呼び出されたクラスを将来別の実装クラスに置き換える場合、インターフェースは何も変更されないため、それを呼び出したクラスを 1 つずつ変更する必要がないことです。インターフェイスの実装クラスを構成内の新しいクラスに置き換えるだけで、すべてが置き換えられます。

クラス間の結合が弱いほど、結合が弱いクラスが変更されても、関連するクラスには影響しません。

提案: 半分の努力で2倍の結果を得始める前に、自分の考えを明確にしてください。開発プロセスでは、最初にインターフェイスを定義し、そのインターフェイスを実装してモジュール開発を完了すると、バグ率をできる限り減らし、より良いコードを作成できます。

技術的能力の向上は主に「高凝集性と低結合性」のコードに反映されており、これらのアイデアは現在人気のある MVC、MVP、MVVM などの多くの開発モデルを派生させているためです。

バージョンの反復と再構築

システムを構築するとき、システムの要件が最初に決定され、二度と変更されないことを期待すべきではありません。これは非現実的で非科学的な考えであり、要件は確実に変化します。変更では、要件の変更に直面したときに設計ソフトウェアを比較的簡単に変更できるようにするにはどうすればよいでしょうか。そうすれば、新しい要件が発生したときにプログラム全体を覆さなければなりません。

多くの友人がこれに遭遇したことがあると思います。元々は非常に一般的な要件であったものが、バージョンが繰り返され続けると、巨大な機能が形成され、その規模が大きくなるにつれて、メンテナンスのコストも増加します。悪循環が起こり、コードのリファクタリングが歴史の段階に入ろうとしています。

維持管理コストの観点から、再構築は確かに非常に良い解決策であることは否定できません。再構築の費用は元の基本的な維持管理の費用よりも小さく、将来の維持管理にも便利です。一部の企業では、バージョンを複数回繰り返した後でプロジェクト全体を直接再構築することさえあります。このようなことは小規模企業だけでなく、一部の大企業でも何度も発生します。

技術的に言えば、複雑なコードをリファクタリングするときは、古いコードを理解する、古いコードを分解する、新しいコードを構築するという 3 つのことを行う必要があります。

リファクタリングされる古いコードは、特に複数の反復があり、多くの人々によって処理されるモジュールでは、理解が難しいことがよくあります。モジュール間の過剰結合により、単一の動きが本体全体に影響を与えるため、範囲の制御が困難になります。影響; 古いコードはテストが難しく、特に製品ドキュメントが不完全な場合には、新しいコードの正確性が保証されません。

これは前回のレビュー中に見つけたコードです。これは製品の反復の結果ですが、これは言い訳ではありません。すべき。コードの再利用性に対する否定的な教材として、それがここにはっきりと反映されています。状態が増えると、これは必然的に何度も繰り返されることになります...

提案: リファクタリングされたコードは、その後の改訂を経た後、万能ではありません。いくつかのバージョンを重ねるうちに、コードは乱雑でまとまりがなくなり、コードの混乱が常に繰り返されました。

将来的に要件が変更されるかどうかはわからないので、コードの品質を改善し、変更に適応し、インターフェースを合理的に設計し、要件が変更されるたびにさらに考え、カプセル化することで対処するしかありません複数回使用されるコードを抽出し、既存のロジックの変更を最小限に抑えます。

デザインパターンの重要性

デザイン方法を知っている人は建設エンジニアであり、デザイン方法を知らない人はレンガ職人です。

これまでたくさんお話してきましたが、ここでデザイン パターンの重要性について直接話しましょう。デザイン パターンに関して言えば、6 つの基本原則とアーキテクチャ デザインについて言及する必要があります。想像できる。

まず、6つの基本原則はまだ少し議論がありますが、私が以前に読んだ本では、一般的には単一責任原則、デメテルの法則、リヒター置換原則、開閉原則、依存性逆転原則、インターフェース分離です。原理。

しかし、最近いくつかの投稿で、インターフェイス分離の原則は存在しないが、合成/集約の再利用の原則があるということを見ました。以前の準備に影響を与えないように、合成/集約の再利用の原則については個別に説明します。

6 つの基本原則は、建築設計全体の魂であり、建築設計の指針となるイデオロギーです。デザイン パターンは、建築設計の特定の設計手法であり、建築設計の具体的な実践です。

アーキテクチャ設計から始めましょう。アーキテクチャ設計は主に抽象化能力に反映され、アーキテクトのコーディング経験、機能の分解と理解、論理的な厳密さに依存します。

建築設計を行うときは、問題をできるだけ包括的に検討し、可能な限り包括的なコードを作成する必要があります。海はすべての川に開かれており、寛容であることが建築設計者の基本条件です。すべきだった。

検討する問題がより包括的で包括的であればあるほど、仕事はより困難になり、より多くの障害が自分自身に生じます。これらの詳細な問題を合理的に抽象化し、解決策を提案することが、抽象度が高いほど、より合理的になります。これがアーキテクトの価値です。

特定の要件からコード実装、特定の製品まで。アーキテクチャ設計の目的は、システムの再利用性、拡張性、安定性に他なりません。これらの特性を最もよく反映できるのは、抽象的なものだけです。

アーキテクチャ設計のプロセスでは、このクラスがデータ要求に使用される場合は、高い結合性と低い結合性をより適切に反映する必要があることがわかります。画像をロードするときは、ビューの注釈を分離して、1 つのクラスが 1 つの責任のみを担当し、変更の理由が 1 つだけになるようにしてください。

クラスがより多くの責任を負う場合、それはこれらの責任を結合することを意味し、不必要なメンテナンスコストが発生します。大きな観点から見ると、MVP パターンと MVC パターンはどちらも単一責任原則の具体化であり、モデル、ビュー、およびコントロールは分離されており、それぞれが独自の役割を実行します。

デメテルの法則は、2 つのクラスが相互に直接通信する必要がない場合、2 つのクラスは直接対話すべきではないことを示しています。あるクラスが別のクラスのメソッドを呼び出す必要がある場合、その呼び出しはサードパーティを通じて転送できます。

クラス間の結合が弱いほど、結合の弱いクラスが変更されても、関連するクラスには影響しません。主にクラス間の疎結合に重点が置かれています。

リスコフ置換原則については、多くの人はこの用語を聞いたことがないかもしれませんが、実際には、サブタイプは親タイプを置換できる必要があります。

「List list = new ArrayList();」という簡単な例を考えてみましょう。これを行う利点は、実際には非常に簡単です。たとえば、ある日 ArrayList では需要を満たせなくなり、LinkedList を使用する必要があるとします。グローバル リスト オブジェクトを変更する代わりに、ArrayList を LinkedList に置き換えるだけで済み、保守性が向上します。

オープンとクローズの原則は、拡張に対してオープンであり、変更に対してクローズである 2 つの部分で構成されます。ソフトウェア要件は常に変化します。ソフトウェア設計者にとって、元のシステムを変更することなく柔軟なシステム拡張を実現する必要があります。

拡張に対してオープンであるということは、具体的なプログラミングではなく抽象的なプログラミングを意味します。これは、拡張がインターフェイスまたは抽象クラスを通じて制限されており、インターフェイスや抽象クラスに存在しないパブリック メソッドの境界が定義されていないためです。現れる。

クラスを固定された抽象化に依存させて、変更を禁止します。これは継承とポリモーフィズムに基づいており、抽象クラスの継承を実装し、そのメソッドをオーバーライドすることでメソッドを拡張できます。

依存性逆転の原理は、特定の実装に依存するのではなく抽象化に依存することを指します。実際、これの利点は、実装指向のプログラミングではなく、インターフェイス指向のプログラミングであることです。

一般に、抽象化が変更される確率は非常に小さいため、ユーザープログラムは抽象化に依存し、実装の詳細も抽象化に依存します。たとえ実装の詳細が変化し続けたとしても、抽象化が変わらない限り、クライアントプログラムを変更する必要はありません。これにより、クライアント プログラムと実装の詳細の結合が大幅に軽減されます。

インターフェース分離の原則は、「単一のインターフェースを使用するよりも、複数の特殊なインターフェースを使用する方が良い」と考えています。

モジュールは、必要なインターフェイスに依存し、必要なインターフェイスを提供し、不要なインターフェイスを削除する必要があります。同時に、肥大化したインターフェイスによって引き起こされる汚染を回避し、無関係なインターフェイスを削除するために、単一責任の原則にも従う必要があります。それらを結合して肥大化した大きなインターフェイスを形成することは、インターフェイスに対する一種の汚染です。

インターフェースの粒度は小さすぎることはできません。小さすぎるとインターフェースの数が急激に増加し、インターフェースの粒度が大きすぎると柔軟性が低下し、カスタマイズされます。サービスを提供できなくなり、プロジェクト全体に予期せぬ結果がもたらされるリスク、合理的なインターフェイス設計も芸術です。

多くのデザイン パターンでは複数の基本原則が使用されているため、この図については多くの議論があるはずです。上の図はデザイン パターンの大まかな概要にすぎません。

デザインパターンにおける 6 つの基本原則 (合成/集約および再利用の原則を含む) の具体的な具体化を強調し、6 つの基本原則と 23 のデザインパターンが相互に補完的であることも説明します。デザイン パターンの基礎となるテンプレート、デザイン パターンは、6 つの基本原則を柔軟に具体化したものです。

合成/集約と再利用の原則には多少の議論の余地があります。現在、一部の書籍では、依然として構成/集約の再利用の原則が維持され、インターフェイスの分離の原則が削除されています。構成/集約の再利用の原則は、継承の使用を減らし、構成関係の使用を増やす実装を指します。

構成と集約はどちらもオブジェクト モデリング関係の一種であり、全体は部分から構成されており、部分は全体から分離されることなく独立した個体として存在できます。 、部分と全体の厳密な関係を体現しており、部分と全体のライフサイクルは一貫しており、部分は全体から分離できません。

概要: 6 つの基本原則はオブジェクト指向思考の具体化であり、単一責任原則とインターフェイス分離原則はカプセル化の概念を具体化し、開閉原則はオブジェクトのカプセル化と多態性を具体化します。そしてリスコフ置換原則はオブジェクト継承の仕様です。

依存関係逆転原理に関しては、ポリモーフィズムと抽象的思考の具現化です。オブジェクト指向を完全に理解し、基本的な設計原則を習得し、それをプロジェクト設計に柔軟に使用できることに基づいて、コードの品質と構造設計を向上させることができます。

特に再利用性、保守性、拡張性、柔軟性を確保するために、これはデザインパターンを理解し習得するために必要な知識でもあります。

補足

6つの基本原則を念頭に置いて、開発に柔軟に活用してください。 日々の開発におけるデザインパターンの適用に関して、重要なことは1つです。の。

現時点でモジュールが非常に軽量で、デザインパターンを使用するためだけにデザインパターンを使用している場合、これは間違いなく目立たないように見え、プロジェクトが肥大化し、不必要なメンテナンスコストも発生します（ただし、メンテナンスコストは非常に低いです） 。

私は最近情報を整理し始め、主に MVP の落とし穴とデメテルの法則、フレームワークと開始原理と終了原理、シングルトンと落とし穴、スキニングとオブザーバー パターン、ローディング リストとテンプレート メソッドに焦点を当てたデザイン パターンに関する特別なトピックを書く準備を始めています。パターン、コンストラクターとビルダーの比較、複数のサードパーティのログインとコマンド モードは今後も改善されていく予定ですので、ご期待ください。