個人ブログのジョブ
| プロジェクト | コンテンツ |
|---|---|
| この作品は、コースに属し | 春2020コンピュータソフトウェア工学研究所（ロジャー・レン建） |
| どこの仕事でこの要件 | 個人ブログのジョブ |
| このコースでの私の目標です | この研修コースのソフトウェア開発力と経験を通じ、他の人と仕事をする能力を強化 |
| 仕事具体的な側面は、私は目標を達成するのを助けます | ソフトウェアエンジニアリングの詳細については、資料を読みます |
1--簡単に見て完全な教科書、リストは、あなたはまだ理解していない、あなたの個人ブログに掲載5-10の質問に、。
唯一の著者によって行われ、ライトユニットテストコードのですか？
私は一時停止したときに学生が通常のとき通常の宿題に少数の人々は、テストケースを交換するので、互いのfindバグヘルプ、テスト一緒に、ここを参照してください、大きなことではないプログラムの精度を向上させることができますか？しかし、慎重な検討がそうすることが判明しなければならないの後、我々はすべて、同じプロジェクトのジョブの同じコピーを行っているので、私たちはお互いを助けることができますが、労働のソフトウェアエンジニアリング皆明確な部門で、2人が同じモジュールを書くことはできません（2賃金）は、熟考に後で彼は、コードが行うことを人々に最も精通していることを言及しないように、テストに自分の問題を所有する必要があり、合理的であることがわかりましたか？
学生とプロのプログラマの違い
2.3は、本を書きました：
3年間の本を読むよりもシニアソフトウェアエンジニア、より多くの仕事の三年より、タスクの品質は、人々の2種類が同じではありませんが必要です。我々は両方の「ニーズ分析」と「テスト」のエンジニアは明らかに多くの時間がかかる（60％以上）ことがわかります。
しかし、特定のコーディングに、エンジニアは、学生が第三よりも費やす必要があります時間。明らかに、学生からプロのプログラマーには、いない
コードを書くが、はるかに少ないに費やす時間-より多くの無限のプログラムを書きます。学生のコードを書いて、ステージでの経験は非常に完全ではないので、必然的にこの部分は通常、ほとんどの時間を浪費し、今もちろんの正しさを重視の多くはまた、学生がの多くを費やすことを可能にする開発段階でバグの多くに遭遇し、デバッグしますこのようパイソンの使用など、テストの時は、自動的にテストケースを生成し、その後、DOSスクリプトの自動化、バッチテスト。テストのための時間の割合を増やしますが、ニーズ分析に費やす割合が十分でないことを認めざるを得ないために、多くの人々はおおよその指示を置く - 私を含めコースの要件は、多くの学生が自発的に正しさに注意を払うに始まりました再び性急開始に関する大まかなアイデアを、それを読んで、実際には、情報隠された多くのニーズがまだある、ない指定されたデータ範囲が存在しない場合など、それはすべての場合は、ハンドルデータに必要とされ、それはint型を満たす、というようにしないことがあります。
どのように適切にgoto文を使用するには？
「法の構築」を使用後藤については、セクション4.3.2はとてもお勧めします。
単一の出口で最高の機能は、この目的を達成するために、あなたはgoto文を使用することができます。限りプログラムロジックは、方法は後藤含めて、使用することができるかの明確な兆候を助けて。
それが大幅にコードの構造が複雑になるため、オペレーティングシステム上のコースを学習、本の中で4-2のリストたとえば、可能性が高く、使用しないときは後藤にC言語の人々は基本的に非、最後を聞くことになる学びましたまた、私はこの使用方法を持っていました：
HRESULT HrDoSomething(int parameter) { //parameter check and initialization //processing part1 If (SomeCode() != ok) { //set HR value Goto Error; } //processing part1 If (SomeCode() != ok) { //set HR value Goto Error; } Error: //clean up free resource, reset state, etc return hr; }それはできますが、エラー処理に交換する必要があり、もちろん、それは交換することができ後藤のような：
HRESULT HrDoSomething(int parameter) { //parameter check and initialization //processing part1 try { SomeCode(); //processing part1 SomeCode(); } catch (Exception &e) { //set HR value return hr; }このようなコードは、より良い、それはgotoよりもですか？私はそれが少数の小さい判断、後藤文はほとんどの場合であれば交換することができ、優れていると思いますが、使用することができますまとめていくつかの例があります。
- 下がっているプログラムの構造を維持するためには、後藤にあり、それはローカルプログラムの前には戻りません。プログラムの全体的な構造に影響を与えるが、これは無害しかしである、時々構造の一般的な順序は蚊帳の外にジャンプするgoto文を使用することであるが、必要はありませんしません。
- 例外処理の場合には、より一般的に、後藤を使用することができることを行うことも可能であるが、言語のほとんどはまた、代替手段を提供します。
- 有限ステートマシン。
ペアプログラミングモデルの質問について：
本セクション4.5.2書き込み：
ペア・プログラミング・モード、側プログラマ、等しく、相補開発によって一対のサイドで。彼らは、電気に並んで座って
マウスを操作、同じキーボードを使用するディスプレイ局の前面。彼らは一緒に、一緒に設計、分析
、文書を書くために、一緒にテストの統合を行うために、一緒にテストコーディング、ユニットと一緒に、一緒に書き込みテストケースを。現在のコード管理ソフトウェアは非常に進んでいる中で、私は、このような行為を推奨するものではありません、ペアプログラミングは、より下の本に適している必要があります（私はこのパターンを試していないためか）言いました：
プログラミングは常に人間の活動となっています。だから、学校は教えることであり、また私たちはやってきました。二
人は（これは2人の賃金である2人のモジュールは、現在の書き込みは無駄ではない、二つのモジュールを行っている可能性
オハイオ州）？私は明示的なバグ可能性のが大幅に減少したが、暗黙的にもかかわらず、2人は同じモジュールをすればするので、ペアプログラミングは、異なるモジュール、使用コード管理ソフトウェアのバージョン管理、テスト、公開を完了するために、2人のあるべきだと思いますバグが考え方による見つけることができない場合があり、同じ、それは、次に、それぞれのモジュールを完了するためにコードが改善される読み取り不具合の可能性を認識している場合。もちろん、私はテストがペアプログラミングであるとき、二人の開発者によって開発段階が自分でプレーする方が良いだろうと信じています。
疑いの開発段階のために
セクション15.1.5で書きました：
バグ修正は、すべてのチームが執行力を持っています。ZBB -ゼロバグビルドは、あること、すべての既知の建設のこのバージョン
のバグが出て解決されます。これを達成するために、我々は、開発段階でバグを最小限に抑える必要がありますが、開発段階が終了する中、開発者はすぐに良いテストモジュールとすること、またはすべてのモジュールは、その後、良いテストを終えましたか？モジュールは、すぐにテストを書かれている場合は、エラーコードやその他の問題は、低効率が表示される場所のすべてのモジュールおよび他のテストを行った後、完成している場合、プログラミングでは私の経験で、あなたはバグを見つけることは難しいでしょう、私は知りませんどのモードの用途が良いでしょうか？
2 - いつ、どこで、誰が - ウィル「ソフトウェア」および「ソフトウェアエンジニアリングは、」これらの単語が表示される方法ですか？
ソフトウェア：
紹介によると、ウィキペディアには、リチャードR.カーハートは、ソフトウェアの研究メモランドに単語を書いたが、また、ソフトウェア工学分野の概念を導入する最初のものです。
エンジニアリングの文脈における用語「ソフトウェア」の最古の出版物は、ランド研究所の研究覚書では、リチャードR.カーハートによって1953年8月にありました。
出典：ウィキペディア
ソフトウェアエンジニアリング：
、1968年にその最初のソフトウェア工学会議を開催ソフトウェア、北大西洋条約機構（NATO）を開発する際に遭遇する困難を考慮して、ソフトウェア開発における「ソフトウェア工学」は、ソフトウェア開発べきだ」という知識を定義するために必要な、と提案されています同様のプロジェクト活動。」ソフトウェアエンジニアリングは、1968年から正式に提案した、研究成果を大量に蓄積し、この時間は、広く多くの技術的な練習の、学術及び産業必見の共同の努力によって、ソフトウェアエンジニアリングは、徐々にプロの規律に展開されます。
出典：ウィキペディア
3 - 私たちは、すべてのソフトウェアエンジニアリングの開発プロセスは、あなたが面白いトリビアや物語見つける何であり、ソフトウェアおよびソフトウェアエンジニアリングの起源を知っていますか？
（コンピュータプログラミングのアート、TAOCP）「コンピュータプログラミングの芸術」で有名なコンピュータ科学者ドナルド・クヌース（ドナルド・E.クヌース）は、することを決め、ラフ組版耐え難いに最終的に、彼の記念碑的作品の第三巻を終えました書き込みを一時停止し、後でTeXの組版ソフトの中で学術的評判に完全な開発になりました。
- 彼は、1978年の後半に完了することができるようになり、わずか6ヶ月の時間だと思ったが、最終的に、彼はより多くを過ごした10年の 1989 TeXの最後にストップが変化するまでの時間を。
- TeXのバージョン番号も非常に興味深いです。TeXの第3版の当初から、アップグレード後、小数点以下の場所の後に新しい番号を追加するためにどんどん近づいてパイπの値にそれを作ることです。TeXの現在のバージョンである3.1415926。TeXは非常に安定していることをこの番組では、任意のアップグレードは非常に微妙です。ガートナーは、「残りの脆弱性は、プログラムの機能と見なされます、その後、バージョン番号πに置き換えられます、最後のアップグレードが（私の死の後）である。」と述べました
- TeXはTeXの中にバグを見つけることができる非常に安定したプログラム、クヌース報酬報酬誰である（バグ）があります。1セント始まり、毎年から各脆弱性のための賞量は倍増し、現在の$ 327.68キャップまで、。しかし、ガートナーは、したがって、お土産は現金を取るしたくないとして、それを額装することを好む、チェックを受けた後にTeXでは非常に少数の抜け穴ため、多額の資金を失っていないが、人々の脆弱性の本当の発見ん！[1]
また、ガートナーは、時間（または、むしろ別の結果の多くで）Metafont--あることが10年以上他のジョブは、システム内のフォントのセットを設計するために使用されます。そして、自然対数Eの進化を使ってTeXに同様の方法には、バージョン番号です。（現在のバージョンは2.718281です）
出典：ほとんど答え知っています
4 - 現在の人気のソースのバージョン管理ソフトウェアとプロジェクト管理ソフトウェアに関するインターネット調査、何、何の利点と欠点？
マイクロソフトTFS：
長所：、プロジェクトの進捗状況の視線をタスクのバージョンを要求することができ、ガントチャートよりも有用小さなチーム、統合プロジェクト管理、バージョン管理、バグ追跡のために、効果的VS.と係合シームレスに、SCRUMを実装することができます
短所：ビルドは、TFSは、より複雑な保守、ハードウェア要件は比較的高いです。
GitHubの：
長所：ウェブに基づくサービスを提供するためのGitHubのGitリポジトリは、あなたがGitのソースコード管理機能、またはその特性を使用することができます。GitのリポジトリGitHubのは、ウェブに基づいてサービスを提供し、あなたはGitのソースコード管理機能、またはその特性を使用することができます。
欠点：創造的なプロセスは、キャプチャし、創造的なアイデアを記録するための最適なツールではないかもしれません。この特殊機能についてLayerVaultアナログ、または他の同様のツールを選択することができます。以前、我々はすでに強調してきたGithubのは、コードを追跡するための理想的ですが、それは最高のデザイン・トラッキング・ツールではありません。コードまたはのために設計された製品のセットに映像コンテンツが、それはまだのように滑らかではないようです。
Bugzillaの：
長所：無料、中国語版のサポートがあります
欠点：高速検索結果が正確ではありません。欠陥のみを管理します。
アップルはXCode：
長所：高速なコンパイル速度、各操作は非常に迅速かつ簡単です。自動的に任意のコードを記述することなく、アンドゥ、リドゥとセーブ機能を提供します。
欠点：プラグインの更新バージョンが失敗することがあります。
Tracの：
メリット：非常に柔軟で、任意の制御およびSVN統合することができ
デメリット：機能は非常に強力ではありません
Bitbucket：
利点：小さなチームのための使用は無料ストレージライブラリ、限られた容量の無制限の量を使用しますが、5人のメンバーを制限することができます。JIRAの統合ツールは、統合バグ追跡コンポーネントと、JIRAは自動的に検出された問題についての情報を更新します。すぐに大きなファイルを提出してください。柔軟なアクセス制御を持っている、そのようなサポートとして、ドメイン名をカスタマイズすることができウィキ
欠点：コードとユーザーグループの量はGitHubのようではないかもしれない、プラットフォームをホスティングしている家庭用のプライベート倉庫はGitLab未満であってもよいです。システムが安定して十分ではありません
GitLab：
メリット：国内のIT企業がプライベートライブラリのGitLab利用の非常に大規模な量を持っています。強力な統合されたCI / CD機能も怠惰なインストール、gitlab統合ジェンキンスドッカー独自のオムニバスパッケージをサポートし、また、非常に便利である独自のセットをウェブフック、があります。自由のためのプライベートライブラリのための
欠点：gitlab githubのはレプリカですが、それは少し重いようです。有料gitlab拡張機能。登録頭痛のgitlabアカウント登録を確認する必要が、検証はGoogleのCAPTCHAであるので、あなたはオンライン登録gitlabの魔法を完了する必要があり、気持ちのgitlab遅くgithubのより
ランクユーザー数（ウィキペディアからのデータ）：
| 名前 | ユーザー | プロジェクト | Alexaのランク（下=より人気のあります） |
|---|---|---|---|
| GitHubの | 3100万 | 100,000,000 | 2019年9月9日のように65 |
| SourceForgeの | 3,700,000 | 50万 | 2019年9月9日のように407 |
| Bitbucket | 5,000,000 | わからない | 2019年9月9日のように989 |
| GitLab | 10万 | 546000 | 2019年9月9日のとして2146 |
| OSDN | 54826 | 6294 | 2019年9月9日のとして8529 |
| 発射台 | 3965288 | 40881 | 2019年9月9日のように12344 |
| Assembla | わからない | 526,581+ | 2019年9月9日のように23052 |
| ロゼッタコード | わからない | わからない | 2019年9月9日のように62045 |
| バディ | わからない | わからない | 2019年9月9日のように73518 |
| GNUサバンナ | 93346 | 3848 | 2019年9月9日のよう100244 |
| ジート | わからない | わからない | 2019年9月9日のよう209697 |
| CloudForge | わからない | わからない | 2019年9月9日のよう339271 |
| OW2コンソーシアム | わからない | わからない | 2019年9月9日のよう610052 |
| Ourproject.org | 6353 | 1846 | 2019年9月9日のよう1191954 |
| ONLY | わからない | わからない | 2019年9月9日のよう1268571 |