実用主義プログラマー第4章「実用主義編集証」

Today reading range

-今日読んだ範囲
実用主義プログラマー第4章「実用主義編集証」

Impressive content

-印象的な内容
実用主義プログラマー自身も信じない.誰もが、完璧なコードを書くことができないことを知っているので、実用主義プログラマーは自分の誤った防犯措置を説明します.146p.

Topic23. プロトコルの設計

DBCDesign By Cotractは、ソフトウェアモジュールの権利と責任を記録し、協議し、プログラムの正確性を確保するための簡単で強力な技術です.148p.
正しいプログラムとは?自分がやっていると主張するよりも、そんなに多くの番組しかやっていない.-148p.
マイエはこれらの前提と宣言を次のように解釈した.148p.

前提条件:スレッドは呼び出し可能である必要があります.つまり、これはプログラムの要求です.スレッドの事前条件が違反している場合は、インスタンスを呼び出すべきではありません.正しいデータを転送することは、コール側の責任です.

後続条件:luceneが自分でやることを保証します.つまり,プログラムが完了すると,世界の状態になる.スレッドにはバックライン条件があります.これは、スレッドが最後に終了し、無限の繰り返しが許されないことを意味します.

類不変式:呼び出し者にとって、類はこの条件が常に本当であることを保証する.インスタンスの内部処理中に不変式が本物ではない可能性がありますが、インスタンスが終了し、呼び出し元として制御権を返す場合、不変式は本物でなければなりません.

インスタンスとそのコードを呼び出すプロトコルは、次のとおりです.
呼び出し元がインスタンスのすべての前条件を満たす場合、インスタンスは終了時にすべての後行条件と可変項目が真であることを確認します.149p.
....'クラス不変式と命名します.しかし、実際には、これよりも一般的な概念です.この用語は本当の意味で状態状態である.
コードを記述する前に、有効な入力範囲、境界条件、スレッドが何を伝達するか、または何を約束しないかをリストするだけで、より良いソフトウェアを記述するのに役立ちます.-153p.
問題を特定し、原因を明らかにするためには、事故が発生した場所で早く止まることが有利です.-155p.
これらのニーズから直接導出される単純なルールは、複雑なエラー・リカバリ・スキームの整理に役立ちます.156p.
不変資格の要件が見つかった場合は、作成したすべてのドキュメントに適合させます.-156p.

Topic24. 死んだ番組は嘘をつかない。

一部の開発者は、すべての例外をキャプチャまたは救済し、ログ・メッセージを撮ってから再び例外が発生するのが最善の方法だと考えています.-159p.
言語をつくり、『プログラミング言語』を書いたジョアムストロングはよくそう言ったそうです.「防御プログラミングは時間の無駄ですか、止めたほうがいいです!」...-161p.
しかし、基本原則は同じです.コードがさっき起こり得ないことを発見すれば、プログラムはもう有効ではないと言える.これからやったことはみなおかしくなった.できるだけ早く終わることです161p.

Topic25. 特定のプログラミング

自己非難には贅沢性がある.私たちが自分を非難するとき、私たちは他の人が私たちを非難する権利がないと感じます.
-オスカー・ワイルド『ドリアン・グレイの肖像』
それぞれのプログラマーには、自分の経験を積む初期から暗記しなければならない戒めがあるようだ.
... このように始まったのです
そんなことは絶対に起こらない.
あなたたちの最初の防御線はすべての可能性のある間違いを検査し、それからダンティンを使って見逃したものを見つけることです.-165p.

Topic26. バランスリソースの使用

多くの開発者は、リソースの割り当てと解放の一貫した方針を処理していません.だから私たちは簡単なチラシを提出したいです.Tip40は自分で始め、自分で終わります.170 pのソースコードは必ず!参考にしてください!
リソース割り当てのデフォルト・モードを展開し、複数のリソースを一度に使用するインスタンスに適用できます.もう2つ提案します.-171p.

リソースを割当順に解除...

コードの複数の場所に同じ構成のリソースを割り当てる場合は、インタリーブの可能性を低減するには、常に同じ順序で割り当てる必要があります...

Topic27. ヘッドライトの前を歩かないでください。

調査員の言葉は、運転手が車のヘッドライトが照らされているのを見て反応し、駐車したりハンドルを曲がったりする能力を指す.177p.
そのため,実用主義プログラマーには明確なルールがある.Tip 42.の小さな階段を上る.いつでも.
ここのフィードバックは何ですか?もしあなたたちの行動が独立確証や反証であれば、フィードバック-177 pです.
「大きな仕事って何?」これはすべての「予言」が必要な仕事です.
未来がどうなるか予測したいほど、みんなが間違っている可能性が高くなります.-179p.
多くの場合、明日はほとんど今日と同じです.しかし、確信しないでください.

Thoughts I had while reading the book

-今日は本を読みながら・・・
DBCコンテンツではJavaScriptの方法を考え理解した.たとえば、Javascriptのmap関数map関数は非配列ではなく、実行後に新しい配列を作成するので、この内容に適していると考えられます.普段からモジュール化を重視しているので、DBCの内容はもっと集中して理解しようと努力しています.△そのため印象的な内容も多い.
どんなことがあっても、契約に適応できないのは間違いだと確信しています.これは起こり得ないことであるため、ユーザの狩り値を検証するために事前の条件を使用することはできません.149p.
読んでいるうちに上の内容が全く理解できなかったので、再びDBCの内容を精読しました.上記の内容は、前提条件はインスタンスを呼び出す条件のみであり、入力値を検証する機能としては使用できないと理解できる.すなわち、入力値がルーチンの条件と一致しなくても、ルーチン内でエラー(bug)として処理されなければならない.
DBCを読んで思い出したことがある.受講中、講師がモジュールの上にモジュールの説明や伝達パラメータのデータ型やアクティビティを定義するのは、半分のDBCルールではないでしょうか.
DBCをJavaScriptの関数として実現すれば、こんな感じになるのではないでしょうか.理解できるかどうかわからない

 /*
 * thing이 무엇일때 무엇을 해서 무엇으로 반환하는 함수
 * thing [type] ~~
 * return state(불변식)
 */
  const thing = 'something';
  
  // 선행조건
  if(!thing 조건){
    return new Error;
  } else {
    const thing_copy = thing;

    return doSomething(thing_copy);
  }
 
 // 후행조건
 function doSomething(thing_copy){
 
   // thing_copy를 가지고 후행조건 실행...

   return state? // 불변식???
 }

練習問題は14回後に必ずやります△これは今までの練習問題で一番やりたいことです.
今日の内容も重要らしいです.特に<ヘッドライトをリードしないで>私はいつも心配している私に大きなメッセージを送った.開発だけでなく、日常生活で考えなければならない概念のようです.前を歩くな!

Things you're curious about, things you don't understand.

-気になる内容、理解できない内容
DBCとリソースのバランスを理解するのは難しいです.特に資源バランスの後ろの部分は感覚しか見つからなかった.