個人ブログのジョブ
「法の構築」を読んだ後、簡単な質問に提案
あなたは高速でなければならないかどうかを1ユニットテスト？
第二章が始まるとき、それは良いの標準的なユニットテストに言及しました。著者は、ユニットテストは、プログラムの基本的なモジュールの正確さを保証するために、正確かつ迅速であるべきと考えており、私はこの点を確認しました。しかし、その後、次のように私は、いくつかの疑問を持っているので、説明は
ユニットテストは、（時間ではなく分よりも、数秒間テストランで）高速であります
効率を維持するために高速、。基本モジュール（クラス）のようなソフトウェアの数十がありますが、各モジュールは、私たちは基本的には、数秒以内に完了するクラスをテストするために必要な、いくつかの方法があります。
私はそれが「効率性を維持するために、速い」と一致している任意のソフトウェアユニットテストではないと思います。例えば、我々は時間の多様上の規定は、人々があまりにも速いエレベーターを取ることができないので、OOマルチスレッドエレベーターを学習時間年生で書いた、機械学習テストを含む、データの非常に大量の顔は、それが試験速度には不可能ですどのくらいの速。しかし、それゆえ全くユニットテスト効率はなく、良好な試験が存在しないと言うことができません。おそらく著者は、「テスト」の通常の理解と「ユニットテスト」は異なることがここにもありますか？
コードの設計仕様と2.goto準拠？
セクション4.3.2では、著者が提案しています
単一の出口で最高の機能は、この目的を達成するために、あなたはgoto文を使用することができます。限り明確反射支援プログラム論理として、どのような方法は、ジャンプなどを使用することができます。
「有害考慮GO TO文」で有名なコンピューター科学者ダイクストラ元（有害説に移動）彼の論文は以下のよう
声明へ行くの使用は、このような悲惨な効果を持っている、と私は声明へ行くにはプログラミング言語のすべての「より高いレベル」から廃止すべきであると確信しになった理由をもっと最近私が発見しました。
彼は、goto文は、「悲惨な」影響力を持っている言語のプログラミングを「高レベル」から排除されるべきで、提案しました。現代のgoto文は、一般的に混乱とエラーが発生しやすいのプログラミングをもたらし、プログラムを破壊する「構造化」、コードの可読性を減らすために考えられています。私たちは、コードの読みやすさを実現し、強化するためのif-else文で置き換え、goto文を使用しないようにしてください、この文は、その存在の役割を持たなければならないと思います。
4.5結節について3.プログラミング
このセクションでは、著者は信じています
ペア・プログラミング・モード、側プログラマ、等しく、相補開発によって一対のサイドで。
ペアプログラミングでは、プログラムのすべての面での見直しと品質のやり取りに任意の時点で存在しているように、1というハイレベルのすべての面でプログラマーの束に依存します。
三つもペアプログラミングの利点を指摘しました。私はそれが包括的ではない、それはペアプログラミングのちょうど正のアイデアだと思います。これは、プログラマの相補等しい作業の始まりであることを仮定しますが、1日に2人の男が突然、このようなAは、彼の貢献は、開発プロセスではBよりも大きくなると思いますが、傲慢になり、Bプログラマとして目に見えない矛盾を、生産......このペアプログラミングは逆効果だろう受け入れることを拒否した、ペアには本当の目的は、ケースは相当なものだから、そこではありません。
4.どのようにして、ユーザの背後にある動機を見つけるのですか？
10.1では、一例として、作者のWeb漫画、それを注意すること
ただ、ユーザの言語や行動の面を見てすることは十分ではありません。また、ユーザーの言語やアクションを見つける動機の背後を！ユーザの言語によるだけで意思決定を行うために急いですることはできません。
含意は、我々はユーザーのより深いニーズを推測したいということです。しかし、現実には、同じ内部の漫画のような、多くのユーザーで、そして時にはZhaomaohuahuは、多くの場合、非常に専門的ではない、完全に開発者が理解してみましょうされていない彼らのニーズを記述することができ、開発者を願っています。「あなたが最初にこの、この、この方法で再び、そして最後に、これは右、非常に単純なのですか？」つまり、一部のユーザーは難しい：いくつかの時間、インターネットの普及などの場合前に、一部の人は言った、似ているパーティーを呼び出します通信は、かなり確実ではありません行うには、それらの背後にある動機、でも自分の希望を見出すことは困難です。このケースでは、我々は、ユーザの顔の言語発達や行動に直接、または動機の背後を発見する何より良い方法でしょうか？
5.技術革新はキーがあるかどうか？
- セクション16.1.6では、著者は「技術革新が鍵である」と信じている革新的なビジネスモデル、革新的なユーザーエクスペリエンス、革新的な生態系の一例を挙げて、神話です。私はアナロジーは非常に完了していないと思いますが、技術革新を通じて除いて、他の多くの革新的な方法があることだけを示し、証明することができ、「イノベーションは技術には存在しません。」キー革新は、私はまだ技術を考えて、来ます。
「ソフトウェア」および「ソフトウェアエンジニアリングは、」これらの単語が表示される方法です - いつ、どこで、誰が？
- ソフトウェア（ソフトウェア） - 1958年は、「具体的な数学の授業」紙に掲載された、有名な統計学者ジョン・テューキーベル研究所によって提唱されました
- ソフトウェア工学（ソフトウェア工学） - アポロ11号は、マーガレット・ハミルトンによって、設計プロセスで作られました
面白いトリビアや物語のソフトウェアエンジニアリングの開発プロセス
コンピュータウイルスが原因の損傷に設計されていません。
最初のコンピュータウイルスの歴史は、フレッド・コーエンは、個人的に設計された技術的な防衛の専門家です。コンピュータウイルスの彼の創造を目的とちょうどあなたのコンピュータに害を引き起こすことがないことを期待して、感染したコンピュータプログラムの実行可能性を証明します。しかし、このアプリケーションはそうウイルスの名前が付けられ、コンピュータ、フロッピーディスクと異なるコンピュータ間でのリムーバブルメディアや缶広がりを感染させることができました。その後、彼はアクティブなコンピュータウイルスを作成し、主な目的は、コンピュータユーザーは感染していない実行ファイルを見つけることです。
人気のソースコードのバージョン管理ソフトウェアとプロジェクト管理ソフトウェア、あなたが何であるか、どのような利点と欠点？
マイクロソフトTFS
利点：
- できる小さなチームのタスクの需要バージョン、プロジェクトの進捗一見、上、ガントチャートの統合プロジェクト管理、バージョン管理、バグトラッキングよりも便利。
- SCRUMはVS.とのシームレスな約束を達成するのに有効であること
短所：
- 建設、より複雑なメンテナンスTFSは、ハードウェア要件は比較的高いです。
- システム全体はかなり遅いブラウザを使用してアクセス、ASPを用いて実現されます。
ギット
利点：
- 分散開発に適した、個々の重視。
- サーバと大きすぎることはありませんデータの量に世論の圧力。
- 高速かつ柔軟な。
- あなたは簡単に二人の開発者の間で矛盾を解決することができます。
- オフライン作業。
短所：
- 高い学習コストが、学ぶことは非常に困難です。
- Gitのリポジトリには、頻繁に手動メンテナンスを必要とします。
Tracの
利点：
- 非常に柔軟で任意の制御やSVN統合することができます。
短所：
- 機能は非常に強力ではありません。
Bugzillaの
利点：
- 無料、中国語版のサポートがあります。
短所：
- クイック検索結果が正確ではありません。欠陥のみを管理します。
アップルはXCode
利点：
- 高速でコンパイルし、各操作は非常に迅速かつ簡単です。自動的に任意のコードを記述することなく、アンドゥ、リドゥとセーブ機能を提供します。
短所：
- プラグインの更新されたバージョンの後失敗することがあります。
Mercurialの（HG）
利点：
- エントリの下の障壁。全体的に、HGの必要性はgitのよりもはるかに少ないのコマンドを知っています。
- それは歴史のスライスを完全に復元されたバージョンへの鍵となることができます。
- グッドパッケージ。gitのを比較すると、HGはほとんどいくつかの実装では詳細を明らかにしません。
- ユーザーの移行の世話をSVN。
- 時間のより多くのHGプルを使用すると、ブランチを作成しないようにすることができます。
- HGリポジトリは、メンテナンスを必要としません。
短所：
- 枝管理が柔軟ではありません。MercurialのやGitのブランチの管理は非常に便利で比較されていません。