| 项目 | 内容 |
|---|---|
| 作业属于 | 2020春季计算机学院软件工程(罗杰 任健) |
| 作业要求 | 个人博客作业 |
| 个人课程目标 | 掌握软件工程基础知识 |
| 具体有助方面 | 了解'软工'发展；了解项目管理软件 |
| 其他参考文献 | 构建之法(第二版) ，创新词条(维基百科)，软件词条(维基百科)，软件工程词条(维基百科)，Comparison of source-code-hosting facilities，Comparison of version-control software |
提出问题
《构建之法》3.1 个人能力的衡量与发展：
积累问题领域的知识和经验（例如：对医疗或金融行业的了解） ······ 随着经验的增长，一个工程师可以掌握更广泛、更深入的技术和问题领域的知识。
问题领域的知识和经验对个人能力的提高有多大的帮助，特别是对工程师来说。我对这点还是略微反对作者的观点。我认为一个软件工程师了解问题领域的知识对软件工程的进行并没有太大帮助，因为本职之外的事情，你了解的不够深入，甚至有可能产生误解等操作。
《构建之法》4.3 代码设计规范：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
goto语句的使用应该是有争议的话题，在我刚学习c语言时，很明确记得老师是要求尽量减少goto语句的使用。我想goto语句的使用与否取决于最终目的对“程序逻辑的清晰体现”。但是应该有其他的方法来体现程序逻辑，使用goto语句是不是增加了程序逻辑不清晰的风险呢？
《构建之法》16.1.3 创新的迷思之三：好的想法会赢：
这个也是我不太理解的地方，为什么更有益处或者更有效率的方案得不到推广，比如书中提及的Dvorak键盘布局与QWERTY键盘布局方式。生活中我也遇到这种例子，输入法的选择上。一般我们都是用拼音输入法，但是五笔输入法按理来说应该是速度更快的方法，还有现在有推广的双拼输入法，其效率都高于拼音输入法，但是受众相比来说仍然不多。往大了说是历史遗留问题，往小了说是用户习惯问题，创新带来的收益怎么才能更好地收获。
《构建之法》16.1.5 创新的迷思之五：要成为领域的专家，才能创新：
统计数据表明，70%的创新者说，它们最成功的创新，是在他们的拿手领域之外发现的。
我在想这个问题是不是由于在自己领域的知识学习过程中思维被束缚所导致的。而且我认为，在其他领域创新在现在这个时代可能更加困难。维基百科指出全球范围内的人均专利数正逐年下滑，显示创新的速率正在趋缓。甚至有人指出“创新程度回答道顶峰然后跌落到黑暗时代”。也许你在其他领域可能提出新的想法，但其真正的创新发展还是靠其专业人员才能发展解决。
《构建之法》16.2 创新的时机：
关于技术创新，一些趋势大家早就看到了，也有一些产品推出，但是往往最后成功的产品成功在时机上。
这个模型我觉得也不容易理解，这是不是与“产品要尽早发布”的规律相矛盾呢？现在产品的营销中，种子客户(第一批客户)是比较重要的一环，需要他们的初始资金以及推广引流等。而且优先收集用户反馈对于产品的进一步开发改进必然是有助的，其他产品发布较晚必然缺少数据无法改进产品（我认为真实用户的反馈更有分量）。
“软件”和“软件工程”
关于“软件”一词的诞生，维基百科中有如下说法
in 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that John Wilder Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years. This led many to credit Tukey with coining the term, particularly in obituaries published that same year, although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.
大致意思是说软件一词的真正创造者并不明了，许多人认为是Tukey创造了这个词，因为在他的1958年的论文“The Teaching of Concrete Mathematics”中出现了该词；Paul Niquette声称这词他在1953年10月创造，尽管没有可以支持他说法的文件；工程环境中“软件”一词的最早发表是在1953年8月，由Richard R. Carhart在兰德公司的一份研究备忘录中发表。
而“软件工程”一词，维基百科中是这样的说法
The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger;, it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering. Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy. At the time there was perceived to be a "software crisis". The 40th International Conference on Software Engineering (ICSE 2018) celebrates 50 years of "Software Engineering" with the Plenary Sessions' keynotes of Frederick Brooks and Margaret Hamilton.
来源主要有两种说法，一是出现在公司提供的服务列表中于1964年6月，并且在1966年8月出版的通讯ACM中有更正式的使用；另外也有说法是玛格丽特•汉密尔顿(Margaret Hamilton)在阿波罗(Apollo)任务期间，曾独立地将这门学科命名为“软件工程”。
一点冷知识
图片中的梗是指matlab中数组下标从1开始，而我们一般使用的c语言、java语言、c++等数组下标均是从0开始。其创始人提起过原因是因为matlab本就是为矩阵运算而生，故其下标从1开始。关于matlab的诞生是在1970年代末到80年代初，时任美国新墨西哥大学教授的克里夫·莫勒尔为了使学生更方便地使用一些工具（需要FORTRAN知识），而学生并无相关知识，于是其用FORTRAN语言独立编写出了第一个版本的MATLAB。而后成立公司，推上市场，用C语言重新编写了MATLAB并添加新功能。需要注意的是，虽然MATLAB用C语言重写，但是在矩阵存储方式上却和FORTRAN保持一致，两者使用的均为列优先存储，而非行优先存储。（在查询有关资料时注意到vb语言可以通过option base语句调整数组初始下标默认值为0或1！）
流行的源程序版本管理软件/项目管理软件
用户数量排序(根据维基百科数据略微上调)：
| Name | Users |
|---|---|
| GItHub | 31000000 |
| Bitbucket | 5000000 |
| Launchpad | 4000000 |
| SourceForge | 3900000 |
| GitLab | 100000 |
| GNU Savannah | 100000 |
| OSDN | 55000 |
| Ourproject.org | 7000 |
工具优缺点：
| Name | Strength | Weakness |
|---|---|---|
| Visual Studio Online(旧称Microsoft TFS | 任务版全面；与VS无缝接合 | 旧版本搭建困难；庞大需系统学习 |
| Git | 分布式开发，强调个体；可离线工作 | 学习周期长 |
| Mercurial | 简单易上手 | 跨平台障碍 |
| GitHub | 强调个体；用户基数大 | 中文兼容问题 |
| Bitbucket | 适合小团队 | 不开源；系统稳定问题 |
| Trac | 良好的扩充性 | 多基于插件 |
| Bugzilla | 免费；中文支持 | 智能管理缺陷 |
| Apple XCode | 自动分类图表；美观 | 系统稳定性问题 |
软件实操感受
git与github
git与github是我们最开始接触的项目管理软件，它们的关系就像弓与箭。它们组合的主要优点是分布式系统，对于团队工作非常适合，这点在操作系统课程设计这门课上感受颇深；其次其用户基数很大，遇到问题很大概率可以从网上或前辈同学那得到解决方案。目前来看缺点是学习周期较长，主要是针对git的原理以及常见操作：熟悉常见操作后，误操之后很可能一脸茫然，不知道问题在哪，所幸可以找同学帮助。根据实际操作感觉github对中文的兼容问题也有改进，没有发现中文兼容问题；不过github网站的访问有时还是较慢。
Bitbucket cloud与sourcetree
Bitbucket作为源代码管理软件，我在登录后的第一感觉是界面相对github较为清晰简单，例如查看提交历史等情况。SourceTree是版本管理软件，初次印象是图形化界面做的很棒，特别是与git图形界面对比。其操作界面比较清晰简单，特别是针对命令行不熟的同学简易上手；另外其界面的文件预览窗口、历史提交记录、分支记录等相比不熟悉命令行操作的同学，使用起来较为方便。缺点目前感受是Bitbucket免费只可以用于团队人员小于五人的项目。另外在安装SourceTree的过程后，其启动时没有找到对应的图标或者命令，是通过打开安装程序打开，可能是安装错误或者系统稳定性问题。