软工个人阅读作业二
读一本400页的“教材”？这是当我拿到《构建之法》的第一反应。平时我并不擅长读书，因为我读的很慢，总是一字一句的读（一本500页社科类的书花了我一个寒假的时间），更不用说是教材了。
可是当我真正开始读这本书的时候，我发现他并没有想象中的那么“教材”。这本书很特别，他从非常全面的角度系统的对“软件工程”这个词进行了描述和解释；书中有非常多的链接（这对喜欢看故事的我十分不友好）；有长篇幅的例子；这些都说明了，这并不是一本普通的“教材”。
说起来，它更像是一本故事书，从故事里讲道理。这才让我能在一周之内将它大致浏览完。
问题：
Q1.到底什么样的功能才有必要实现？
说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：
如果一架民用飞机上有一个功能，用户使用它的概率是百万分之一，你还要做这个功能么？你会选择：
- 根本不考虑
- 如果没时间实现这个功能就算了
- 做了，但是不用告诉用户
- 做了，而且不厌其烦地告诉用户如何使用
你会如何选择呢？选择之后，这个功能究竟是什么呢？
对于这样的选择，如果说选1.2或3，那请考虑飞机的安全功能。说实话，我在读到这个例子的时候第一反应：确实，有些恍然大悟，好例子。可是过了一会：等等...
我相信这个例子的出发点是好的，在书的一开始，就需要给读者们建立一种思维：软件工程的思维。我们需要全方面的综合考虑软件的功能。但是其实这并不是个很好的例子，因为这个例子就没有“全方面”考虑。
介绍这个例子使用的是非常明显的春秋笔法：行文中虽然不直接阐述对人物和事件的看法，但是却通过细节描写，修辞手法（例如词汇的选取）和材料的筛选，委婉而微妙地表达作者主观看法。过分强调的是这个功能的被使用概率，而忽略的是这个功能的重要性。
其实这个角度不难想到，因为安全功能很重要，所以就算使用概率再小也需要完成。所以从衡量一个功能用不用去实现的角度上来讲，只关注概率，这个例子非常差劲；但是他确实在开头就给了读者一个足以持续思考直到读完整本书的问题——到底什么样的功能有必要实现，如何从各个角度衡量功能？在第八章【需求分析】有详细的讨论。
Q2.文档这个东西在软件工程里到底是个什么地位？
最近我和上交的同学在共同开发一款体量非常小的游戏。在团队里5名成员只有2名是计算机专业，其他则是几乎没有太多工程经历的同学。我深刻的体会到，“想到哪儿就走到哪儿”这样的开发方式，对于不论代码的开发还是项目的合作都非常的不友好。
毫无疑问，我认为文档在任何工程中，永远排的上第一位。在书中的很多地方，我们都可以看到文档，在各个流程和步骤中占据排头的位置。在结对编程中的第一步：先写文档；项目中，完成代码后同步完成代码文档的更新。
文档分为很多：设计文档、使用文档等等。不同的文档给不同的人看，设计文档给程序员和PM看，使用文档给客户看...文档几乎可以说是除了交流之外的最重要的沟通方式了。而由于会出现功能过多，地点不允许等等情况，交流变得不太方便时，文档就显得极为重要。
或许他们不太明白就算是小体量游戏的开发也需要设计文档，但是在我和同学的劝说下，设计文档才最终落稿。而我们得到的反馈是：真的没有想到，只是光写一个设计文档，就会遇到很多以前从来没有想过的问题。
Q3.原来我真的不了解用户，原来真实的用户并不是我想象的那样
这句话出自P159第八章【需求分析】的一个案例。
我平时接触的同学都是计算机专业的，我平时上的网站都geek味或hacker味十足。我几乎从来不用qq，我从来不上百度贴吧，我从来不打游戏，我不用360也不用任何杀毒软件，我不用hao123做主页。我没事看看google reader，我翻*墙上twitter和facebook，我常逛hacker news和quora，我乐于尝试国外的各种新鲜酷站，我从来没为软件或服务付过费。
原来我并不了解海量中国用户，原来真实的用户并不是我想象的那样。
以前我不理解为什么360的装机量那么大，现在我懂了：1.海量用户并不知道如何管理使用电脑，360那种傻瓜式的一键解决才是他们需要的，2.他们不想花钱，但是不会找什么“破解版”，“序列号”，“注册机”
以前我不理解为什么hao123这么“弱智”的网站能有这么大影响，现在我懂了，我爸爸可以通过它非常轻松的到新浪上看新闻，但如果你让他直接输入网址的话，他肯定会输入“xinlang.com”
以前我不理解为什么有那么多人愿意为了qq上的虚拟形象付钱，现在我懂了，我表姐她们只要上网肯定挂qq，而且女孩都爱漂亮爱虚荣，她们不在乎花点钱打扮打扮自己。
站在用户的角度思考问题，这其实是大家在需求分析中都懂的一件事。可是为什么还会有那么多反人类的设计？那是因为很多人并没有思考，软件的用户是谁？如果单纯的这个案例所说，我身边的人都这么做，那我就这么去开发。那么我们再来看看下面这些数据：中国网民达8.29亿，互联网从业人数1677万人。为什么要加“海量”二字？产品的用户到底是怎样的？或许这一组数组就会告诉我们答案。
我们搞清楚了用户是谁，我们还需要搞清楚用户的需求。我曾经看过一个分析设计的视频，底下有一句评论非常真实：
本人是做平面设计的，国内有很多非常棒的视觉设计师。国内的设计不好看，主要原因在于甲方审美。就那开头的网页来说，为什么国内清一色都是明亮的界面，而苹果官网是黑色？我记得甲方说过一句话“画面黑黑的，像是给死人看的”。就是有这么多的顾虑，限制太多。在色彩搭配方面，目前最能体现高级感的要是就是黑白灰了。
所以书中所说：获取用户需求甚至需要人类学调查，与目标用户“同吃同住同劳动”或者说是“Put yourself in other's shoes.”
需求分析和设计一门非常复杂的学问，我看过各式各样的分析设计和产品的视频，总结起来大概只有一句话：一切优秀的设计永远是站在人文关怀的角度去创造产品。
Q4.如果你懂的太多，会假设用户也懂很多，但是......
既然说到了【需求分析】，那么必不可少的就是【用户体验】了。这个问题在P270被提出：
果冻：我觉得我们团队成员最懂这个软件和需求，应该有我们来主导用户界面的设计，把我们软件的使用方法告诉用户。而不是一味的做各种试验或采访去问用户。
阿超：懂得做多的人，未必能做最好的交流。我们可以做下面的实验：
在一个团队中，任意挑出一个代表，她站到大家的面前，心里想一个大家应该都知道的歌曲，然后在心里唱，用手把节奏打出来。那么问：有多少人能猜出她心里唱出的曲子？
这里的例子也可以用来说明上一个问题：当你成为一名电脑高手时，你可以会去想周围的人也都是电脑高手。而你周围的人大多数是学计算机的，或者是互联网从业者，他们绝大多数都是电脑高手。这一点会加深你的判断，从而导致你犯下上一个问题例子中的错误：不懂用户。
这本书我觉得写的非常不错，但是我的阅读体验并没有很好。很多时候我很想去读现实中发生的故事（或者说是名人的故事），而这本书偏偏把这些都放在了链接里。虽然它考虑的很周到，还配有相应的链接二维码，但是这对于我这种看书不想再去拿手机的人确实不友好。
只是，当我看到【用户体验】这一章时，我静下来仔细思考：为什么他要这么做？为什么在书中编造的例子出现次数远多于真实的例子？为什么他们那么喜欢把故事放在链接里？
或许是因为这是一本教材，编造的例子更加适合清晰地讲述每一个知识的逻辑；现实的例子比较复杂而且更加难以捕捉，所以编书的人将它们放入了链接。可能这个理由并不会让我满意，但我的态度逐渐从埋怨转变到了理解。或许这也就是这本书给我带来思考的变化吧。
Q5.单元测试应该由谁来写？
这个问题很值得思考，甚至拓展一些，可以思考：bug到底由谁来de？
就在写这篇博客的过程中，我就偶然的发现了微信的一个bug：在windows端微信3.1.0.67版本中，引用一个人说的话然后发送后撤回，重新编辑，此时就会出现关于这条消息的源代码。为了保护隐私，我把里面的部分信息删去了。
<msg>
<fromusername>*******</fromusername>
<scene>0</scene>
<commenturl></commenturl>
<appmsg appid="" sdkver="0">
………………此处省略很多行标签和内容
</appmsg>
<appinfo>
<version>1</version>
<appname>Window wechat</appname>
</appinfo>
</msg>
没想到我也曾经参与了微信debug的行列。正当我想向微信反馈的时候，我同学告诉我说，其他地方你还没有测过呢。听完之后我虎躯一震：这不就是书上的原话吗？
测试代码应该覆盖代码的每一个分支。
（我记不清在哪里了，应该在比较靠前的位置）
于是我把手机端和ios端也都测试了，发现只有windows端有这个问题。正当我再一次想反馈给微信时，我的同学告诉我，新版本微信已经修复了，并附上了一张版本号的截图（3.1.0.72）。于是我失望的关掉了微信继续这篇博客的撰写。
但这件事引起了我的思考：究竟需要一个怎么样的团队，才能让软件没有bug？我们假设在产品上架前就要把所有的bug消灭（大家肯定也都要这么想），所以我们尽量避免让用户来“找”bug。
首先毋庸置疑的一点是，代码的测试人员一定需要熟悉代码。可是写单元测试的一定就需要是作者本身吗？我一点我不敢苟同，或者说在某些情况下，我不赞同。
在像微信这样的大团队里，一定有非常多优秀的工程师，他们在不同的岗位来创造微信这款产品。产品越复杂，产品的开发和测试就越有可能不是同一个人甚至是同一个团队的人。为数不多的码龄告诉我，de不出来bug的时候就换换脑子，睡一觉说不定就de出来了。所谓“当局者迷，旁观者清”，“不识庐山真面目，只缘身在此山中”，很多时候程序员比较容易陷入自己的定势思维中，这会很大程度上让他忽略一些看似明显的分支。
而对于我们这样的学习的人来说，自己写单元测试则更加重要。毕竟别人很可能读不懂自己的代码，在体量不大的情况下，写单元测试也对代码有更加深刻的理解。这或许也就是这本教材所说的“单元测试代码需要作者来写”的原因吧。
源代码版本管理软件调研
这里，我大致比较了一下Github/GitLab/Bitbucket三种源代码管理软件的异同。
共同点：
- 基于git的管理系统
- 拥有不同级别的仓库和权限
- 支持CICD功能
不同点：
- 除了支持Git外，GitLab还支持Google Code，Bitbucket和FogBugz。而Bitbucket还支持SVN、CodePlex等
- GitLab在Github支持错误跟踪系统的基础上，还支持基于Web的代码编辑功能
- GitLab的权限设置比Github更加丰富。
GitLab CI
这里我对OO_pre_task1的作业写了简单的测试程序并部署了CI，通过了测试。
Github Action
同样我讲上面的项目传到了github上，并且创建了github action的测试，最后结果通过。
