【软工】第1次阅读作业
| 项目 | 内容 |
|---|---|
| 这个作业属于的课程是 | 2019BUAA软件工程 |
| 作业要求是 | 第1次阅读作业要求 |
| 我在这次的目标是 | 系统学习软件工程的理论知识并成功应用到实践中来 |
| 这个作业在哪些方面帮助我实现目标 | 通过阅读《构建之法》以及进行相关的调研工作，对软件工程的理论知识有了更进一步的认识 |
第一部分 快速看完整部教材，列出你仍然不懂的5到10个问题
问题1：单元测试应该由谁来写？
书中（P25 2.1.2 好的单元测试的标准）提到：
单元测试必须由最熟悉代码的人（程序的作者）来写。
此言一出，我立马想到大二下的面向对象课程，大家经常在私底下交换测试用例，原因大概就是“三个副将，顶个诸葛亮”。编程者如果没有考虑到要处理某一个特殊情况，那么他就不可能设计相应的测试，从而错误地认为自己的代码是完美的。为了防止这种情况发生，大家往往会私下共享测试样例，以保证自己的代码能应付一些特殊情况的输入。
虽然“三个副将，顶个诸葛亮”具有一定的合理性，但是却无法运用在实际中：
- 从单元模块的角度讲，实际的软件工程中，出于成本和效率的考量，一个单元模块主要由一个人进行负责，没有人会跟你做同一个单元模块来防止所谓的“一个人可能考虑不周”，而若由单独的测试人员进行单元测试，往往工作量大，周期长，耗费巨大，其结果事倍功半（参见这里）。
倒不如雇佣/培养一个诸葛亮。 - 从系统测试的角度讲，共享测试样例这个事儿，对于OO课来说，是两个人的共享测试，可对于软件工程来说，是两个团队的共享测试，而后者是不可能发生的（一个公司总不会用两个团队去开发完全一样的软件）。
所以，我还是比较同意书中作者的观点：单元测试还是应该由“最了解代码的目的、特点和实现的局限性”的作者来完成，而且“最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义”。
问题2：何时使用goto语句更为合理？
书中（P69 4.3代码设计规范）提到：
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
这两句简短的话让我回忆起C语言的教程中往往明确写着“尽量不要使用goto”，原因大概是跳来跳去的容易使程序结构不清晰。但是书中随后给出的代码清单4-2又让我觉得加上goto语句确实逻辑挺清晰的。
下面是书中代码清单4-2：
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;
}
在阅读了博客1和博客2后，总结出goto的优缺点和结论大致如下：
- 缺点：GOTO语句使程序的静态结构和动态结构不一致，从而使程序结构不清晰，难理解，难查错。去掉GOTO语句后，可直接从程序结构上反映程序运行的过程，不仅使程序结构清晰，便于理解，便于查错，而且也有利于程序的正确性证明。
- 优点：使用起来比较灵活；有些情形能提高程序的效率。若完全删去GOTO语句，有些情形反而会使程序过于复杂，增加一些不必要的计算量。
- 结论：不加限制地使用GOTO语句，特别是使用往回跳的GOTO语句，会使程序结构难于理解，在这种情形，应尽量避免使用GOTO语句。但在另外一些情况下，为了提高程序的效率，同时又不至于破坏程序的良好结构，有控制地使用一些GOTO语句也是必要的。
至于作者提到的“函数最好有单一的出口，为了达到这一目的，可以使用goto”，这篇简短的博客给出了单出口函数的两种代码结构，一种是使用goto，另一种是使用do while(0)和break。本人觉得更偏好goto语句来实现。（毕竟虽然写高级语言时没用过goto，但是写汇编语音时对goto已经比较接受了）
私以为作者可以在书中对goto语句多做些说明，毕竟可能有一大波人学C的时候也跟我一样没太弄懂。“既然课本说别用goto，那我不用就是了”。
问题3：对于结对编程不大认可，还需实践检验。
书中（P79 4.5 结对编程）提到：
- 在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等等。
- 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，工作一小时休息15分钟。领航员控制时间。
对于这样的结对编程方式，我从直觉上，还是比较持怀疑态度，毕竟两个人的水平可能不同，思路也可能不同，需要调研的东西可能也不同，比较难以达到同频道的状态（比如我对C++不大熟练一些语法问题可能还需要现场百度）。
直觉上是怀疑，但是行动上还是要试试看的。个人认为可以在某些阶段进行结对编程，其它一些时间就并行编程。（感觉需要先好好理解作业要求，细致地划分多个阶段和模块，调研一下算法，熟悉一下语言，然后再看哪些部分要结对编程，哪些部分要并行编程。）
问题4：PM在本课程项目中的具体任务
书中（P189 9.3 PM做开发和测试之外的所有事情）提到在一个项目中PM的具体任务：
- 带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
- 管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）；
- 创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍；
- 代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；
- 分析并带领其他成员对缺陷/变更需求形成一致意见，并确保实施；
- 带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件；
- 收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。
但是我认为，在本课程中，为了使我们的软件能够推广出去（毕竟还是很想有用户量和用户反馈的），PM除了上述任务，还应负担起市场调研、竞品分析、运营推广等工作，似乎加入了许多产品经理的活儿。
而这些任务全部加起来，对于产品经理的要求是很高的，他必须懂市场、懂调研、懂营销、懂管理、（他可能还想借着软工课锻炼自己的代码能力，比如承担一部分测试工作），这样的人可能难以寻找或快速培养。此时是找一个最合适的人顶上去培养成全职PM，还是找几个程序员兼职做PM（顶一个诸葛亮），是一个问题。具体觉得还需要看项目团队的定位和目标吧。
问题5：在这个时代，创客们更需要注重哪种创新？
书中（P349 16.1.6 迷思之六：技术的创新是关键）提到：
我们在这里看到，除了技术的创新，还有很多方面的创新：商业模式的创新…用户体验的创新…生态系统的创新…
说到创新，我就想到了创业，如果从一个创业者的角度出发，他应该最看重什么方面的创新呢？
在我看来，首先肯定不是生态系统的创新。原因有二：
- 如今各个领域的生态系统大都比较完善。
- 即便找到了一个生态系统的可创新之处，形成一个新的生态系统也很难，因为生态系统这是大而空的“连接方式”，里面需要有具体的“连接物”，即产品或服务。然而，原来的生态系统虽然不完善，但肯定已经有了一些市场占有者，无论是将他们联系起来，还是去白手创造自己的产品或服务系统，都是比较难的。
其次，创客们最应看重的，也应该不是用户体验的创新。在这个网站找到了用户体验的方方面面：
我觉得这方面用户要求很高，产品的用户体验也比较完善了。如果要进行用户体验的创新，可能更多还是技术支持下的创新，比如VR。
最大的PK可能还是商业模式的创新与技术的创新。我在这篇报道中，发现了许多不同的声音：
- 寻找中国创客发起人、北京文投集团总经理戴自更认为，现在模式创新的时代已经过去，科技创新才是常青的风口：
过去因为抓住了移动互联网爆发的契机，中国的新经济取得了一些成绩，但这些成绩很大程度上得益于商业模式的创新，以及依赖巨大的人口红利实现模仿中的超越。他认为，现在模式创新的时代已经过去，科技创新才是常青的风口。
- 中国创客导师、信中利资本集团创始人、董事长汪潮涌认为，对于AI产业来说，技术和算法难以成为AI产业的核心壁垒，唯一道路是成为伟大的AI产品公司。
AI创业者面临“落地之痛”。商业化之路要以技术为基础、用户需求为导向、落地场景为核心，想要成为巨头，就要成为伟大的AI产品公司。目前单纯靠技术和算法的红利期已经过去了。新成立的AI公司应该打“组合拳”，而不止做技术服务商，随着技术门槛降低，离用户需求最近的产品经理和行业专家将成为团队的主导，两者的结合可以形成产品经理和技术专家为主导的产品级的公司。
- 中国工程院院士、香港中文大学（深圳）校长徐扬生认为，更重要的是技术创新，但是要注意从解决市场需求的角度入手。
深圳龙岗有很多创新企业，但商业模式的创新比较多，技术创新比较少。深圳和硅谷的差异在哪里？硅谷做的事是0到1的事，是科研上的创新，而深圳做的是1到N的事。只有“0到N”才是技术和产业的创新。过去，人工智能领域常常是有了技术之后才去找落地应用、推动产业化，但成功的很少。创业者们应当着眼于市场的需求，从如何解决市场需求入手，反推再去进行技术方面的落地。
我比较支持最后一个观点，“更重要的是技术创新，但是要注意从解决市场需求的角度入手。”
第二部分 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：
- 软件的第一个理论诞生于1935年，由计算机之父阿兰图灵提出。但是同时也有人认为，是化学家和统计学家约翰·图基（John W. Tukey）在1958年撰写一篇科学文章时，首次使用“软件”这一术语。
软件工程：
- 1968年北大西洋公约组织在联邦德国召开的国际会议上，为了讨论软件危机课题，Margaret Hamilton 正式提出并使用“软件工程”（Software Engineering）的这个名词。提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”转化。
第三部分 软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
以下内容来自知乎
著名的计算机科学家高德纳（Donald E. Knuth），在他的巨著《计算机程序设计艺术》（The Art of Computer Programming，TAOCP）出完第三卷后，终于对当时粗糙的排版技术忍无可忍，毅然暂停写作，转向后来在学术界满载声誉的排版软件TeX的开发之中。
- 他原本以为他只需要半年时间，在1978年下半年就能完成，但最终他用了超过十年时间，直到1989年TeX才最终停止修改。
- TeX的版本号码也十分有趣。从TeX第三版开始，之后的升级是在小数点后加入一个新数位，使之越来越接近圆周率π的值。TeX目前的版本是3.1415926。这显示了TeX已经十分稳定，任何的升级都十分细微。高德纳曾表示“最后一次升级是（于我过世后）将版本数改为π，那时任何余下的漏洞将被看作程序的功能。”
- TeX是非常稳定的程序，高德纳悬赏奖励任何能够在TeX中发现程序漏洞（bug）的人。每一个漏洞的奖励金额从1美分开始，并每年翻倍，直到目前的327.68美元封顶。然而高德纳从未因此而损失大笔金钱，因为TeX中的漏洞少之又少，而真正发现漏洞的人在获得支票后，宁愿将其裱起来留作纪念也不愿拿去兑现。
第四部分 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
在维基百科找到了用户量：
排名由高到低主要依次是：github, bitbucket, launchpad, sourceforge
优缺点列表如下：
| 项目 | 优点 | 缺点 |
|---|---|---|
| git | 可用性好，方便；用户和项目多，利于交流学习；对git版本库提供了完整的协议支持；功能强大； | 对中文支持太差；国内访问速度太慢；前期学习知识较多 |
| Mercurial | 命令兼容SVN；扩展性强；学习门槛较低；基于Python，服务器配置相对于Git更加容易 | 功能太过简陋；分支管理不灵活；中文使用资料匮乏。 |
| Trac | SCM配置管理平台；十分灵活，支持定制； | 不显示中文名，中文支持很差 |
| Bugzilla | 定制功能很强；免费，支持中文 | 功能不及GitHub；UI不够好 |
