記事ディレクトリ
第1章ネーミング
関数名
関数の命名は具体的である必要があり、一般的な命名は無意味です。たとえば、すべてのメソッドがデータを処理しているため、processData（）は適切な名前ではありません。このような名前は何をすべきかを示すものではありません。対照的に、validateUserCredentials（）またはexcludeDuplicateRequests（）の方がはるかに優れています。
関数の名前は、それがどのように行われるかではなく、その機能を反映する必要があります。スタックに従業員情報を格納していて、スタックから最後に格納された従業員情報を取得する場合、スタックのデータ構造が基本的な実装の詳細であり、命名により抽象化レベルが向上するため、getLatestEmployee（）がpopRecord（）よりも優れています。ビジネスのセマンティクスを反映します。適切な名前を付けることで、「ポップ」を覚えるという精神的なステップを省くことができます。「最新の従業員の情報を取得してください」と言うだけで済みます。
補助クラス
補助クラスの場合は、ヘルパーやユーティリティなどのサフィックスを使用しないようにしてください。それらの意味は一般的すぎて、SRP（単一の責任の原則）を破壊するのが簡単だからです。
たとえば、CSVを処理するには、次のように記述します。
CSVHelper.parse(String)
CSVHelper.create(int[])
しかし、CSVHelperを分解することをお勧めします。
CSVParser.parse(String)
CSVBuilder.create(int[])
メソッド名の規則
| CRUD操作 | メソッド名の規則 |
|---|---|
| 追加 | つくる |
| 追加 | 追加 |
| 削除する | 削除する |
| 修正 | 更新 |
| クエリ（単一の結果） | 取得する |
| クエリ（複数の結果） | リスト |
| ページングクエリ | ページ |
| 統計学 | カウント |
反対の言葉を使う
単語ごとの命名規則に従うことで一貫性が維持され、コードの読みやすさが向上します。最初/最後のような対照的な単語は理解しやすいですが、fileOpen（）やfClose（）のような組み合わせは非対称で混乱を招きます。ここではいくつかの一般的な反対のフレーズがあります：
add/remove
increment/decrement
open/close
begin/end
insert/delete
show/hide
create/destroy
lock/unlock
source/target
first/last
min/max
start/stop
get/set
next/previous
up/down
old/new
事後修飾子
多くのプログラムには、合計、平均、最大などの計算結果を表す変数があります。Total、Sum、Average、Max、Minなどの修飾子を使用して名前を変更する場合は、名前の末尾に修飾子を追加してプロジェクトに実装し、命名スタイルの一貫性を維持するようにしてください。
この方法には多くの利点があります。まず第一に、変数名の最も重要な部分、つまりこの変数に主な意味を与える部分は、強調表示して最初に読み取れるように最前線に置く必要があります。第2に、プログラムでtotalRevenueとsalesTotalを同時に使用することによって生じるあいまいさを回避できます。事後修飾子の原則を実装すると、revenueTotal（総収入）、expenseTotal（総支出）、revenueAverage（平均収入）、expenseAverage（平均支出）など、非常にエレガントで対称的な変数名のセットを取得できます。
注目すべき点の1つは、修飾子Numです。Numは変数名の最後に配置され、添え字を示し、customerNumは現在の顧客のシリアル番号を示します。Numによる問題を回避するために、CountまたはTotalを使用して総数を表し、Idを使用してシリアル番号を表すことをお勧めします。このように、customerCountは顧客の総数を表し、customerIdは顧客の数を表します。
コメント
- 機能を繰り返さないでください
コード機能を再掲するために存在するコメントの主な機能は、私たちの意図を表明するときに遭遇した失敗を補うことです。現時点では、そのようなコメントが必要かどうかを検討する必要があります。プログラミング言語が十分に表現力がある場合、またはコードで意図を明示的に表現することに長けている場合、おそらくコメントはまったく必要ありません。したがって、コメントを書くときは、表現力が足りないかどうかを内省する必要があります。
- 背後にある意図を説明する
コメントは、単に関数を繰り返すのではなく、コードの背後にある意図を説明できる必要があります。
第2章仕様
ログ仕様
1。ERRORのレベル
ERRORは、それ自体では回復できず、注意を払い、すぐに解決する必要があるエラーを示します。たとえば、データベース操作エラー、I / Oエラー（ネットワークコールタイムアウト、ファイル読み取りエラーなど）、不明なシステムエラー（NullPointerException、OutOfMemoryErrorなど）。
ERRORの場合、スレッドスタックだけでなく、トラブルシューティングを容易にするために、特定のコンテキスト（TraceId、ユーザーID、注文ID、外部からの主要なデータのリンク）も出力する必要があります。
ERRORは監視および警報システムに接続する必要があります。ERRORでは、時間のロスを停止するために手動の介入が必要です。それ以外の場合は、システムの可用性に影響します。もちろん、ERRORを悪用しないでください。悪用すると、「オオカミがやってくる」という状況が発生します。実際の業務では、システムが毎日何千もの誤報を発してしまう状況に遭遇しました。その結果、誰も警報の内容を読み取らず、問題が発生しても誰も注意を払っていないため、オンライン障害が発生しています。したがって、エラー出力シーンの定義と標準化を適切に行い、監視と管理に協力してオンラインシステムの安定性を確保する必要があります。
2。WARNレベルを
予測可能なビジネス上の問題については、アラームシステムを汚染しないように、ERRORを使用してログを出力しないことをお勧めします。たとえば、パラメーター検証の失敗やアクセス権がないなどのビジネス例外は、ERRORで出力されるべきではありません。
短期間に生成されるWARNログが多すぎることも、システムが正常でないことを示しています。そのため、WARNに適切なしきい値でアラームを設定する必要があり、たとえば、アクセス制限WARNが100回/分を超えると、アラームが発行されます。このようにして、WARNログの頻度が高すぎる場合、ユーザーの問題を追跡するためにシステムアラームを時間内に受け取ることができます。たとえば、製品設計に欠陥があり、ユーザーにとって操作のスタックポイントが頻繁に発生する場合は、プロセスまたは製品の最適化を検討してください。
3。INFOレベル
INFOは、システムの基本的な操作プロセスと操作ステータスを記録するために使用されます。
一般的に言えば、優先度は最初にINFOログに基づいて見つけることができます。INFOログには、主にシステムステータス変更ログ、ビジネスプロセスのコア処理、主要なアクション、およびビジネスプロセスのステータス変更が含まれます。適切なINFOは問題のトラブルシューティングに役立ちますが、INFOをDEBUGとして使用しないでください。これにより、記録されるデータが多すぎます。一方で、システムパフォーマンスが影響を受け、ログファイルが急速に増大し、不要なストレージリソースが消費されます。ログファイルの読み取りに役立ちます。
4。デバッグレベル
DEBUGは、リクエスト/レスポンスのオブジェクト内容などのデバッグ情報を出力します。オブジェクトのコンテンツを出力するときは、ObjectのtoStringメソッドをオーバーライドする必要があります。オーバーライドしない場合、出力はオブジェクトのメモリアドレスであり、デバッグには役立ちません。
通常、開発およびプレリリース環境では、開発およびデバッグを容易にするためにDEBUGログが開かれます。オンライン環境では、DEBUGスイッチをオフにする必要があります。実稼働環境でDEBUGを開くと、大量のログが生成され、その損失は許容できないためです。DEBUGは、オンラインでバグまたは厄介な問題がある場合にのみ動的に開くことができます。ログボリュームが大きくなりすぎないようにするために、分散構成ツールを使用してrequestIdに基づくログフィルタリングを実装し、要求する必要のあるDEBUGログのみが出力されるようにします。
異常な
ビジネスシステムでBizException（ビジネス例外）とSysException（システム例外）の2つの例外を設定することをお勧めします。これらの例外は両方ともUnchecked Exceptionにする必要があります。
try / catchを使用して、ビジネスプロセスのすべての場所でエラーログを印刷しないでください。これにより、関数コードとビジネスコードが絡まり、コードが煩雑になり、コードの可読性に影響します。
第3章機能
パラメータの数
パラメータの最も理想的な数は、ゼロ（ゼロパラメータ関数）で、その後に1（1変数関数）、2（2変数関数）、3（3変数関数）の順で、できるだけ避ける必要があります。
関数が4つ以上のパラメーターを必要とする場合は、一部のパラメーターをクラスとしてカプセル化する必要があることを意味します。
短い機能
Java言語の場合、メソッドは20行を超えないようにすることをお勧めしますが、このルールをチームのコードレビューの厳密な指標として使用したところ、コードの品質が大幅に改善されたことがわかりました。
単一の責任
つまり、メソッドは1つのことだけを行います。これは、関数レベルでの単一責任の原則です。
コードの可読性を向上させるだけでなく、コードの再利用性も向上させることができます。責任が単数で機能のまとまりが強いほど、再利用される可能性が高くなりますこれは、コードの行数には直接関係しませんが、間接的に関係します。
補助コードを合理化
いわゆるアシスタントコードはプログラム操作に不可欠なコードですが、ヌル判定、ログ印刷、認証、ダウングレード、キャッシュチェックなどのビジネスロジックを処理するためのコアコードではありません。これらのコードは、複数の機能で冗長になる傾向があります。
補助コードが多すぎると、コードの可読性が大幅に低下し、この種のコードを読むと、人々は頭がおかしくなり、混乱します。したがって、ビジネスコードへの補助コードの干渉を最小限に抑える必要があります。関数内のコードにビジネスロジックを直感的に反映させ、ビジネスコードを補助コードに埋め込むのではなく、
複合機能モード
結合された関数では、すべてのパブリック関数（エントリ関数）が一連の実行ステップの要約のように読み取る必要があり、これらのステップの実際の実装の詳細はプライベート関数にあります。関数を組み合わせると、コードが洗練されたままになり、再利用が容易になります。
平手打ち
単一レベルの略奪原則（SLAP）は、組み合わせ機能に密接に関連する原則です。関数を組み合わせるには、大きな関数を複数のサブ関数の組み合わせに分割する必要がありますが、SLAPでは、関数本体の内容が同じ抽象化レベルである必要があります。高レベルの抽象化と低レベルの詳細が混在していると、面倒で理解しにくいように見えます。
結合された機能とSLAPの原則に従って、エントリ処理ではビジネス処理の主要なステップのみを表示する必要があります。特定の実装の詳細はプライベートメソッドによってカプセル化され、抽象化レベルの一貫性を使用して、高レベルの抽象化および実装の詳細と混合されるのではなく、関数内の抽象化が同じレベルになるようにします。
ピラミッドを構築するプロセスでは、ピラミッドの各レイヤーが同じ論理カテゴリと同じ抽象化レベルに属している必要があります。この時点で、ピラミッドの原則とSLAPは相互に関連しており、世界は非常に素晴らしく、多くの原則がさまざまな分野に等しく適用されます。
第8章要約
抽象とは
抽象化は、物事を単純化し、物事の本質を把握するプロセスです。抽象化は、問題の本質に近づくのに役立ちます。
階層化された抽象化
階層化された抽象化は、ソフトウェアの世界のどこにでも見られ、ソフトウェアアーキテクチャの中核です。
各層の抽象化は、層の関連情報にのみ焦点を当て、複雑さを上位層から保護し、それによってシステム全体の設計を簡素化します
抽象化する方法
- 共通点を探しています
抽象化のプロセスは、類似のアイテムをマージし、カテゴリをマージし、共通点を見つけるプロセスです。内部の論理関係を持つものをまとめて、このカテゴリに名前を付けると、この名前は、このカテゴリのグループの抽象化を表します。
- 抽象化のレベルを上げる
カテゴリにグループ化できないものがある場合は、論理的な関係により、それらをより高い抽象化レベルに引き上げることができます。
- ピラミッドを構築する
上から下に表現し、最初に結論を出します。その中でも、ボトムアップサマリーのプロセスは抽象的なプロセスであり、ピラミッドを構築するプロセスは論理的な関係を見つけて抽象化するプロセスです。構造化された方法で問題に対処し、独自のピラミッドを構築する定期的な演習は、問題のコンテキストを明確にし、抽象化能力を向上させるのに役立ちます。
ピラミッド構造は、理解と記憶を容易にするために、抽象化を通じてカオス的で無秩序な情報を抽象化の異なるレベルに形成することを可能にしますこれは非常に実用的な方法です。
抽象的思考を改善する方法
- さらに読むと、読書の過程で私たちの抽象的な能力と想像力が発揮され、写真を見ると脳がいっぱいになり、抽象化と想像力の必要性が少なくなります。
- もっとまとめます。まとめるのに最適な方法は、記事を書くことです。録音も良いまとめの習慣です。ノートを読む場合は、本の内容を原文から抜粋するのではなく、自分の言葉でまとめてまとめることで、理解が深まるだけでなく、抽象的思考力も向上します。
- もっと書く
抽象的な美しさ
「抽象化」は名詞としての考え方を表すもので、細部はさておき、本質的で一般的なものの特徴をとらえることで、問題領域をより効果的に分析・設計できるのが素晴らしい。動詞としての「抽象化」は一種の能力を表しており、概念を理解し、それらの間の論理的な関係を明らかにするための基礎であり、オブジェクト指向の分析と設計に必要な基本的な能力でもあります。
要約すると、同様のアイテムをマージすることは、抽象的なアクティビティにとって最も効果的な方法です。同時に、抽象化は階層的であることにも注意する必要があります。概念が拡張をカバーできない場合、抽象化レベルを上げて、その意味合いを減らし、拡張を大きくする必要があります。
読者は自分自身の抽象的な思考を養う必要があることをお勧めします。記事を読んだり書いたり、論理的思考のトレーニングは、抽象的思考能力を向上させる非常に良い方法です。勉強や運動を続けている限り、ゆっくりと異なる種類の美しさ、つまり抽象化の美しさを体験できます。
第9章分割統治
分割統治の価値
分割統治の価値は、問題のドメイン全体を同時に頭の中に詰め込もうとするのではなく、特定の方法で問題を整理して、一度に特定の部分に集中できるようにすることです。これの目的は、いつでも考慮される問題の複雑さを最小限に抑えることです。
ステップの分割と征服
問題を分割して克服する一般的な手順は次のとおりです。
（1）分解：解決する問題をいくつかの小さな同様の問題に分割します。
（2）解法：副問題が十分に小さい場合は、より簡単な方法で解いてください。
（3）マージ：元の問題の要件に従って、サブ問題のソリューションがレイヤーごとにマージされ、元の問題のソリューションが形成されます。
コード作成の2つの作成
- 初めて機能を実現
「完璧な」コードを一度書こうとしないでください、それは私たちのペースを遅くするだけです。記事を書くのと同じように、最初にラフに書いて、一般的な意味を書き、理想的な見た目になるまで注意深く磨くことができます。
同じことがコードの記述にも当てはまります。最初のパスは主に関数を実装することです。これにより、過度のインデントやネストされたループ、長いパラメーターリスト、名前を自由に取ることができるなど、ある程度の冗長性と複雑さを許容できます。コードが重複しています。最初のパスでは、主にロジックを明確にし、2番目のパスの再構築と最適化の準備をします。
- 2パス再構成最適化
関数の実現に止まる場合、コードはせいぜい半製品です。実際の状況では、コードベースにそのような半完成品が多すぎるため、システムの複雑さが増し続け、保守がますます困難になっています。したがって、2番目の作成-リファクタリングと最適化が必要です。つまり、関数の最初の実装に基づいて、もっと上手くできるかどうかを確認します。命名は妥当ですか？責任は単一ですか？OCPを満たしていますか？関数ですか？長すぎますか？抽象化は妥当ですか？
したがって、最善の最適化は、システムがオンラインになるのを待たずに実行することです。これは、「二度と実行しない」ことを意味することが多いためです。最適化作業はコーディング作業の一部である必要があり、主にコーディング効率を考慮して、2つのステップに分かれています。
第10章技術者のスキル
独断的ではない
ソフトウェアの最初の原則は、ソフトウェアの複雑さを制御することです。特定の開発プロセスやプログラミングパラダイムに固執しないでください。コードの可読性、スケーラビリティ、および保守性を改善できる方法は、検討する価値があります。
批判的思考
批判的思考とは、推論を慎重に使用して、アサーションが真であるかどうかを判断する能力です。それは、思考の自律性と論理の厳密さを維持すること、すべてを受動的に受け入れること、または偏見のある視点を故意に反駁することを要求します。
成長の考え方
成長の考え方を持つ人々は、学習を通じて自分自身を向上させることができ、学習と成長の力を信じ、そして努力が知性と能力を変えることができると信じています。
成長の考え方を持つ人々は、その瞬間の成功または失敗に対してより合理的な態度を取り、成長と学習の力をしっかりと信じます。
構造化された思考
構造化思考とは何ですか？私の構造化思考の定義は「論理+ルーチン」です。
いわゆるロジックとは、構造間に論理関係がなければならないことを意味します。たとえば、話すときは「1番目、2番目、3番目」の論理シーケンスを使用するのが妥当ですが、「1番目、2番目、4番目」を使用するのは奇妙です。実際、組織的思考のロジックは4つしかありません。
1.ロジック
（1）演繹的順序：たとえば、「大前提、小前提、結論」の演繹的推論方法は演繹的順序です。
（2）時間（ステップ）シーケンス：「1番目、2番目、3番目」、「1番目、2番目、次に」などのように、ほとんどの時間シーケンスも原因シーケンスです。
（3）空間（構造）シーケンス：たとえば、「フロントエンド、バックエンド、データ」や「ボストン、ニューヨーク、ワシントン」などは、パーツに分割されます（全体をパーツに分解）はすべて空間シーケンスです。空間分解を行うときは、「相互排他的集合的網羅的」（MECE）の原則を満たすことに注意してください。
（4）程度（重要度）の順序：「最も重要、2番目に重要、重要でない」など。私たちの考えと表現がこれらの4つの論理シーケンス内にある限り、それらは論理的です。それ以外の場合、論理はありません。
2.ルーチン
ルーチンとは、問題を解決するための方法論、パス、経験を指します。たとえば、5W2H分析方法は非常に優れており、問題の分析に役立つ「ルーチン」です。問題が発生した場合、「なぜ、誰が、いつ、どこで、何を、どのように、どのくらい」の7つの側面（図10-6に示す）から考えることができれば、それはより良いでしょうか。この方法論を知っている人がドットモードで考える方がはるかに包括的ですか？
ロジックは一種の能力であり、ルーチンは方法論と経験であり、ロジックはタオに属し、方法論はテクニックに属します。どちらも非常に重要です。両方を習得することによってのみ、より構造化された思考が可能になります。次に、2つのケースを使用して、実際の作業シナリオで構造化思考のアプリケーションを紹介します。
構造化された表現：
- 最も明確で最も実用的な構造化された表現は、「問題を提案し、問題を定義し、問題を分析し、問題を解決し、最後に将来を見据える」です。
- 合計スコアの構造：話をすると、私たちは映画のレンズのようになり、最初は遠くからズームインし、次に近くからズームインします。
道具的思考
繰り返し作業がある場合は、怠惰であること、ツールの作成方法を学び、一度にすべての作業を行って、作業効率を向上させる
私が忙しくて考えられないときは、立ち止まって、効率を改善するのに役立つもっと怠惰な方法があるかどうか考えてみることをお勧めします
好奇心
学習の動機は、外部からではなく、世界についての知識と好奇心に対する私たちの内なる欲望から生まれるべきです。
好奇心は私たちが仕事での経験を継続的に学び、蓄積することを可能にし、それによって仕事の効率を向上させます。
メモする
1.クラウドノートを使用し、マルチターミナルの使用をサポートし、ディレクトリ階層、タグ、および検索機能を備えてい
ます。2.分類およびグループ化し、定期的にノートの内容を確認し、論理ツリーを形成するためにノートを適切な方法で再編成します構造化して、独自のナレッジシステムを段階的に作成し、より便利にしていきます
。3。コピーアンドペーストしないでください。メモの内容は、消化後に要約にするのが最善です。トレーサビリティを容易にするために、リンクをメモの下に置くことをお勧めします
。4。構造化された表現：短いコンテンツ重要なポイントを強調するには、長いコンテンツのカタログを用意するのが最適です
目標がある
目標の重要性は、以前は過小評価されていました。実際、以前の私の不安や混乱の多くは、不明確な目標が原因でした。
最初に目標について明確に考え、次にそれを達成するために努力します。それが主要な生命問題であろうと、段階的に達成されるべきものであろうと、明確な目標と明確な目標が必要です。
多くの人が多くの技術記事を読んだと言いますが、常に何も知らないと感じています。非常に重要な理由は、あなたが目標を持って学んでいないことです。情報爆発のこの時代に、さまざまな公式アカウントによって押し出された記事を断片で受け取っただけでは、学習効果はほとんど無視できます。学習する前に、この学習の目的は何かを自問する必要がありますか？Redisの永続性の原理を明確にしたいですか？またはRedisのマスター/スレーブ同期メカニズムを理解していますか？またはRedisクラスターアーキテクチャ全体を学習したいですか？システム？関連情報を収集し、質問と目標で学習できれば、半分の労力で2倍の結果が得られます。この学習モードの効果は、断片化した読み取りよりもはるかに優れています。
心の平和
私のモットーは**「やる気は最高の無私の心です。不活発な心で、有望なことをしてください」**です。まず第一に、物事を行うための私たちの出発点は良いはずです。第二に、「有望なこと」とは、真剣に行動し、真剣に生きることを意味し、「不活動心」とは、ある種の心の平和、ある瞬間に生きる知恵を意味します。それは積極的に物事を行うことですが、考え方は穏やかでなければなりません。
勤勉
勤勉とは、毎日少しずつ進歩しなければならないことを意味します！覚えておいてください、遅いのは速いです。毎日少しずつ進歩する力を無視しないでください、そして一口で太るようにしようとしないでください本当の進歩は、滴り落ちる水と石の蓄積であり、それは勤勉です。
しっかりと学び続けられる方なら結果は悪くないでしょう。
マインドマッピング
