第一次阅读作业

课程链接：

https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass1

作业要求链接：

https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass1/homework/2713

课程目标：

.建立博客并介绍自己；

.阅读与思考；

.提有质量的问题；

.了解和调查源程序版本管理工具；

获得的帮助：大量的博文，教材，Google

我的博客地址：

https://www.cnblogs.com/X----Y/

其他参考文献：

.娄老师的心得：

https://www.cnblogs.com/rocedu/p/6143494.html

.徐宥老师的掉进读书的兔子洞https://book.douban.com/subject/4006425/discussion/22802960/

.娄老师的如何提问：

http://www.cnblogs.com/rocedu/p/5167941.html

.著名黑客ESR的提问的智慧：

http://www.dianbo.org/9238/stone/tiwendezhihui.htm

.张洪君-微软AzureDevOps(TFS):

https://www.cnblogs.com/danzhang/p/5707116.html

.JINGYAN的细数目前流行的“源程序版本管理和项目管理软件”优缺点：

https://www.cnblogs.com/JINGY/p/5271594.html

.邹欣老师的《构建之法》第三版。

 

       老师今天布置这个作业时，说实话，开始时还会抱怨，也许是因为不会做，怎么做；也许是因为任务太多，占用了玩的时间。但是当我开始敲我的第一个字母时，突然感觉好充实，好有意义。所以，有了接下来的一段话：

 

　　我呢，一个平平凡凡的纯种单身狗一枚，说实话，我也不知道我有啥闪光点，我爸妈就经常说我继承了他们两人的共同的缺点（哈哈，我知道这是开玩笑的，手动滑稽）。

　　上大学前，一直都是按部就班的学习，在一所全封闭的学校里上了六年学，都是日复一日的安排，所以也没什么课本之外的学习。

　　上大学后，喜欢上了轮滑，学会了平花（自吹自擂），当然，任何事情都不是一蹴而就的，需要积累，一路上的跌跌撞撞也是必然会经历的。

　　我呢，还喜欢音乐（五音不全），有时也会在寝室一展歌喉（?自行想象）。最近在学尤克里里，学的时候呢（嗯，一言难尽?），也有想放弃的时候，但是每当这个时候，我就会去看看那些网上还厉害的演奏者，然后又会充满信心。

 

　　所以，人生如是，当你快要搁浅的时候，回首看一下那片近在咫尺的大海，眺望一下最初的那个目标，给予自己希望，给予自己前进的动力。

 

　　还记得当初知道高考成绩后，在填志愿的那一段时间，我老妈好激动，什么都要操心，一直给我洗脑让我去学医（到现在都还在说），而我呢，义无反顾地给她说我要读计算机类的专业，可能是因为当初在学校里对电脑的接触很少，于是就一直对这个充满兴趣，于是后来就报了软件工程专业。

 

　　刚上大学时，我还对软件工程这个专业懵懵懂懂，就是一小白。在过去的两年中，接触到了各种各样的专业课程，说实话，和我最初的期待是挺不一样的。在我最初的理解里，老师会教得很深很彻底（╮(╯-╰)╭），然而事实并不是这样，老师只会教一些比较浅显的东西（或许是因为要考试，要完成教学目标吧），更多的东西需要自己去钻研，需要自己去寻找，去理解。如果只学老师教的那点知识，那你会发现，与你上同样的课，但你与同学的差距越来越大，越来越迷惘。所以，该醒悟了……

 

　　软件工程这个专业，怎么说呢，又爱又恨。当你完成目标的时候，那种自豪感、喜悦感是什么也比不了的。但是在这个专业里更多的是打脑阔（?四川话），当你进入一个死胡同的时候，哪怕是再小的一个错误，你也找不出来，然后就原地爆炸（夸张了?）。要问这是不是我擅长的领域，只能说勉勉强强算吧，因为我也没什么其他擅长的邻域，如果硬要说一个，那就只能是玩了（?）。

 

　　对于未来，我肯定会选择在成都从事软件开发工作，最开始绝大可能就是一名码农，能怕到哪个层次去就不好说了，对于公司肯定是越大越专业的好哇。现在19岁，30岁左右就可以光荣退休转战其他领域了。哈哈，理想很丰满，现实很骨感。将来的我不是现在的我，将来的事谁有说得定呢？所以，努力吧，骚年。

 

　　还有几个月，我的大学四年就走完一半了，到现在，说实话，自我认为还差很多，现在的状态就是学得快也忘得快，真正能印在脑海里的其实不多，大多数知识都只有一个框架。到现在为止呢，我们已经学了C、数据结构、C#（感觉只是一点皮毛），有过自己编写一些简单的系统的经验，已经写过的代码量也就只有七八千行得样子吧，上大学的第一学期很懒，没怎么自己写，一般都是写老师布置的作业。现在呢，回想起当初的懒惰，真的挺后悔的，浪费了那么多时间在一些毫无意义毫无营养的事情上面。至于离一个合格的软件工程专业本科毕业生，在专业知识上来说，只能说有基础了吧；而在技能、能力上，在各个方面来说都还差很多吧。

 

　　对于大三这个十字路口，我家里人都希望我去考研，我呢，曾想过出来就直接去找工作，但是现在，我犹豫了，也醒悟了。我觉得徐宥老师的博客说的很对，深入积累，书到用时，无心插柳，面试也好，考研也好，写论文写好，都是一键一键敲出来的，也是一本书一本书读出来的。做什么事情，都需要积累，只要现在踏踏实实的走好每一步，甚至走出原本的道路去踩出另外一条路，就不会在做决定时做出一个让自己后悔的决定。让将来的那个他去庆幸有个现在的你。

 

　　在看到这个任务时，我就先去看了娄老师和ESR大牛的提问心得。好吧，看完之后再去看书，因为知识粗浅的快速的读了一遍，所以发现想要提出一个有质量的问题好难。所以为了完成任务，我在这里也只能提出几个蠢问题了（自己都找得到答案的那种）：

1.结对编程：（4.5）

结对编程，英文是 Pair Programming，是一种编程模式，从字面上理解就是两个程序员并排坐在一台电脑前，面对同一台显示器，他们一起进行需求分析、设计、编码、编写测试用例、执行单元测试和集成测试，甚至一起写文档。因为结对编程没有强弱之分，而驾驶员和领航员又是可以互相交换的。所以，如果驾驶员和领航员在互相交换职责的时候（两人都在自己原本的岗位上累了，时间又很紧凑），两个人的思路想法完全不一样时，我们该怎么处理？

2.两人合作的不同阶段和技巧：（4.6）

如果两个人因为种种原因在萌芽阶段就直接跳过了磨合阶段进入规范阶段，而在之后发生了，种种的摩擦，就像现在的闪婚一样，第一眼看对眼了就直接领证了，婚后又爆发种种摩擦，然后处理不好，关系破裂。对于这种情况该如何有效的处理？

3.需求分析（8）

在软件功能完成的差不多之后，若用户需求和优化化后的软件起冲突时，要按照用户的需求继续做还是优化的软件？   

4.项目经理（PM）(9)

一个优秀的PM该如何有效的分配任务？该具备哪些品质？

5.实战中的源代码管理（11.6）

如何在有很多本地修改的电脑上快速获得一个干净的代码环境？

有多个文件都是关于同一个功能的修改，你要如何保证这些文件都能同时签入成功，或者同时签入不成功？     

6.用户体验（12）

当你的软件最后成功发布了，但是之后的用户反馈极差，这时候该怎么处理？

                                                                                                                   

对于目前流行的源代码版本管理软件和项目管理软件：

Microsoft TFS:

整体的优点：

任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG跟踪。

能有效实现SCRUM，能与VS无缝接合。

单在源代码管理方面，TFS的优点：

1) 易用性。
在用户习惯上，TFS秉承了微软所有产品的特新，开发人员非常容易上手。软件使用过程中，用户会发现与日常导入操作系统、开发工具（VS），Office软件等有很多共同的体验。
2) 高度集成其他工具。
TFS高度集成主流的开发工具和常见的办公工具。
例如Visual Studio, Eclipse, XCode, ItelliJ，
例如Excel, 浏览器，Project
同时，TFS提供方便的API（.NET API, Java API, Rest API）集成，可以与企业现有的系统实现数据共享
3) 高度集成研发团队的工作项目
可以通过TFS的源代码，查询到代码变更的依据（需求、任务、Bug等）
反过来，可以通过项目管理的数据（需求、任务、Bug等），查询到相应代码的变动。例如，你可以查询到修复Bug所修改的代码行数。
4) 支持分布式代码库（Git）
除了支持集中式代码库（SVN属于此类），TFS还支持分布式的源代码库Git。这为TFS开拓了分布式代码管理的一个广阔天地，是SVN望成莫及的。
5) 搁置集
可以通过TFS将代码保持在服务器上，但是不签入到代码库中，实现将你的变更保存在服务器上一个临时的位置。这样，既备份了自己的代码，有不会影响其他团队成员的代码。
6) 代码评审
TFS提供基于开放工具的便捷的代码评审机制，可以实现研发团队内部之间的代码评审，或者与外部专家的代码评审。
7) 后台数据库存储
TFS的所有源代码和版本信息都存储在数据库中，在大型软件研发团队中，可以大幅提升数据的查询和存储速度。
同时，基于数据库存储，系统管理员可以方便的备份和还原TFS中的任何数据。
8) 代码搜索
TFS提供非常方便的代码搜索功能，开发人员可以在代码库中基于方法、类、对象等查询相关文件和代码。
9) 快速修改代码
你可以不需要任何开发工具，在浏览器上就可以完成代码的修改功能。
10) 自动化生成和发布
开箱即用的TFS就集成的自动生成和发布功能。可以实现修改代码以后，生成和发布自动完成；也可以在发布过程中增加流程控制，例如需要项目经理审批才能继续发布过程。

缺点：

搭建、维护TFS比较复杂，硬件要求也比较高。

    整个系统是用ASP实现的，用浏览器访问相当慢。

Git/GitHub:

优点：
1.免费且开源。
2.用于敏捷高效地处理任何或小或大的项目。
3.Git支持分支功能（branch）。如果你想开发一个新的产品功能，你可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。
4.可拿Git做备份系统，或者同步两台机器的文档，很方便。
5.支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
6.Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
7.Git 中的每个工作树都包含一个具有完整项目历史的仓库。
8.简易的初始化。对于随便写两行代码就要放到代码管理工具里的人来说，再合适不过。
缺点：
1.学习成本大。由浅入深的过度很漫长，需要大量时间的投入。
2.Git版本库需要频繁的手动维护

Mercurial(hg):

优点：
1.学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
2.可以一键完全恢复到历史版本的某一个切面。
3.封装好。相比git，hg很少暴露一些实现内的细节。
4.照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，目标其实是为了5.让 svn 用户更容易接受。这使得已经习惯 svn 命令的团队，几乎零成本的切换到 hg。
6.hg 的 pull 更多的时候可以让你避免创建分支。hg 好比苹果系统，git 好比 Linux，前者在常用命令上更好用更易用，后者在功能上更强大更灵活。
7.hg的版本库不需要维护。
缺点：
1.分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。

 

转载于:https://www.cnblogs.com/X----Y/p/10554810.html