「プログラマーの実践の道：小さな労働者から専門家まで」6,000語を読んだまとめ

この本を読んだ後、私は基本的な知識を持っていたので、それほど時間はかかりませんでした. これは主にその時の考えとまとめを記録するためのものであり、あくまでも個人的な考えと経験です。

この本は、Geek Time の「10x Programmer's Working Method」に似ていますが、より良いコロケーション、より速い消化、より簡単な「体重増加」を備えています。

では、この本は何について書かれているのでしょうか。

この本は、難解な技術、意気揚々としたアイデア、またはプログラミング言語については語らず、読者の思考を刺激し、実践者になることを奨励する小さなチェックリストをリストするだけです。

必要に応じて、コードを書くたびに、コードを書くとき、コードを書いた後に参考書として読んで、空いた時間に確認して考えてみてください。徐々に、その本は実際には不要になりました。

この本には、元のタイトル「The Pragmatic Programmer」のテーマワードでもある、非常に重要なキーワードがあります。Pragmatic です。この言葉をどう理解するか。

非常に重要な点は、思考と認知の進化です。

この業界に入ったばかりのプログラマーの中には、コードを打ち込むだけの仕事で「実行するだけでいいんだよ～」と思っている人も多いのではないでしょうか。

ただし、これに限定することはできません。コードは問題を解決するためのツールであり、業務を効率化するためのものであり、ツールの使用効率を向上させることが私たちの仕事の効率化につながります。タイピングを速くしたり、難しくしたり、より多くのコードを書いたりすることではなく、単にそれを行うだけでなく、より良く行うことです。それを行うには、少なくとも次の側面があると思います。

心変わり
自分自身を向上させます
適切で低コストの実装を選択する
より便利なツールを使用する
より良いコードを書くために、コードの量は以前よりも多くても少なくてもかまいませんが、将来書かれるコードの量は少なくする必要があります。
コミュニケーションに注意を払い、コラボレーションに注意を払い、プロジェクトでより多くの「ビジョン」に焦点を当てます。システムは一人で構築するのではなく、協力して構築します。

正直なところ、多くの場合、給与の増加は、あなたがより多くのことをしなければならないものではなく、元の仕事でより多くのことを行い、確実に得られるものです.

強くなり、給料を上げ、金持ちになる方法

この本の序文には、読むために提起できるいくつかの文があります。

正しい原則に従って正しい行動を導くことができるかどうかは、実際には、マスターであるかどうかを区別するための明確な兆候です。

しかし、誰もが真実を理解していると思いますが、正しい原則は何ですか? 常に行動を導く方法は？

上で言ったことを思い出してください。この本は実際にはいくつかのチェックリストであり、それぞれが短い文です。この本の多くは、これらの短い文の解釈に専念しており、例を通して理解しやすくなっています。

よし、物はそこにある、やってみよう：

いくつかの簡単な言葉やルールを抽象化し、記憶と絶え間ないリマインダーに依存し、これらの小さな声を小さなスケールで内面化する必要があります。これにより、これらの単純な小さな声が常に脳から耳にジャンプして自分自身に思い出させることができます.

ひっくり返して大丈夫です。それを見て、実践して、最終的には必要ありません。自然に行われたからです。

特定のテクノロジーに縛られるべきではありませんが、特定の状況に適したソリューションを選択できるように、十分に幅広いバックグラウンドと経験ベースを持っている必要があります。あなたのバックグラウンドはコンピュータサイエンスの基礎を理解していることに由来しますが、あなたの経験はさまざまな現実世界のプロジェクトに由来しています。理論と実践の組み合わせがあなたを強くします。

後ほど、参考までに、役立つ内容をいくつか抜粋します (あくまで個人的な意見です)。条件が許せば原書を読むことができ、内容は多すぎず、繰り返し読んで熟考する価値があります。

個人記事

能動的思考、好奇心を持ち、能力を向上させる

原文も 3 つの文です: 好奇心を維持し、自分の仕事について積極的に考え、常にスキルを向上させることを学びます(この言葉は非常に興味深いものであり、そのゲームに対応しています: プログラミングは芸術です)。

これはもう「退化」へと進化しており、巻き上げていかなければなりません。

学習はまた、計画と方法に関するものでもあります。

学習計画には目標を設定することをお勧めします。継続的な学習を維持するために、大きな目標を段階的な小さな目標に分割することができます。

単純な学習は、読むだけでは絶対にできません. 読んで、記録して、要約して、アウトプットするというプロセス.

瞑想的に、つまり批判的思考を持って読み続けてください。

質問の仕方

問題が発生した場合、極端な状況が 2 つあります. 1 つは誰かに直接助けを求めることであり、もう 1 つは多くの時間を一人で費やすことです.

1つ目は、自分自身に感銘を与えて自分の経験を蓄積するのが難しいということです; 後者は多くの時間を無駄にし、それによって他の人や他の人の仕事を遅らせます.

合理的な方法は、最初に何をすべきかを考えてから、答えを見つけることです;答えを見つけるのに時間がかかるが、いくつかの計画やアイデアもあります. 次に、誰かに解決策を依頼し、同僚に解決策を手伝ってもらいます。これにより、双方の時間を節約できます。

最終的な答えは元の考えとは異なるかもしれませんが、計画や考えが正しくて間違っていることがわかり、次は正しい道にすぐにたどり着くことができます。

聞き方、伝え方に注意？対面でのコミュニケーションを優先し、次にメールやドキュメント（私は儀式的な感じがする傾向があります。なぜなら、何か問題があるかどうかを確認するために書いた後に必ず読むからです）、そして IM の順です。しかし、どのようなコミュニケーションが求められるとしても、私は「ピラミッドの原則」をお勧めします。

適切なコードを書き、よく維持されたコードを書きます。重要なことは、仕様を遵守することです

エントロピー増加の法則によれば、ソフトウェアコードとアーキテクチャは常に無秩序の方向に発展します。これには、一般に、コードの設計および記述時に常に仕様を順守する必要があり、「壊れたウィンドウ」に対するゼロトレランスが必要です。壊れたウィンドウは、ソフトウェアの設計不良または不良コードの小さな断片です。

そして、このような小さな「抜け穴」が現れると、常にソフトウェアの保守、拡張、および設計が困難になり、実際の抜け穴であるバグでさえも発生します。これは「カエルをぬるま湯で茹でる」のと少し似ていますが、少し問題があれば問題ないと思いますが、一度このようなたるみが発生すると、後で繰り返されないという保証は困難です。さらに厄介なのは、CV Dafa が優れていることです。このようなコードは無限にコピーされます。履歴書がなくても、厳しい規制によってもたらされる仕事の重複の下で、より多くの同僚が一緒にサボることを選択します (実在の人物と実在の物)。

そのため、概ね期待スペックは5に達し、6に設定するのがベストという感じです。あなたの会社がそうかどうかはわかりません。.

このような問題が発生すると、それを解決するためにさらに多くの努力が必要になります。

規範、ガイドライン、原則、正直に言うと、この種のことを行うのは本当に難しいです。プログラマーの本質は「怠け者」であり、厳密な仕様によってもたらされる余分な労力が最も厄介です。

提案は、常に自分自身に問いかけ、小さなステップで練習し、それを習慣に組み込むことです. コードの品質を覚えておいてください。ソフトウェアの品質も対処する必要がある要件になる可能性があります

要求が多すぎて忙しすぎるので、自分自身に要求を追加する必要はないという人もいるかもしれません。これはもっと具体的なことで、この本でも「10倍プログラマーの仕事法」でも、要件を小さなタスクに分解することで、重要でないものや緊急性のないものを除外して切り捨てることが実際に提案されています。しかし、この粒度は意見の問題です。

変化の「触媒」になる

この点がとても気に入っています。何かが理不尽で、より良い解決策があると感じた場合、それを宣伝して元の方法に置き換えたいと考えます。

ただし、解決策を試すには時間とコストがかかる、解決策があっても、コードを変更するのは面倒、利点と落とし穴が明確でない、一部の大企業では技術的な解決策があるまだ技術委員会によるレビューが必要です。承認します。

合理的に要求できるものを設計し、それをうまく開発します。完成したら、みんなに見せて驚かせましょう。そしたら「増えた方がいいかもしれない……」と言う。椅子に座って、すでに必要な機能を追加するように求められるのを待ちます。人々は、起こっている成功に参加しやすいと感じています。彼らに未来を垣間見せれば、あなたの周りに彼らを集めることができます.

これは、写真付きの大げさなテンプレートである可能性があります。しかし、これには、変更を推進する人がより大きなビジョンを持ち、自分のコードだけでなく、全員の問題点を見る必要があります。

私の個人的なアプローチは、ユーザーの視点から製品設計についてもっと話すこと、プロジェクト全体とチーム間のコラボレーションに注意を払うこと、それについて小さく話すこと、他の人が書いたコードを見てMRについて言及することです. .

プログラムとアーキテクチャの設計

繰り返すことを拒否し、再利用することを選択する

「DRY-Don't Repeat Yourself」の原則は誰もが知っていると思います。

コードの繰り返しと設計の繰り返しは、コードの肥大化を引き起こし、コード変更 (複数箇所の変更が必要) の困難さとリスクを高めます。

繰り返しを避けるようにしてください。以下は一般的な状況です。

コードスニペットの機能は似ています。ツールクラスを抽出できます。
コードモジュールの機能は似ています: ボトムモジュールへの沈み込み
さまざまな言語が同じ機能を実現します: 公共サービスを抽出し、1 つの言語でサービスを提供し、プラグインまたはエージェントを介してアクセスを提供します。
さまざまな開発者が同じ同様の機能を実装しています: 同上.

柔軟なアーキテクチャ

プロジェクトの反復では、関数、データ構造、さらには基盤となるリソースの変更が発生する可能性があります。

設計の初期段階では、コードとアーキテクチャの柔軟性を考慮する必要がある場合があり、統合と展開にまで及ぶと言っても過言ではありません。

ソフトウェア設計の分野では、デカップリング、抽象化、腐食防止層、構成など、このような柔軟性を実現する方法がたくさんあります。

「直交性」、デカップリング

高い結束と低い結合の核心は、階層化、サブモジュール、および抽象化です。

このモジュールはコア機能を一元化し、統一されたインターフェイスを介して外部機能を提供します。

モジュールの外部依存関係は、実装ではなく抽象化に依存することによって分離され、依存ロジックは、コアロジックのサポートを提供するインターフェイスを実装します。

モジュール内のロジックは、それに依存するモジュールに依存しません. 内部ロジックが変更されても、上位モジュールは変更を加える必要はありません.

これは、オブジェクト指向の原則では、デメテルの法則または最小知識の原則に等しいものとして要約できます。

MVP とプロトタイプ

この MVP は、あなたが想像した MVP ではありません。彼は、実用最小限の製品 (Minimum Viable Product)、つまり最も単純化された実現可能な製品を指しています。

中心的な視点は、市場の目標に迅速に対応し、コア機能のみを保持する最も単純な製品を実現し、ユーザーの使用とフィードバックを受け入れてから繰り返すことです。

1 つは変化する市場でホットスポットを見逃さないようにすること、もう 1 つは試行錯誤のコストを最小限に抑えること、3 つ目は不必要な無駄を避けることです。したがって、市場に迅速に参入し、ユーザーのフィードバックに基づいて調整することによってのみ、ユーザーと市場に対応することができます。

研究開発の観点から、機能開発はより合理的であり、継続的統合環境はより完全であり、テスト検証には実際のデータがあります。もちろん、ユーザーからのフィードバックにより、目標はより明確になります。ただし、研究開発チームの要件はより高くなることがよくあります。

対応力のある熱心なチームが必要です。これは一般的にそれほど大きくはありません。そうでなければ、動員にはつながりません。
蓄積されたリソースやプログラムを使用または参照することができます。設計材料、R&D ツール、足場、建築設計ソリューション、または複雑な問題を解決するためのツール。
完全なインフラストラクチャと自動化環境。継続的インテグレーションと継続的展開、自動化されたテスト、グレースケールテスト、およびデータ分析の自動化環境は、新しい市場でのトラフィックの急増のサービス展開と拡大に適応できます。

これまで提唱されていたプロトタイプはデモ用であり、ユーザーに届けることができず、使用後に廃棄されることが多い。多くの場合、実際の製品に必要ないくつかの機能が無視されるためです。

正しさ。プロセスを検証する必要があるだけで、仮説データを使用できます。
威厳。MVP よりも単純で、コア機能の正しいプロセスのみが必要であり、異常なプロセスは必要ありません。
堅牢性。ミスをして直接クラッシュしても問題ありません。
スタイル。

学習目的でのプロトタイピングをお勧めします。

メタデータの設計

「詳細をノックアウト！」

メタデータとは正確には何ですか？厳密に言えば、メタデータはデータに関するデータです。おそらく最も一般的な例は、データベーススキーマまたはデータディクショナリです。

大まかに言うと、メタデータは、アプリケーションがどのように動作するか、どのリソースを使用する必要があるかなど、アプリケーションを記述するデータです。

核となる設計思想は、抽象化をコードに入れ、詳細をメタデータに入れることです. これの利点は、

設計を分離する必要があり、その結果、より柔軟で適応性の高いプログラムが作成されます。
プログラムの外で詳細な処理を延期することにより、より堅牢で抽象的な設計を作成する必要があります。
拡張しやすく、カスタマイズに適応し、変更に簡単に対応できます。

タスクの内訳と見積もり

タスクの分解と見積もりは密接に関係しています。タスクの分解は、需要の理解の制御、需要の進行の制御、および時間管理の制御に役立ちます。タスクが非常に小さい場合でも、自分が中断された場合でも、他の人の中断を一時的に脇に置き、タスクを開発した後に他の人に応答することができます.また、タスクを一時的に中断することもできます.複雑で、進行状況を記録し、中断に対応できます.開発を継続するために戻ってきます。

分解の精度は、ビジネスの理解、要件の理解、過去の経験の蓄積、および自分自身の明確な理解に基づいています. 要件を分析し、タスクを解体するための一連のモデルを要約することもできます.

プログラムコーディング

契約による設計 (DBC)

プログラムの正確性を確保するために、ソフトウェアモジュールの権利と責任を文書化 (および成文化) することに関係しています。正しい手順は何ですか？それ以上でもそれ以下でもない、言われたことを実行するプログラムです。このような宣言の文書化と検証は、契約による設計 (略して DBC) の中核です。

そして、そのような宣言と検証を記述する方法は次のとおりです。

前提条件（前提条件）。プロシージャまたは関数を呼び出すための前提条件が満たされている必要があるのは、呼び出し元の責任です。
事後条件 (事後条件)。プログラムまたは関数が終了することを保証する、終了時のイベントまたは状態。
クラス不変。状態または一連の状態の整合性チェックは内部で維持され、このチェックは、プログラムの実行中に中間状態の正確性を保証するために使用できます; 中間状態がこのチェックに違反することも許可されていますが、最後に、小切手は合格でなければなりません。

これを行うには、入力ドメインの範囲、境界条件、出力データの形式と範囲、および入力と出力の方法を設計時に考慮する必要があります。

保証は、アサーション、前処理、早期リターンエラー、およびクラッシュによって実現できます。

継続的なリファクタリング、小さなステップでのリファクタリング

いつでもリファクタリングできますが、早ければ早いほどよいでしょう。

重複、結合、古いロジック、パフォーマンスの問題、不適切な仕様が見つかった場合は、リファクタリングを選択できます。

一度にすべてをリファクタリングするのではなく、少しずつ変更を加えることができますが、それは苦痛だと思います。時間がかかるし、最初から中断することはできない. 完了するか、すべてを返す. リファクタリングは、クラスとメソッドを抽出するCVメソッドかもしれません.多すぎると、繰り返しの作業が退屈になります。また、スモールステップのリファクタリングは、何か問題が発生した場合でも、単純に戻って再設計できます。

そのため、スモールステップのリファクタリング、リファクタリング後にテストに合格する必要があることを確認するための完璧なテストなどのスキルに注意してください。

リファクタリング中に新しい機能を追加しないという提案もありますが、小さな変更に絞り込む場合は、要件に従ってテストし、日常的に行うことをお勧めします。重要なのは、より良いコードを記述し、継続的に最適化する習慣を身に付けることです。

テスト容易性とテストケース

多くの人が、私と同じように単体テストを書くのが嫌いだと思います。単体テストは通常、コアロジックまたは複雑なロジックをカバーすることを考えると、なぜそれほど困難なのでしょうか?

コアロジックの大部分は適切に記述されておらず、外部の「重い」実装に依存している可能性があります。他のものと混在している可能性があり、結果として複雑さが増しています。

私は個人的にテスト可能なコードを書いています. 重要なのは、コアロジックメソッドが限られた適切な数の入力と出力であることです. このようにして、考えられるすべての入力と出力を徹底的に列挙して、テストケースを作成することができます。

プログラムの並行性とワークフロー

時間は、ソフトウェアアーキテクチャの見落とされがちな側面であり、ソフトウェア自体の設計要素としての時間の役割です。

並行性: 複数のイベントが同時に発生する
シーケンス: 時間内のイベントの相対的な位置

特にインターネットの開発と設計において、並行性は無視できない要素であり、設計の初期段階で考慮しなければなりませんが、並行性の競合を防ぐにはどうすればよいでしょうか? 高い同時実行性を確保するには?

同時実行の競合を防ぎ、同時実行を改善するために考えられる原則は、UML アクティビティ図を通じて分析できるワークフローを分析することです。

また、並行プログラミングでは、マルチプロセス、マルチスレッド、マルチコルーチンを考慮に入れる必要があり、サーバー側アーキテクチャの設計では、並行性の高さ、拡張と縮小の方法なども考慮する必要があります。

システムのパフォーマンスと複雑さの見積もり

システムパフォーマンスは、CPU 負荷、処理時間、メモリ負荷、ディスクの読み取りと書き込みなど、測定が難しい場合があります。一般に、既存の知識と経験が見積もりに役立ちます。

さらに、アルゴリズムの推定、つまり複雑性分析と Big O 記法を通じて、あいまいな認識を取得します。

計画

合理的なニーズ

これはより賢明です。いろいろなプロセスを非常に明確に書く必要性にも遭遇しました.ステータス表示を追加するために文章を直接投げる人もいます.スタイルは別の場所と同じです. 本当に、兄弟、これは同じものではありません。同じになる方法はありません。

そのため、ニーズを理解し、現象を通して本質を見抜き、ユーザーの視点で問題を捉える必要があります。R&D が受け取る要求は、製品がビジネス上の問題を受け取った後に処理されるソリューションだからです。製品のアイデアと研究開発のアイデアは矛盾する場合があり、製品はデザイン、相互作用などを考慮し、研究開発は変更のリスクと作業負荷を考慮します。

しかし、目標は団結、問題解決です。問題が何であるかがわかれば、それが一時的なもので簡単にできるのか、それとも非技術的な手段を使用できるのか、おそらくコアの魅力を簡単に解決できる既製の手段があるかどうかを考えることができます。

第二に、問題のクラスを解決したいのか、特定の問題を解決したいのかを知ることができます。

指定された担当者のみがファイルを閲覧できる【良い】

そのような需要が来ると、開発者はその後の拡張を容易にするための権限管理システムを設計します。

ファイルを閲覧できるのは幹部と人事部だけ【悪い】

このような需要が発生した場合、開発者は単純な構成を行い、事前静的検出を実行するだけで済みます。

要件が変わる限り、満たされない可能性があり、コードも変更する必要があります

前者の表現は、設計時にスケーラビリティと互換性を考慮することを促します。したがって、詳細よりも抽象化を選択します。

私が非常に重要だと思うのは、製品とのコミュニケーションにおいて、語彙の統一性を明確にする必要があるということです。

製品にはAと書いてありますが、設計時にR&Dが英語表現を考慮することもあるかもしれませんが、完全に一致する語彙がないため、Bを使用しています。ただし、B の翻訳は A とは異なるため、製品は A と言い、R&D は B と言う状況につながります。

シーンに最も特化した語彙を持ち、ビジネス分野の独自の語彙を使用するようにする必要があります。

より多くの準備

要件を聞いても設計できない場合はそれを把握し、計画を設計してもコードが書けない場合は、どこにまだ問題や欠陥があるかを考えます。

よく考えないと、やり直しや無駄な作業につながる可能性があるからです. 1、2 か月後に、すべてが間違っていたことに気付くと思います。

仕様

プログラムの仕様書を書くということは、プログラマーが引き継げる範囲まで要件を減らし、最終的に誰もが受け入れることができる合意を形成するプロセスです。

これは実際には非常に重要で、特に複数人での共同プロジェクトでは重要です。

インフラストラクチャ、自動化

メタデータの設計には構成センターが必要な場合があります。単体テストにはカプセル化された使いやすい足場が必要な場合があります。自動化された CI/CD の構築、コンパイル、テスト、コード品質検査、ミラーまたは jar の構築、展開、さらには自動化されたテスト、グレースケールの展開テスト、など。

これは、持つべきか、持つことができると私は信じています。

完全なテスト、自動化されたテスト

自動テスト、早期テスト、頻繁なテスト、テストがコーディングの大部分を占めます; プロジェクトには単体テストと統合テストが必要です; コアシステムにはパフォーマンステストとストレステストも必要な場合があります; ある程度のカバレッジが必要です.

ドキュメントとメモ

ドキュメントは適切に維持されるべきであり、落とし穴は残されるべきではありません。まじめな話、システムを乗っ取ったり、ドキュメンテーションなしで会社に入社したりしたら、考えるのがどれほど苦痛で、コードを見ることしかできません。ふふ、そしてコメントがないことに気づき、手を投げて立ち去るかどうかわかりません。

大学生の頃は、プログラミングの前に先生が関連するドキュメントを教えるべきだったのを覚えていますが、教えないと逃げられません。

ドキュメントまたはコメントが古くなっている場合は、時間内に更新するように注意してください。

真実は理解されていますが、誰もが書きたがりません。ブログを書くことから始めて、ゆっくりと文書を書くことを開発してください。

一緒にアウトプットして、お互いに高め合って、レベルアップしていきましょう！! ! 小さな目標は最初にレベル 2 に進みます。

要約する

この本を読み終えてから 1 か月が経ちましたが、まだ整理していません。

この要約の構造は、本書の構造と必ずしも同じではありません. これは、私の個人的な分類と個人的な理解の結果です.

違う考えや意見があれば、議論を歓迎します。相互激励！