软工第一次阅读

所属课程：https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_RJ/
所属做业：https://edu.cnblogs.com/campus/buaa/BUAA_SE_2019_RJ/homework/2626
课程目标：及格，在此基础上尽可能多拿点分。
做业回报：_(:з」∠)_看了N久书……百度了N次……

1. 阅读

1

2.1    "因此，写单元测试没有比做者更适合的人选了。"

首先我以为写好一个单元测试自己是和写好一个功能有时候是等价的事情。

咱们何时会写很差一个功能呢？

• 有时候是由于粗心、失误写错了一部分代码。这种错误就是脑子里的代码和写下来的代码不一致。
• 有时候是由于对他人写的模块的功能的误解。这种就是脑子里的代码和别人已经写下的代码不一致。
• 而有的时候是由于对功能自己的理解就不对。也就是脑子里的代码自己就不对。

本身写的单元测试对于前两种错误是有效的，但对于第三种错误是无效的。

那么第三种错误该如何避免呢？我以为让别人来写单元测试是一种可行解。一我的理解错误几率较高，两我的就比较低了，三我的就更低了。

因此我以为写单元测试的最合适的人选不该该只是代码做者自己，还应该包括功能指定人，就是负责设计产品功能的人，甚至包括想用这个产品的人。

2

3.1 "软件工程的奠定人之一瓦茨·汉弗雷总结说，软件领域能够分为两个方面：一方面是技艺创新的大爆发；而另外一方面是坚持不懈的工程工做，包括软件的改善、维护和测试等，这一方面占了90%—95%的比例。"

我对这句话用在我的评价这里是否合适抱有疑问。

按照个人理解，他所说的应该是整个软件的工程实现中，工程工做占据了90-95%。也就是说，对于团队内部处于不一样层级的工程师而言，工程工做的占比应该不一样。

一个高级的工程师可能不该该老是在作可重复的任务？一般的认知应该都是这样的才对。

因此我认为对于一个高级工程师而言，工做中的“技艺创新的大爆发”可能不止5-10%？那么将标准方差做为评价标准就是一个有待商榷的方式了。

3

3.3 技能的反面

我以为不该该将低层次的问题解决变成不用通过大脑的自动操做，由于咱们这个行业的“低层次问题”变化过快、过大。

我在上大学前基本是只敲C那一族的语言的，刚上大学那会儿对一些基本的代码确实能够不经大脑思考来自动操做。可是这对我学习新的语言造成了障碍，由于我已经构建了不少条件反射了。说到这个就是那个，←就这种感受。

固然，也能够再对新的语言进行训练，而后又多一族新的条件反射。可是如今这样每月几乎都有新的技术的环境下真的值得去进行这种训练吗？我对这个观点抱有疑问。

4

4.2 "另外，注释（包括全部源代码）应该只用ASCII字符，不要用中文或其余特殊字符，不然会极大地影响程序的可移植性。"

这点我以为在如今的编程环境中有待商榷。如今支持utf8编码形式源代码的编译器不在少数，不如说正在变成主流的感受？

不过我也相似地以为注释不该该使用中文，理由不是编码带来的移植性问题，而是由于如今进行开发每每是全球性的。代码丢到github上之后鬼知道fork的人是哪国人了。

5

4.3 "函数最好有单一的出口，为了达到这一目的，可使用goto。"

诚然，示例中的Goto Error这类状况，使用goto确实能使得代码更加清晰。但应该避免使用goto这点从我学编程开始就一直被这么说着了。

我以为在缺少合适的异常处理机制，或者一些特殊的内核代码实现的状况下，使用goto是能够的，确实有助于代码逻辑的清晰、实现的简洁。但若是仅仅只是为了单一出口而使用goto我以为不可。

我以为多处使用return致使了多个函数出口带来的坏处是小于过多使用goto致使的零散代码块的弊端的。

6

4.4 在todo标记那里加上人名

我以为一份代码的存在应该独立于人，也就是说，不该在代码中标注人名，这样要是团队中发生了人员更迭，那就须要修改代码来更新这些人名标记，而这种代码修改要是出如今提交历史里面我以为是一种冗余，由于并无任何功能上的更新，而只是行政的变化。

我以为经过外部的管理软件来指定负责人更好。

7

4.5 "若是团队的人员要在多个项目中工做，不能充分保证足够的结对编程时间，那么成员要常常处于等待的状态，反而影响效率。"

此次的疑问不是对书的疑问，而是对课程的疑问。由于事实上咱们大学生就是处在这样的状况。咱们有多个项目，并且由于选课制致使项目还都不太同样。咱们不得不互相等待对方的时间。

8

5.2.5 秘密团队

这种模式感受不适用于雇员团队，而只适合创业团队那种感受。这种对团队成员自身的能动性、自律性等等有较高要求。

举个例子，目前公认的一个结论是较小的生态圈很难自给自足，稍小的扰动就会致使生态系统崩溃。对于团队也是这样的。秘密团队意味着和外界隔绝，也就是造成了一个独立的较小环境。对于这种环境的可靠性、可维持性，我报有疑问。

2. 调研软件

software: 2000, Fred Shapiro, "The Teaching of Concrete Mathematics"
软件工程：阿波罗11号的软件开发期间，Margaret Hamilton

4. SCM比较

经过stackoverflow的这个调查能够看出，绝大多数人都用git。

• git: git是我一直在用的，或者说我周围人也一直用这个。在我看来这就是SCM的基准点吧。

• TFS: TFS我以为更像是个团队软件开发管理程序，git的功能只是它的一个小分支罢了。在微软实习的时候用过一小会儿，事实上那时候我提交代码其实仍是用git提交的，而后review之类的行为的时候才是登上TFS去搞的。

• mercurial: 这个按照这篇博客的说法，是易用性比git强。

• github: 呃……github不是一个独立的SCM吧，我总以为它内核用的仍是git。我猜测这指的是github desktop。这也是我一直在用的，我以为这玩意儿主要是让上手更容易了。github desktop用起来可比git bash顺手多了。并且github提供了个随手就能存的源代码管理网站，变得可以随意使用git了，虽然得open-source就是了。

• bitbucket: 这个我偶尔会查到某些库用这个网站来存着。和github同样，我总以为这货应该也是用mercurial做内核，而不是一个独立的SCM。根据这篇博客的说法，bitbucket更注重私人仓库，github更注重公开仓库。

• trac: 这个根据它官网上的介绍，它和TFS相似是个团队软件开发管理程序，不过trac是开源的，并且基于BSD，这意味着能够定制本身的trac。

• bugzilla: 这个彷佛是个bug追踪系统，虽然也是个团队开发管理程序，但侧重于bug追踪。

• Rational: 根据百科的介绍（我打不开IBM上rational的页面……），这彷佛是个巨大的开发平台，反正是要钱的，格调很高的样子。

• Apple XCode: 根据官网上的介绍的介绍，这是个IDE吧……并非一个独立的SCM，但支持挺多SCM的样子。这个应该主要都是ios平台东西的开发吧。