软工第一次阅读

所属课程：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平台东西的开发吧。