北、個人のブログソフトウェアエンジニアリングの求人
| プロジェクト | コンテンツ |
|---|---|
| この作品は、コースに属し | 春2020コンピュータソフトウェア工学研究所（ロジャー・レン建） |
| どこの仕事でこの要件 | 個人ブログのジョブ |
| このコースでの私の目標です | ソフトウェア工学の知識を学習、チームプロジェクトを開発する能力を向上させます |
| 私は目標を達成する助けたジョブの特定の局面において | 「法の構築」を読んで、次回のさらなる研究のために準備するためのソフトウェア工学の理解を深めて |
クイックルックは、個人のブログに掲載あなたはまだ理解していない5-10質問に、リストの完全な教科書。
一つの問題：ユニットテストが唯一のプログラムの著者によって書かれたことができるかどうか？
次の文でユニットテストのための2.1.2教科書の著者：
ユニットテストは、コードに最も精通し人々（プログラムの作者）によって書かれている必要があります。コードの目的、特徴および実装の制限のコードの最高の理解。そこで、著者らはこれ以上の適当な候補よりもユニットテストを書くません。
効率の著者によって書かれたユニット・テスト・プログラムが実際に高くなる可能性があり、著者はよりよい人々のコードよりも知らなかったことは事実ですが、私の経験では、ユニットテストの品質が低下しても良いです。私はコードを書くときには、多くの場合、考え方の種類は、プログラムに固有のバグを見つけることがしばしば困難である持っているのではなく、見つけるためにどこの試験試料あなたと議論し、普通株式によるバグ。あなたは著者自身によって完全にユニットテストを書く場合、私はおそらく、繰り返しテストされる同じ苦境に陥ると、自分のサンプルプログラムを修正すると思う、とエラーサンプルはにより、この場合には、見つけることは困難でしたブレーンストーミング、ユニットテストを書くことで他の人または人々、それはそれではない、より効率的で、より質の高い練習ですか？
第二の問題：限り、どのような方法での援助プログラムロジック明確な症状は、使用することができますか？
4.3.2では、著者は次のように説明します。
単一の出口で最高の機能は、この目的を達成するために、あなたはgoto文を使用することができます。限り明確反射支援プログラム論理として、どのような方法は、ジャンプなど、を使用することができます。
1974年に議論の焦点となってgoto文は、D・E・議論のためのクヌースGOTO文は、正義の包括的な見直しをした、基本的なポイントは以下のとおりです。GOTO文を無制限に使用、バックジャンプ、特にでGOTO文では、このような場合には、あなたがGOTOステートメントを使用しないようにしようとする必要があり、困難なプログラム構造を理解することが原因となります。私は、強力なものの後藤声明深く偶発的ですが、静的構造と動的構造と一致しません。プログラムは、トラブルシューティングするためにプログラムは、理解しにくい困難にします。プログラムを反映することができるGOTO文を削除した後、プログラム構造から直接実行されています。このように、プログラム構造は、明確に理解しやすい、簡単なトラブルシューティング、だけでなく、プログラムが正しいことを証明するために役立つだけではなく。書き込みの時間と後藤の乱用を反映する唯一のロジックの場合は、コードの可読性や他の隠された危険性の減少で、その結果、私はそれはろうそくの価値があると思います。
質問3：ペアプログラミングモードに疑問
4.5.2で以下の議論では：
ペア・プログラミング・モード、側プログラマ、等しく、相補開発によって一対のサイドで。彼らは、マウスでの作業、同じキーボードを使用して、表示面と、コンピュータの前に並んで座っていました。彼らは一緒に文書を書くために、一緒にテストの統合を行うために、一緒にテストコーディング、ユニットと一緒に、書き込みテストケースと一緒に設計し、分析します。
ペアプログラミングは、利益の多くを持って、彼らは怠惰ではないことが容易で、お互いに、相互牽制を奨励し、私はそれが害がないわけではないと思います。私の経験、プログラマと低レベルのプログラマでプログラミングの高レベルでは、このケースでは、だけでなく、低レベルのプログラマは寄与しないことがあり、より多くの作業を行うことが多いプログラマのハイレベルであります自分の思考のエネルギーは、また、それはペアプログラミングである本の中で説明し、このように著者に言及し、二人がモニターで、私はそれは方法だと思いますが、同じマウスを共有するのではなく、プロジェクト全体の足かせかもしれそれはあまりにも理想と現実的ではありません。私の理解では、独立したワークの2組が自分の空間で自分の才能を最大限にするために、定期的に交換し、議論を行うことができ、これは、オープンプログラミング正しいペアがあります。
質問4：プログラマやプロジェクトマネージャの交換を
第九章では、著者は、最大かつ最もユニークな貢献のためのプロジェクトマネージャーは、最も重要な目標を達成するためにチームをリードし、チームのバランスを維持することですについて説明し、しかし、私の経験では、実際の状況はより複雑にすることができます。プログラマーとして、どのように明確にプロジェクトマネージャに自分の考えや能力を表現するには？私たちは意見を一致しない場合には特に、何が優先対象として考慮すべきですか？プロジェクトマネージャは、間違っていたり、非現実的な目標を作る場合、私は、単にあなた自身のコードを書くに加えて、プログラマーとして、それを解決する良い方法はありますか？
5つの質問：改善の余地のバグと呼ばれるソフトウェア開発会社のバランスをとる方法
第16章では、著者はこれを議論し：製品が公開される場合は、通常は変更にいくつかの既知のバグを残します。製品はインスタント利益を持っているためにリリースされるので、一方では、チームはよりやる気になり、製品の反復の次の段階のための余地を残すためのもう一つの理由です。しかし、どのようにあなたのバグがユーザーエクスペリエンスに影響を与えないことを確認するには？開発者の意欲を高めるチームがやる気しながら、どのようなバグ最大化は、顧客を維持滞在することができますか？
いつ、どこで、誰が - 「ソフトウェア」および「ソフトウェアエンジニアリングは、」これらの単語の表示方法であるのだろうか？
ソフトウェア（ソフトウェア）
この語彙の「ソフトウェア」は最初のリチャードR.Carhart覚書RAND社の研究により1953年8月に提案されました。2000年には、フレッド・シャピロ司書イェール大学ロースクールは1958年に、アメリカの数学者ジョン・テューキー紙「コンクリート数学の教育」によって公開され、その文字番組を公開し、参照が単語の使用に言及される「ソフトウェア」です。
ソフトウェア工学（ソフトウェア工学）
NASAのエンジニアマーガレット・ハミルトンは、アポロ計画グループで提案されています。その時、ソフトウェアではないハードウェアは、注意として、ほとんどの人は魔法ではなく、科学と考えるため、マーガレット・ハミルトンは、発明および関連ソフトウェアのための彼らの正当性と尊重のために戦う用語「ソフトウェア工学」を使用し始めました。
参考資料
我々は、すべてあなたが面白いトリビアや物語を見つけるものの中にあり、ソフトウェアおよびソフトウェアエンジニアリング、ソフトウェアエンジニアリングの開発プロセスの起源を知っていますか？
- グーグルは、Google、グーゴルの元の名前を呼ばれるスペルミスますので最初は、それがでした。
- 恐竜パルクール、人々が知っている多くのでなければなりません-インターネットから切断され、GoogleのChromeブラウザは小さなゲームを隠しました。ゲームは非常に簡単な方法を制御：コンピュータの押しますスペースバーをゲーム、スペースジャンプを開始するには、キーボードの下矢印は、モバイルデバイスを使用している間、彼はスクワット、そしてロングゲームを開始することができます鳥をタップするようにします。
Googleはの開発者とのインタビューで、ゲームの起源を説明：デザイナーによるとセバスチャン・ガブリエルは、ゲームの意味は、「ネットワークオフ」にバックのようなものであることを言った「先史時代。」もちろん、まだユビキタスインターネットではなかったです。若い人たちのために、今日、それはネットオフすることも非常にまれなことですが、過去への回帰が、人は、特定の場所でインターネットに接続する必要があります。「インターネットカフェ」が、その後、事業の売却が活況を呈している-これらの場所は、家庭、学校、または会社を含むことができます。このゲームではクローム恐竜、「プロジェクト・ボラン」のコードネーム、1970年代からのロックバンドT-Rexの（ティラノサウルスレックス）は、バンドはいずれかのマークボランという名前の歌手でした。ゲームは最初に2014年9月Chromeで登場します。また、開発者は、このゲームは最高のパワーに遊ぶことができることを自慢しました。エドワード・ユングは言ったエンジニア：「私たちは、地球上のティラノサウルスレックスが長く生き残るが、私はあなたのスペースバーは、その長い生き残ることができない恐れているとき、ゲームの長さは、おそらく、万人の約1700年となりました設定します。」
現在人気のあるソースのバージョン管理ソフトウェアとプロジェクト管理ソフトウェアに関するインターネット調査、あなたは、どのような利点と欠点が何でありますか？どのように多くの、より少ないソートするから、年の最後のカップルを使用している人の数に従って、どのくらいの各ユーザー（推定）を説明、ツールの長所と短所（あなたは、関連する情報を参照し、ソースを示すことができます）。
人気の指標
長所と短所
マイクロソフトTFS
長所：、プロジェクトの進捗状況の視線をタスクのバージョンを要求することができ、ガントチャートよりも有用小さなチーム、統合プロジェクト管理、バージョン管理、バグ追跡のために、効果的VS.と係合シームレスに、SCRUMを実装することができます
短所：ビルドは、TFSは、より複雑な保守、ハードウェア要件は比較的高いです。
Tracの
优点：Trac作为一个SCM配置管理平台，意味着它有良好的扩充性，Trac的权限体系是比较完备的设计，非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点：不支持多项目，需求和缺陷没有分离，用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，中文化不完整，美术人员接触起来困难重重，不显示中文名，本地化做得很差，核心功能很少，不安装插件基本上没法用。
BUGZILLA
优点：BUGZILLA不收费，BUGZILLA现在有中文版支持
缺点：BUGZILLA只能管理缺陷
Apple XCode
优点：可以自动创建分类图表，自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
GitHub
优点：免费且开源。用于敏捷高效地处理任何或小或大的项目。Git支持分支功能（branch）。如果你想开发一个新的产品功能，你可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。可拿Git做备份系统，或者同步两台机器的文档，很方便。支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。Git中的每个工作树都包含一个具有完整项目历史的仓库。简易的初始化。对于随便写两行代码就要放到代码管理工具里的人来说，再合适不过。
缺点：学习成本大。由浅入深的过度很漫长，需要大量时间的投入。Git版本库需要频繁的手动维护。
Mercurial
优点：学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。可以一键完全恢复到历史版本的某一个切面。封装好。相比git，hg很少暴露一些实现内的细节。照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，目标其实是为了让 svn 用户更容易接受。这使得已经习惯 svn 命令的团队，几乎零成本的切换到 hg。hg 的 pull 更多的时候可以让你避免创建分支。hg 好比苹果系统，git 好比 Linux，前者在常用命令上更好用更易用，后者在功能上更强大更灵活。hg的版本库不需要维护。
缺点：分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。