| プロジェクト | コンテンツ |
|---|---|
| コース | 春2020コンピュータソフトウェア工学研究所（ロジャー・レン・ジアンキン） |
| 運用要件 | 個人のブログ運用要件 |
| 私のカリキュラムの目標 | 優れたソフトウェアを開発するためのソフトウェア開発方法論と学生との技術協力の数の章グリップ |
| ジョブアクション | 速読材料、オープン次の研究の問題点。プロジェクト管理ソフトウェアの理解。 |
迅速な読み物は、まだ問題を理由にすることは理解していません
•質問：単体テストの作成者
第2章では、著者は信じて、ユニットテストは、その根拠に基づいて、プログラムの作者によって書かれている必要があります。
コードの目的、特徴および実装の制限のコードの最高の理解。
しかし、比較的複雑なユニットには、いくつかのバグ自体はいくつかのケースで発生するメカニズムを無視著者によるものです。この時点では、ユニットテストを書く著者は「そのカバー包括的なテスト以来、」おそらく既存の思考や書き込みによるものであり、彼は特定の状況の正確不足「包括的」と考えました。学生はバグの状況を測定した後、オブジェクト指向のクラスの前に、独自の詳細なテストサンプルによって起こった、後、私は抜け穴の考え方を実現しました。試験サンプル中の質量暴力と一緒にブラックボックステストケースのメンバーによって書かれた、または複雑なサンプル発生器モジュールのために特別に書かれた機能ユニットコードの明確な定義にかは、完全にバグを識別することがより助長していますか？
•質問：後藤＆例外処理
以前の研究では、後藤は、有害とみなされており、避けるべきです。しかし、マニュアルの例のセクション4.3.2、後藤に確かにそう単純およびエクスポート機能にはいくつかの分岐リードによって機能の終了の統一性を確保。それがこのユニットにジャンプすることはgotoを確保するために使用されなければならない、と言うことができますか？さらに、本実施例では関数内の関数出口単一の例外処理を行うためです。しかし、学習する前に、我々はそれを投げるインスタンス化するときに例外が発生し、自作の例外処理クラスに奨励されています。私は、例外が統一された方法を処理するかどうかを尋ねますか？状況は、単一のエクスポート機能と決意例外が内部的に処理することを保証するために必要なものの下では？
HERSULT HrDoSomething(int parameter)
{
//parameter check and initialization
//processing part 1
If (SomeCode() != ok)
{
//set HR value
GOto Error;
}
//processing part 2
If (SomeCode() != ok)
{
//set HR value
Goto Error;
}
Error:
//clean up free resource, reset stat, etc
return hr;
}*「ビル法」からリスト4-2
•質問：なぜアジャイル？
この本は、表6-3の条件さまざまなソフトウェア開発手法に与えられています。私は今、非常にアジャイル開発はまだソフトウェア開発方法論の主流れているかどうかであるかを知りたい、そして注目すべきどのようなプロジェクトでは、それは、このように開発されましたか？
•質問：スプリント変更プロセスのニーズ
书中第6章描述在Sprint过程中团队专注于满足根据需求制定好的计划，在此期间不响应需求的变化。图6-5给出的一个例子中，Sprint可以持续一个多月的时间。是否在Sprint开始前需要和客户沟通好这个开发模式以约束其在Sprint过程中不变更需求扰乱Sprint的过程？
· 问题：创新的迷思
第16章中，作者描绘出时兴的创新氛围：
媒体上充斥着创新型的人才、创新型的学校、创新型的公司、创新型的城市、创新型的社会等名词。有些城市还把“创新”当作城市的精神之一，还有城市要批量成产上千名顶级创新人才。IT行业也充斥了很多创新的新闻和掌故。
而后披露了一些关于创新的似是而非的观点，指出“并非所有人都喜欢创新”，“好的想法未必赢”，“成功的团队未必靠创新”等。请问该如何看待这种矛盾的现象？对此我们该如何调整心态？这对于我们的软件开发有何启示？
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
· Software
根据维基百科词条，John Tukey在1958年的“The Teaching of Concrete Mathematics”一文中最先使用“software”这个词。1995年Paul Niquette声称他发明了这个词，然而并没有依据。而软件这个词最早在工程语境中出现是在1953年兰德公司（RAND Corp.）的工作便签中。
· Software Engineering
“软件工程”的概念是1968年第一次提出来的。
——《构建之法》P4
按章后的引用，找到了NATO的1968年报告SOFTWARE ENGINEERING，其中记载：
In late 1967 the Study Group recommended the holding of a working conference on Software Engineering. The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
“软件工程”的提出被用来促进一种“软件制造需要吸收传统工程的特点，基于严谨的理论基础和实用性原则”的认识。这应该是“软件工程”第一次在国际大会上得到承认，而“软件工程”的提出可以追溯到1965年Margaret Hamilton在Apollo计划的实践中提出的概念：
The concepts developed became the building blocks for modern "software engineering", a term coined by Ms. Hamilton, and immediately found use beyond Apollo on Skylab and Shuttle.
——The NASA Heritage Of Creativity
（神似TBBT中的Amy Farrah Fowler）
三、软工冷知识——Let It Crash
程序崩溃（Crash）很多时候是我们所尽力避免的。听说在上届的面向对象课中，如果你没有接住异常而使程序崩溃，难么你会被“恭喜得到0分”。然而这却是Erlang的编程哲学之一。Let it Crash告诉我们不要让程序“带病运行”，而是尽管让其崩溃——然后解决bug。当然，我们很难想象Margaret Hamilton会认同这种哲学。但可以说，只要能保证系统能快速崩溃（fail fast）并快速恢复（recover fast），我们仍然可以乐观地看待它。
四、流行的源程序版本管理软件和项目管理软件的优缺点及用户数量调查
· Microsoft TFS
优点：由数据库存储源码，性能较高；与开发工具集成度高；源码管理无存储限制。
缺点：搭建、维护复杂；对硬件的要求较高。
· Git
优点：分支能力强大；支持离线提交；分布式推送拉取。
缺点：子模块管理不完善，多repo继承困难。
· GihHub
优点：基于web的版本管理；对Markdown有着很好的支持。
缺点：不易学，入门较慢。
· Bitbucket
优点：免费支持私有仓库；同时支持hg/git；
· Trac
优点：权限体系完备。
缺点：不支持多项目；中文化不完整。
· Bugzilla
优点：不收费；中文版支持。
缺点：只能管理缺陷。
· Apple XCode
&emsp优点：编译速度快；原生支持撤销、重做和保存功能。
缺点：版本更新后时常导致插件失效。
· 用户数比较
| 名称 | 用户数量 |
|---|---|
| GitHub | 31,000,000 |
| Bitbuket | 5,000,000 |
| Launchpad | 3,965,288 |
| SourceForge | 3,700,000 |
| GitLab | 100,000 |
五、源程序版本管理软件实践
对比Git和Mercurial两种版本管理软件的简单版本控制过程——创建一个文件，然后将其删除。
· Git
· Mercurial
可以看到，它们最基本的版本控制流程都是：修改文件->添加至暂存区->提交形成本地版本。二者使用皆比较顺畅，且可以用过log中的历史版本信息回退至任意版本。基本不需担心误删的情况。