22死は存在しない
の早期崩壊を。（ゴミ）を破壊しないで、間違ったデータを書き込みます
プログラミング23アサーション
それが起こることができない場合、アサーションと必ず、それは起こりません。
副作用アサーションを持っていません
例外を使用する24
の要件を理解することは、異常が不測の事態のために予約されています
どのようにリソースをトリミングする25
のコースに滞在する：リソースの割り当ては、それを使用し、それを解放
ネストされたディストリビューション（だけでなく、ワンタイムリソース）
・ リソースが別のリソースへの参照が含まれている場合、オーダーと資源配分の割り当てを解除リソースを逆にするには、それが放棄されているリソースにはなりません
。・ コードの異なる場所でのリソースの同じセットを割り当て、彼らは常に同じ順序を割り当てられていますこれは、デッドロックの可能性を削減します。
26デメテルとデカップリングするルール
デメテルの法則は、モジュール間の依存性を減らすことができますが、デリゲートメソッドは、独立したコードを高めるだけでなく、コードの実行速度に影響を与えるので、様々なニーズに応じていないだけで表示される多くをもたらすでしょうが、あまりにも従うことシーン妥協は、改善された性能を獲得する規範に違反します。
プログラミング27元
のメタデータを
・ メタデータ（メタデータ）：アプリケーション・コンフィギュレーション・オプションの説明：チューニングパラメータ、ユーザの嗜好が
- 厳密な意味でのメタデータのデータであり、広義には、任意のアプリケーションにデータを記述することです。（好みに加えて、リソース、等がある）
・ メタデータは、実行時ではなく、コンパイル時にアクセスされ、使用されています。
抽象コード手順で要素の詳細
時間28を結合します
プログラムの開始時間は、オーダーを実行することです。必要によって複雑いったんしかし、トラブルがありました。
使用UMLのアクティビティ図、分析のワークフロー。
29それはちょうど見
除算の概念に基づいて、私たちをして、プログラムを支配するには、いくつかのモジュールに分割されていますが、どのように管理組織は、異なるモジュール（クラス）との間で問題を依存していません。
私たちは、関心の対象に新しい変更を送信するために、イベント（イベント）の概念から進みます。、
（機能インターフェースは、オペレーティングシステムのAPIとしてシステムの外部に設けられたルーチンまたはサービスの集合であり、したがってサービスルーチンである）Baiduの百科事典からのルーチンを介してください。その後、さまざまなオブジェクト間の相互作用を知るためのルーチンの必要性は近い理解しています。もちろん、我々はサブスクリプションモデルを使用することができます/リリースは、加入者がそれに興味のあるイベントのみを受け入れることができます。
CORBAイベントサービスオブジェクトが通知チャネル（公共バス）を送受信することによって、イベントに参加することを許可されています。
MVC（モデル - ビュー=コントローラ）モードを効果的にモデルがGUIから分離し、制御管理ビューから分離します。
モデル：アイコンは抽象データモデルオブジェクトを表します。任意のビューまたはコントローラへのモデルのは直接の知識がありません
どのようにモデルを説明する：ビューを。これは、コントローラから与えられたビジネス・モデル論理的イベントを変更する
コントローラ：ビューを制御します。パスウェイのモデルは、新たなデータを提供します。また、モデルを表示するためのイベントを発表しました。
黒板次のセクションを参照するには、まだ結合された、愛があります。
30黒板
手がかりの事例を扱う探偵情報は特性の黒板黒板方法に掲示することを指摘した：
-追加のオブジェクトは、彼らが黒板からの情報を表示し、その調査結果を追加し、他のオブジェクトの存在について知っておく必要がありません。
-例の事件を解決することであるとして使用黒板のオブジェクトまたはモジュールは、同じ目標や機能を中心に一つの共通点を持っています。
複雑なワークフローのために、我々は調整するために黒板ことができます。
・ 受注データが到着無関係です
。・ トリガ適切なルールは、特定の事実を受け取ることになります。
偶然の一致で31プログラミング
一致プログラミングに頼ることができないのはなぜ（仕事に開始を参照）。
・ この知識は本当に偶然の仕事に頼っていないことを境界条件は、他の条件で作業することができないかもしれない
- 文書に入力されていませんが、ライブラリの変更の次のリリースに振る舞うこと
・ 余分な呼び出しが遅くコードを作るために
・ 過剰の呼び出しはバグ導入することができる
意図的なプログラミングを
・ 彼らが何をしているか、常に意識
・ 完全に理解し、なじみのない技術を使用していない盲目的ビルドアプリケーションにプログラムされていない
・ 系統的、計画に従って行動！！！
・ このような固体ライブラリとして信頼性の高いもの、に依存しています。
・ 文書あなたの仮定を確立します。
・ あなたが優先順位付けのために働く、重要かつ最も難しい側面に費やした時間。
・ 歴史のない奴隷は、適用されない既存のコードに参加し、できるだけ早く交換します。
32レートアルゴリズム
リソースアルゴリズムの場合。処理、メモリ見積もり。
我々が上限設定値を測定するもののO（）表記。
いくつかの一般的なO（）表記
O（1）
O（LG（N））
O（N）
O（NLG（N））
O（N ^ 2）
O（N ^ 3）
O（C ^ N-）
一方我々あなたは、アルゴリズム設計をソート記述する必要はありませんが、有利な推定アルゴリズムの順序は、私たちは、自分の書かれた手順の動作のいくつかを理解しています
33復興
再建リライタブル= +再+アーキテクチャやり直し
ときに再構築されました：
・ リピート（DRY）
* 非直交設計
・ 時代遅れの知識
・ パフォーマンス
、多くの場合、早期復興、再構築されました
どのように復興：
・ Doがリファクタリングに増加していない
・ あなたは、多くの場合、可能な限りこれらのテストを実行し、復興の開始前に問題のように早期発見を良いテストを持っていることを確認します。
・ 長時間のデバッグを避けるために、各工程の後に短い手順やテストを受けます。
テストコードに簡単34
ユニットテスト：契約のためにテストします。
テストのために設計されています：
契約の両方のコードは、契約をテストするように設計されていても、単一のルーチン設計モジュール設計。
35の邪悪なウィザードは、
ウィザードにあなたが理解していないコードを使用しないでください
ピットの36枚の要件は、
それらのマイニング、収集しない需要を行います。
彼らのニーズを表現し、宣言文をクリアする必要があります。時々要求する文は、商業政策を運び、商用のポリシーは常に変化しています。だから我々は、ニーズやビジネスポリシーを区別するために行う必要があります。
ユーザーインターフェースを議論では、需要、政策と実施の差が不鮮明になることができます。
主な
ユーザーではなく、彼らは現在、この事の道をやっているよりも、特定の物事を行う理由を見つけるために。
システムの特定の使用を記述するためのユースケース（ユースケース）：要件ドキュメントを確立します。
対応する例のテンプレート
詳細よりも長く生き抽象
通信に資する用語集プロジェクトを、維持します。
37のパズルを解明することは不可能ロックを解除するには
困難な浮遊出会いを解決するとき、解決策は、あなたの現在の考え方の範囲内ではないかもしれません。それは拘束の再決定方法に必要であるので、いくつかの制約が絶対的な制約され、制約がいくつかの先入観です。
ボックスの外側を考えてはいけない-ボックスを見つけるために：私たちは自由の問題を特定する必要が制約されている
トロイの木馬について考えること
もっと簡単な方法があるに違いありません
・ 簡単な方法はありますか？
・ あなたはまだ問題を解決しようとしていることは技術的な問題の迂回注意外部にある
- これは、なぜ物事が質問される
。・ 何が困難解決できる
- それがそのような方法で行われなければなりませんか？
・ それは本当に正しい行う必要がありますか？
38あなたは準備が整いました
定期的な疑問を聞いて-あなたは再び開始する準備ができています
良い判断や遅延
遅延- ：コンセプトの証明に「無駄時間の」退屈が現れる
-良い判断力、プロトタイプの進展に伴い、我々はいくつかの点で啓示を得るために喜んでいる、突然前提に意味が間違っています。
39仕様トラップ
いくつかのもののために、むしろ「説明」よりも「やって」
40円、矢印
スレーブ方式の形ではありません
私が使用されるツールは、単なるツールです。