个人博客作业-阅读构建之法

个人博客作业

快速阅读教材，列出仍然不懂的5到10个问题

1 回归测试

教材中2.1.3写到

在3.1.5版本，模块A的编号为125的测试用例是通过了的，但是在新的版本3.1.6上，这个测试用例却失败了，这就是一个倒退。工程师们应该在新版本上运行所有已通过的测试样例

我有一点疑问，新的版本的软件可能在新加的部分有缺陷，也可能是因为破坏了以前的功能，或者是二者链接起来出了问题，而要检测这样的bug需要跑所有的测试，这样是否会有很大的时间成本开销？是否有好的方式能够把新增的代码单独测试？以及用更通用的测试去验证流程的正确性？

2 如何理解软件的泛化？

在教材3.2中写到

过早扩大化\泛化

请问如何理解泛化？为什么过早泛化不是很好的事情？

3 瀑布模型和生鱼片模型

教材 5.3.2中提到

生鱼片模型是瀑布模型的变形

请问生鱼片模型和瀑布模型有什么不同？各自有什么优缺点？

4 认知阻力

教材中12.2提到

倘若认知阻力大，学习曲线就会比较陡；但是经过学习和练习，如果用户适应了新的认知模式，工作效率就会有较大的提高

我认为这并不完全正确，有些时候，认知阻力大是因为软件团队没有考虑完全用户的使用简便性，以及给出清晰的说明文档，所以造成了很大的认知阻力。

比如LaTeX在安装，编译过程中的一些报错和版本有很大关系，以及缺少像git那样有interactive的教程，如果增加这些内容的话，软件的认知阻力大大减少。

再比如colmap和vsfm都是三维重建中非常优秀的软件，但是colmap用的会简单很多，因为colmap给出了详细的教程和文档来适应不同的人群。

在软件开发的过程中，我认为要考虑不同用户的认知能力和需求，不能一味让用户适用自己的认知模式。

5 验收测试和构建验证测试

请问构建验证测试和一般的验收测试有什么区别。

6 敏捷开发

书中6.5提到

我们需要敏捷的开发流程，但是不需要冲忙或者忙乱的开发流程

请问在敏捷开发中，什么样的设计模式和软件架构能够适应敏捷开发的流程？在招聘中，如何判断一个成员是否能够胜任敏捷开发的工作？

请问软件和软件工程这些词汇是如何出现的？

软件这个词最早出现在Tukey 1958年的论文， “The teaching of concrete mathematics", 包含了soft ware这个词
软件工程（software engineering）这个词由Hamilton发明，最早在阿波罗计划中就出现了这个理念，在hamilton之前，没有人很在意这一工程的实践方法。

软件工程开发的过程中有什么有趣的冷知识和故事

分享一个关于科学写作神器tex的故事

高德纳在写完TAOCP第三卷的时候，觉得排版技术太粗糙，于是开始开发tex, 本来以为半年时间就能开发完，之后可以用方便的工具写作，没想到用了十年时间。 tex的版本号码也非常有趣，每次在小数点后面加入一个新数字，高德纳曾经表示等自己过世后把版本改为\(\pi\) 那时任何漏洞都被当做程序的功能。

版本管理软件优缺点

1.git

优点
- 用户群广泛
- 代码库占的空间少
- 易于代码的分支管理
缺点
- 图形界面差
- 学习难度高

2.Bugzilla

优点
- 开源
- 和很多测试管理工具继承
- 自动文档
缺点
- 用户群不广泛

3.trac

优点
- 定制化
- 权限丰富
缺点
- 缺乏中文支持
- 学习成本高

4.github

优点
- 代码资源丰富，用户群广
- 免费
缺点
- 速度慢

5.apple xcode

优点
- 自带完备的profile工具
- 可以自动跟踪函数调用
缺点
- 自定义功能不方便
- 编辑功能不如vs, sublime强大

6.svn

优点
- 操作简单
- 中文支持好
- 没有使用难度
缺点
- 功能不完善
- 占据空间较大

工具使用

git

使用git进行版本管理十分方便，我尝试了以下功能

工作区到index
\\ 从工作区添加到index(staged, cache)， 或者开始追踪文件
Git add file
\\ 从index里面取消对文件的追踪
Git rm —cached
Git rm -f file \\ 从工作区和Index都删除
\\ 从index里取出文件并且放回到工作区
Git checkout —- file


index到版本库
\\ 把Index的文件提交到版本库
Git commit -m “message“
\\ 把index文件提交到版本库并且不创建新的commit, 自动和上一个commit合并
Git commit —amend
\\ 把版本库的文件取出放到index, 同时版本库也回退
    Git reset commit ID
\\ 某些把版本库里的取出放到Index
    Git reset [commit ID] file
\\ 查看之前所有commit, 重返未来
    Git reflog
\\ git reset 


查看不同点
\\查看变化 尚未缓存的改动
    Git diff
\\已经缓存的改动
    Git diff —cached
\\查看已经缓存和没有缓存的所有改动, HEAD可以替换成其他的commi id
    Git dfiff HEAD
\\文件移动 同时修改工作区和暂存区的某个文件名称和位置
    Git mv 

远程操作
\\添加remote
  Git remote add [name] [url]
\\ 从远程取回
  Git fetch [remote] [branch]
\\   查看改动fetch回来的内容和本地的有什么差别
git log -p FETCH_HEAD
\\ 当前的三个工作目录与远程的分支合并
    Git merge
\\ pull操作
    Git pull = git fetch + git merge
\\ 查看remote的url
    Git remote -v
\\ 重命名
    Git remote rename [ori_name] [new_name]
\\ 删除
    Git remote rm [remote name]

分支管理
\\创建分支
    Git branch [branch name]
\\切换分支
    Git checkout [branch name]
\\删除分支
    Git branch -d [branch name]
\\将分支的commit合并到当前分支
    Git merge [branch name]
如果merge失败的话， git会把成功的放到index， 不成功的放到工作区， 然后自己修改文件后再add， 再commit

历史查看
\\ 查看全部commit
    Git log
\\ 简洁版本
    Git log --oneline
\\  分支合并拓扑图
    Git log —-oneline —graph
\\ 逆向查看
    Git log —reverse —oneline
\\ 查看指定用户的日志
    Git log —author

GIT标签
\\ 到了项目的历史性时刻， 用git tag打一个标签
    Git tag -a [tag name]
\\ 如果忘了打标签， 可以追加的
    Git tag -a [tag name] [commit id]
\\ 查看所有标签
    Git tag
\\ 删除标签
   Git tag -d [tag name]
\\ 查看标签里的版本修改的内容
    Git show [tag name]
\\ push tag
    Git push [remote name] [tag name]