【软工】第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的具体任务：

1. 带领团队造成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
2. 管理软件的具体功能的生命周期（需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰）；
3. 建立并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍；
4. 表明客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各类需求的优先级；
5. 分析并带领其余成员对缺陷/变动需求造成一致意见，并确保实施；
6. 带领其余成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件；
7. 收集团队项目管理和软件工程的各类数据，客观分析项目实施过程当中的优缺点，推进项目成员持续改进，从而提振士气。

可是我认为，在本课程中，为了使咱们的软件可以推广出去（毕竟仍是很想有用户量和用户反馈的），PM除了上述任务，还应负担起市场调研、竞品分析、运营推广等工做，彷佛加入了许多产品经理的活儿。

而这些任务所有加起来，对于产品经理的要求是很高的，他必须懂市场、懂调研、懂营销、懂管理、（他可能还想借着软工课锻炼本身的代码能力，好比承担一部分测试工做），这样的人可能难以寻找或快速培养。此时是找一个最合适的人顶上去培养成全职PM，仍是找几个程序员兼职作PM（顶一个诸葛亮），是一个问题。具体以为还须要看项目团队的定位和目标吧。

问题5：在这个时代，创客们更须要注重哪一种创新？

书中（P349 16.1.6 迷思之六：技术的创新是关键）提到：

咱们在这里看到，除了技术的创新，还有不少方面的创新：商业模式的创新…用户体验的创新…生态系统的创新…

说到创新，我就想到了创业，若是从一个创业者的角度出发，他应该最看重什么方面的创新呢？

在我看来，首先确定不是生态系统的创新。缘由有二：

1. 现在各个领域的生态系统大都比较完善。
2. 即使找到了一个生态系统的可创新之处，造成一个新的生态系统也很难，由于生态系统这是大而空的“链接方式”，里面须要有具体的“链接物”，即产品或服务。然而，原来的生态系统虽然不完善，但确定已经有了一些市场占有者，不管是将他们联系起来，仍是去白手创造本身的产品或服务系统，都是比较难的。

其次，创客们最应看重的，也应该不是用户体验的创新。在这个网站找到了用户体验的方方面面：

我以为这方面用户要求很高，产品的用户体验也比较完善了。若是要进行用户体验的创新，可能更多仍是技术支持下的创新，好比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的开发之中。

1. 他本来觉得他只须要半年时间，在1978年下半年就能完成，但最终他用了超过十年时间，直到1989年TeX才最终中止修改。
2. TeX的版本号码也十分有趣。从TeX第三版开始，以后的升级是在小数点后加入一个新数位，使之愈来愈接近圆周率π的值。TeX目前的版本是3.1415926。这显示了TeX已经十分稳定，任何的升级都十分细微。高德纳曾表示“最后一次升级是（于我过世后）将版本数改成π，那时任何余下的漏洞将被看做程序的功能。”
3. TeX是很是稳定的程序，高德纳悬赏奖励任何可以在TeX中发现程序漏洞（bug）的人。每个漏洞的奖励金额从1美分开始，并每一年翻倍，直到目前的327.68美圆封顶。然而高德纳从未所以而损失大笔金钱，由于TeX中的漏洞少之又少，而真正发现漏洞的人在得到支票后，宁愿将其裱起来留做记念也不肯拿去兑现。

第四部分 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

在维基百科找到了用户量：

排名由高到低主要依次是：github, bitbucket, launchpad, sourceforge

优缺点列表以下：

项目	优势	缺点
git	可用性好，方便；用户和项目多，利于交流学习；对git版本库提供了完整的协议支持；功能强大；	对中文支持太差；国内访问速度太慢；前期学习知识较多
Mercurial	命令兼容SVN；扩展性强；学习门槛较低；基于Python，服务器配置相对于Git更加容易	功能太过简陋；分支管理不灵活；中文使用资料匮乏。
Trac	SCM配置管理平台；十分灵活，支持定制；	不显示中文名，中文支持不好
Bugzilla	定制功能很强；免费，支持中文	功能不及GitHub；UI不够好