この投稿は、Peter Goodlif の著名な著書「The Craft of a Programmer 」の「黄金律」からの抜粋です。
誰かが記憶をリフレッシュし、誰かがチェックリストと相談し、誰かが興味を持ち、本を読むでしょう。 なぜなら 投稿は非常に膨大であることが判明したため、ブックマークに追加して定期的に戻ることができます。
第1章防衛を保持する
仮定をしないでください。 正式に修正されていない仮定は、特にコードサイズが大きくなると、しばしば失敗を引き起こします。
急ぐほど速度は低下します。 キーボードから入力する内容を常に考えてください。
誰も信じないでください。 あなた自身を含め、誰でもあなたのプログラムのロジックを間違える可能性があります。 あなたは、それらが有効であることを確認するまで、すべての入力と出力を疑っています。
コンパイラの警告は、膨大なエラーを特定するのに役立ちます。 常に出力を含めます。 コードを静かにコンパイルしてください。
制限されたすべてのリソースを保存します。 キャプチャとリリースを慎重に整理します。
第2章微妙な計算
あなたのソースコードを実際に読むのは誰なのか：他のプログラマーを理解してください。 それらを期待して書いてください。
選択した言語のコード標準を確認し、実際にそれぞれを習得してください。 それぞれの長所と短所を評価します。
正しいコーディングスタイルを1つ選択し、常にそれに従うようにします。
グループが特定のコーディング標準を採用している場合は、それに従ってください。 自分の好きなスタイルを残してください。
宗教戦争にノーと言う。 それらに入らないでください。 離れて。
第3章私の名前は何ですか？
オブジェクトに透明な名前を付けることを学びます-オブジェクトの背後に隠されているものを明確に記述する必要があります。
良い名前を思い付くために、主なことはそれが誰のために意図されているかを明確に理解することです。 この場合にのみ、名前が意味を持つようになります。 オブジェクトの適切な名前を思い付かない場合は、その目的が明確かどうかを自問してください。
使用する言語での命名規則を学びます。 さらに重要なのは、この言語のイディオムを学ぶことです。 名前を形成する標準的な方法はありますか？ それらを使用します。
名前の明瞭さは、その簡潔さよりも望ましいです。
特に変数のスコープに応じて、短い名前と長い名前の相対的なメリットを考慮する必要があります。
変数名と型名を区別する命名規則が望ましいです。
外部の観点から、アクションを表すフレーズの形式で関数名を付けます。 論理演算を説明します。実装する方法ではありません。
名前に不要な単語を使用しないでください。 特に、タイプ名-クラス、データ、オブジェクト、タイプなどの単語。
コンテンツに論理的に関連する名前空間とパッケージ名を付けます。
C / C ++のマクロは常にわかりやすくするために大文字で表記され、競合を避けるために名前は慎重に選択されています。 他のオブジェクトを大文字にしないでください。
一貫した命名システムを選択し、一貫して適用します。
名前に必要な詳細度は、アプリケーションのコンテキストによって異なります。 名前を作成するときは、コンテキスト情報を考慮してください。
第4章文学批評
外部ドキュメントを必要とするコードを書かないでください。 彼は信頼できません。 無関係なドキュメントなしで理解可能なコードを記述します。
通常の人がストレスなく読むことができるコードを書きます。 コンパイラは何らかの形で対処します。
マジックナンバーを避けてください。 名前付き定数を使用します。
コードの重要なセクションは、一般的な背景に対して目立つようにし、読みやすくする必要があります。 顧客の興味を引くべきではないものをすべて隠す。
関連情報をグループ化してください。 言語ツールを使用して、このグループ化を視覚化します。
意味のないエラーメッセージを表示しないでください。 コンテキストに応じて、最も関連性の高い情報を提供します。
他の方法で理解を促進することが不可能な場合にのみ、コードにコメントを入れてください。
適切なドキュメントツールを使用して、コードのドキュメントを自動的に生成します。
第5章マージンノート
必要なだけコメントを書くことを学びます。 量よりも品質を優先します。
時間をかけて、多くのコメントの形でコードがサポートを必要としないことを確認してください。
良いコメントは、理由ではなく、理由を説明しています。
各ファクトに対して1つのソース。 コメント内のコードをコピーしないでください。
自分のコードを説明する詳細なコメントを書いている自分を見つけて、やめて考えてください。 これは、高次の特定の問題があることを示していますか？
あなたがコメントに書いていることを考えてください。 むやみにキーを押さないでください。 コードのコンテキストでコメントをもう一度読んでください。 情報が含まれていますか？
コメントはコードの一部です。 読み上げ順序が自然になるように配置します。
各ソースコードファイルにコメントとしてプロローグを提供します。
コメントは過去ではなく現在に関連する必要があります。 何が変わったのかを説明せず、以前に何が起こったのかについて話さないでください。
コードを変更した場合は、その隣のコメントが正しいことを確認してください。
第6章人々は間違いを犯しがちです
エラー処理は重大な問題です。 コードの安定性はそれに依存します。
失敗した状況を放置しないでください。 問題の対処方法がわからない場合は、呼び出し元のコードに失敗を通知してください。 すべてが何らかの形で機能することを期待して、カーペットの下にゴミを一掃しないでください。
受信したエラーメッセージを無視しないでください。 エラーメッセージ用のチャネルがある場合、これには理由があります。
正しく対処する方法が明確になったら、最も有利なコンテキストですべてのエラーを処理します。
エラーを無視しても時間を節約できません。 エラーハンドラを記述するよりも、プログラムの不正な動作の原因を突き止めるのに時間がかかります。
失敗する可能性のあるコードを記述する場合は、同時にコードを記述してエラーを検出して処理します。 将来のために先送りしないでください。 それでも処理を延期する必要がある場合は、少なくともエラーを検出するスナップインを作成します。
第7章プログラマーツールキット
標準ツールを幅広く学びましょう。 学習に費やす時間はすぐに報われます。
プログラミングツールを実用的に扱う。 それらがあなたの生活を楽にする場合にのみ使用してください。
どんな種類のツールが存在するかを調べてください。 現時点では必要ない場合でも、どこで入手できるかを確認してください。
各タスクには独自のツールがあります。 ハンマーでナットをクリックしないでください。
ツールの最新バージョンにご注目ください。ただし、更新時には注意してください。
コードエディターの選択は重要です。 コードの書き方に大きな影響を与えます。
いくつかの言語を学びます。 それぞれに、問題を解決する特別な方法があります。 それらをツールのセットと見なし、特定の状況で最も効果的なツールを選択します。
第8章テスト時間
テストでは、エラーの存在のみを明らかにできます。 障害がないことを証明することはできません。 コードが多数の不適切なテストに合格した場合、落ち着いたという誤った感覚に屈しないでください。
書いたコードをすべてテストします。 他の誰かがあなたのためにこれを行うことを期待しないでください。
テストを効果的にするには、検出されたエラーがまだ大きな害を及ぼさないときに事前にテストを開始する必要があります。 テストコードは動作する前に書くことができます！
特定されたすべてのエラーのテストを作成します。
できるだけ頻繁にテストを実行してください。
コードを読むことは非常に簡単に欺くことができ、正しく動作すると信じています。 コードを書いた場合、それを読むと、実際に書いたものではなく、何を書くつもりだったかがわかります。 シニカルな不信感を持ってコードを読むことを学ぶ。
テストの完全なセットを作成します。各テストは、コードの特定の側面をテストします。 同じエラーを示す15個のテストは、15個の異なるエラーを示す15個のテストよりも有用性が低くなります。
コードアーキテクチャにより、テストが容易になります。
コードテストを可能な限り自動化します。 これは、テストを手動で行うよりも速くて簡単で、はるかに信頼性が高くなります。テストが定期的に実行される可能性が高くなります。
ビルド手順中にテストを自動的に実行します。
第9章トラブルシューティング
コンパイラがすべての警告メッセージを表示したら、コードをコンパイルします。 したがって、実際に遭遇する前に潜在的な問題を発見します。
デバッグの黄金律に従ってください。頭で考えてください。
「非体系的な」デバッグに適切な時間制限を設定し、失敗した場合は、より系統的な方法に切り替えます。
デバッグされたコードを調べる-理解できないコードのエラーを見つけるのは困難です。
あなたが間違いを探すとき、誰も信じない。 すぐに拒否するのではなく、最も信じられない理由を確認してください。 当然のこととは思わないでください。
製品のビルドが失敗した場合は、最初のコンパイラエラーを確認してください。 後続の投稿の信頼性ははるかに低くなります。
デバッグは系統的な作業であり、エラーの場所の周りのリングを徐々に狭めます。 彼女をキャディーのゲームのように扱うべきではありません。
エラーの場所を特定する最初のステップは、エラーを確実に再現する方法を決定することです。
たとえば、プログラムの異常終了のポイントなど、既知の場所から開始します。 次に、障害の原因に向かって後方に移動します。
エラーの原因を見つけたと思われる場合は、徹底的に調べ、間違いを犯していないことを確認してください。 最初の仮説をむやみに受け入れないでください。
エラーが解決され、問題が永久に解決されたことを証明した場合にのみ、デバッグが終了します。
エラーを修正するときは細心の注意を払ってください。 変更によって他に障害が発生しないことを確認してください。
エラーを修正し、コードの近くのセクションで繰り返されるかどうかを確認します。 エラーを完全に排除します。すべての重複をすぐに修正します。
修正された各エラーから、結論を導き出します。 回避できたでしょうか？ より速く検出できますか？
説明できない動作に直面した場合は、デバッガーを適度に使用してください。 コードがどのように機能するかを最初に理解しようとせずに、すぐにそれらに急ぐことに慣れないでください。
第10章構築されたコードジャック
ビルドシステムをソースツリーの一部と見なし、それらをまとめます。 それらは密接に関連しています。
プロジェクトに関与するすべてのプログラマは、単一のビルドシステムを使用する必要があります。 そうでなければ、それらはすべて異なるソフトウェアパッケージをコンパイルします。
正しいビルドシステムを使用すると、物理的に同一のバイナリファイルを繰り返し作成できます。
3年前にソースツリーを取得し、再び正しくアセンブルできるはずです。
正しいシステムは1つの操作のように見えます。 ボタンを押すか、1つのコマンドを実行するだけで十分です。
アセンブリルールごとに、操作全体をキャンセルする適切なクリーニングルールを記述します。
ソフトウェア製品の自動ビルド手順を整理します。 コードの操作性をヘルプで確認してください。
最終ビルドは常にクリーンなソースコードから実行されます。 後で、アーカイブまたはバージョン管理システムからこのクリーンなソースコードをいつでも入手できることを確認してください。
動作しているアセンブリだけでなく、アプリケーションの最終構成をテストします;アセンブリ間のわずかな違いは、コードの動作に悪影響を与える可能性があります。
第11章スピード渇望
プログラムの最初から有効性について考える必要があります-開発の終わりに小さな変更をすることでそれを増やすことができると期待しないでください。
コードの正確さは、速度よりもはるかに重要です。 結果が間違っている場合、すぐに結果を取得する方法は何ですか？
最適化の代替案を検討してください。 他の方法でプログラムの有効性を改善できますか？
コードを本当に最適化する必要があるかどうかを調べますが、最初から効果的で高品質のコードを書く方が良いでしょう。
ある作業の結果が別の作業に影響しないように、他の作業とは別にコードを最適化します。
中間ビルドではなく、プログラムの最終バージョンを最適化します。
プロファイリング用の入力を慎重に選択して、実際の世界を反映するようにします。 そうしないと、通常は実行されないプログラムの部分を最適化していることが判明する場合があります。
プログラムの有効性が不足している理由を検索するときに、プロファイラーに限定しないでください。 より深いかもしれません。
最適化の前後に必ず測定を行ってください。
既存のアルゴリズムの実装を改善しようとするよりも、低速のアルゴリズムを高速のアルゴリズムに置き換えることをお勧めします。
第12章不安定なコンプレックス
あなたが持っている重要なリソースを覚えておいてください。 捜索できる特別な機密情報や特別な機能はありますか？ それらを保護します。
コンピュータシステムが複雑になるほど、セキュリティシステムにギャップが生じる可能性が高くなります。 したがって、できるだけシンプルなソフトウェアを作成してください！
脆弱性を通り過ぎたり、自分を無敵だと考えたりしないでください。 コードにエクスプロイトを適用しようとしている人がいます。
コンピューター上の信頼できるソースからのプログラムのみを実行します。 ソースの信頼性を決定するための明確なポリシーを確立します。
セキュリティは、ソフトウェア製品の重要なアーキテクチャの側面です。 開発の初期段階でそれを大事にしないのは間違いでしょう。
プログラムを設計するときは、既知の安全なサードパーティコンポーネントのみに依存してください。
システムを攻撃する準備をし、これを念頭に置いてシステムのすべての部分を設計します。
第13章デザインの重要性
プログラミングは設計作業です。 これは創造的で芸術的な行為であり、機械的なコーディングではありません。
キーをノックする前に考えてください。 わかりやすいプロジェクトを作成します。 そうしないと、コードではなく混乱が生じます。
少ないほど良い。 あなたの目標は、小さなサイズで大きな問題を解決する単純なコードでなければなりません。
シンプルなものを作るのは難しいです。 コードの構造が明らかな場合は、簡単だとは思わないでください。
内部で接続され、相互接続が最小限のモジュールを設計します。 分解は、タスクの部分への正しい分割を反映する必要があります。
誰も横断すべきではない線を引きます。明確なAPIとインターフェースを定義します。
その後の拡張を考慮して設計しますが、無理しないでください。そうしないと、プログラムではなくOSを作成します。
一度やってください。 よくやる。 重複を避けます。
完成したコードを修正するのではなく、設計段階でコードの移植性の問題を解決します。
設計ツールと方法論について実用的にしてください。本当に便利なときに使用しますが、奴隷にならないでください。
第14章ソフトウェアアーキテクチャ
アーキテクチャは、ソフトウェアシステムの設計とさらなる開発に最大の影響を与えます。 このため、開発の非常に早い段階で正しく判断することが重要です。
システムアーキテクチャの説明は、保守とインストールを担当するプログラマ、管理者、そして場合によっては顧客など、必要な人が利用できる場所に保管してください。
アーキテクチャ仕様は、システムのステータスを報告するための重要なツールです。 ソフトウェアの状態と一致していることを確認してください。
アーキテクチャのコンテキストでソフトウェア製品のすべての設計決定を行います。 体系的なビジョンと戦略から逸脱しないように注意してください。 関係のない小さな変更を加えないでください。
優れたシステムアーキテクチャはシンプルでなければなりません。 1つの段落と1つの単純な図で構成される説明で十分です。
アーキテクチャは、システムの最も重要なコンポーネントとそれらの相互作用を定義します。 彼女は彼らのデバイスを説明していません。
優れたアーキテクチャには、操作、拡張、修正の余地があります。 しかし、彼女のコミュニティは合理的な境界を越えていません。
基本的なアーキテクチャスタイルを理解し、その長所と短所を評価します。 これは、出くわしたソフトウェア製品に共感し、システムを正しく設計するのに役立ちます。
第15章ソフトウェア—進化か革命か？
簡単に変更可能なコードがどれだけ劣化するかを覚えておいてください。 システムの状態が悪化する前の変更は避けてください。
壊れたコードを検出する方法を学びます。 その症状を調べ、分解されたコードを細心の注意を払って処理します。
コードを書くことについて正直に。 優秀なプログラマーは、数年後にコードがどのように見えるかを考えますが、今日どのくらい努力する必要があるかについては考えません。
将来変更する可能性を考慮して、新しいコードを作成します。 明確で、拡張可能で、シンプルにします。
変更するときは注意してください。 誰かが近くのコードを変更しているかどうかに注意してください。
特に新しいバージョンをリリースする準備をしているときは、危険な変更について話します。 最も単純な変更でさえ、他のコードの動作を混乱させる可能性があります。
コードを軽率に叩かないでください。 停止して、あなたが何をしているかについて考えてください。
どんなに簡単であっても、すべての変更を徹底的にテストします。 愚かな間違いを見逃すのはとても簡単です。
第16章エンコーダー
あなたがどんなタイプのプログラマーであるかを調べてください。 自分の良い資質をいかに活用し、悪いものを補うことができるかを決定します。
第17章一緒に私たちは力
チームで働く能力は、高度な資格を持つソフトウェア開発者の重要な品質です。
結果のコードは、チーム内の関係と外部の連絡先の両方の影響を受けます。 それらがあなたの仕事にどのように影響するかを見てください。
構築しようとしているコードに従ってチームを編成します。その逆ではなく、既存のチームに従ってコードを編成します。
効果的なコミュニケーションのためのチャネルの存在は、チームの通常の仕事にとって不可欠です。 そのようなチャネルは、整理および維持する必要があります。 優れたプログラマーは、うまくコミュニケーションできるはずです。
コードの一部を所有するプログラマはいません。 各参加者はコード全体にアクセスでき、必要に応じてコードを変更できます。
成功するチームは、意図的に開発および作業します。 それらの発生は偶然によるものではありません。
人々がチームを離れるときに情報を失わないでください。 転送を整理し、コード文書、テストツール、メンテナンス手順など、重要なデータをすべて受け取ってください。
第18章ソースコードの保護
コードには価値があります。 敬意と注意をもって彼を扱ってください。
バージョン管理システムは重要なソフトウェア開発ツールです。 信頼できるチームワークのために必要です。
リポジトリに注意してください。 他の開発者が作業できないような非アクティブなコードを記述しないように注意してください。
データをバックアップします。 災害が発生するのを待たずに復旧戦略を開発します。
第19章仕様
ソフトウェア開発プロセスには、仕様だけでなく、その高品質も必要です。
仕様は、ソフトウェア開発者間の重要な通信メカニズムです。 紛失したり忘れたりしてはならない情報を記録するのに役立ちます。
機能の拡張を妨げ、開発者の不安を軽減するために、不当な期待が生じないように、ソフトウェア要件を事前に設定する必要があります。
プログラミングタスクが明確に定義されていない場合は、仕様を記述して同意するまでコーディングを開始しないでください。
優れたプログラミングツールを使用して、技術文書を編集します。 すぐに陳腐化するドキュメントをテキストエディタで書かないでください。
仕様をコンパイルするときは、その内容を考慮してください。 聴衆が理解できる構造と語彙を選択し、ドキュメントが正しく、完全で、独自の説明が含まれていることを確認してください。
指定を避けることは危険で専門的ではありません。 仕様を書く時間が足りない場合は、おそらくコードを書くだけでも十分ではありません。
第20章撮影のレビュー
コードレビューは、隠れたエラーを見つけて排除し、コードの品質を向上させ、コードに対する集団的責任を強化し、知識を広めるための優れたツールです。
システムを作成するときに、確認する必要があるかどうか、必要であればコードを確認してください。
レビューするコードを慎重に選択します。 コード全体をレビューできない場合は、十分な情報に基づいて選択してください。 ランダムに選んで貴重な時間を無駄にする必要はありません。
どのようなコードが書かれていても、同僚によるピアレビューと慎重な研究の対象となります。 コードのレビューを取得します。
レビューの成功は、著者とレビューアの肯定的な位置に大きく依存しています。 レビューの目的は、コードを共同で改善することであり、加害者を任命したり、実装中に下された決定を正当化したりすることではありません。
良いコードがどのように見えるべきかわからない場合、他のプログラマーの作業の質を合理的に判断することはできません。
第21章ロープの長さは？
ソフトウェア製品の開発期間の推定は事実に基づいた推測です。 評価ごとに、それに対する自信の尺度があります。
ソフトウェア開発時間を見積もることは本当に難しい作業です。 今後の作業量を過小評価しないでください。 誤った評価の結果の可能性を考慮してください。
皆さん（あなたを含む）は、速記スケジュールを望んでいます。 割り当てられた時間内に本当にできることについてだまされないでください。 配信の準備ができているコードを提供する必要がある場合は、非現実的な約束をしないでください。
時間の見積もりは、ワークロードが理解しやすい小さなタスクに適用する必要があります。 測定単位は、工数または工数にする必要があります。
時間の観点から評価している作業を区別します。自分の（あなたがよく理解しているシステム上で）または他の誰か（システムを勉強する必要がある人）。
単独で評価しないでください。 他の人の意見を調べて、評価を明確にしてください。
コードをクリーンアップする時間があるように、作業をスケジュールします。 技術的負債を返済するための計画。
計画の進捗状況を常に確認してください。 その後、突然検出される遅延はありません。
第22章プログラムのレシピ
優れたプログラマーはプログラミングの方法を知っています。仕事の方法とテクニックを知っています。
当社のソフトウェアプロジェクトは、適用するスタイルとプロセスによって決定されます。 それらはコードの形式と品質に必然的に影響します。
開発プロセスがなければ、チームは無秩序状態にあります。 プログラムは、ターゲットアクションの結果としてではなく、運のために表示されます。
処方プログラムの選択は、多くの理由で決定できますが、それは良いことです。 あなたの選択の動機は、あなたの組織がどれほど成熟しているかについて多くを語っています。
受け入れるプロセスは、形式的すぎて実装が困難であってはなりません。 通常、良いプロセスの兆候は、ちょうど反対の特性です。 ただし、特定のプロセスが必要です。
プロセスの選択は不可欠です。 ほとんどの場合、失敗したプロジェクトは技術的な理由によるものではありません。 ほとんどの場合、主な理由の1つはプロセスの不十分な組織化です。
第23章可能性を超えて
さまざまなサブジェクト領域にさまざまなタイプのプログラミングがあります。 各エリアには独自の特別な問題があり、特定のスキルと経験が必要です。
プログラミング分野を知ってください。 その詳細を調べてください。 彼女のニーズに合った素晴らしいプログラムを書くことを学びましょう。
第24章次は何ですか？
優れたプログラマーになるには、正しい位置、つまりソフトウェアの作成が考慮される角度を選択する必要があります。
スキルを向上させます。 プログラミングへの愛とそれをマスターになりたいという欲求を失ってはいけません。