软件工程第一次阅读

阅读《构建之法》后的一些问题

1、第三章“技能的反面”

年轻学生都志向远大，上了一些课，就很想解决高层次的问题。一些学生非常想做高层次的“科研”，觉得“工程”是基础，没意思。而且他们认为“我已经知道怎么做了”。

我认为现在这个问题还是普遍存在的，进入了计算机系以后感觉同学们的水平还是有差距，毕竟有些人先前接触过编程，或者已经对计算机十分熟悉，但有些同学是初学者，在学习了一些基础知识以后，就很着急地去做一些很深奥的研究。我曾经也想去实验室里做一些项目，但是发现自己的基础水平实在不够，什么东西不会就现场查，用了以后就忘记了。还是要认清楚自己的实力，通过不断练习，把最底层的问题解决以后，才能去解决更高层的问题。

2、关于第四章中的两人合作

在4.5.2中，作者提到“在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。”

之前对结对编程的理解有误，认为是两人一组讨论之后各自分配任务，然后各自完成各自的部分。而书中这种结对编程的形式在我看来开发效率会降低，特别是两个人的水平层次不一样的时候。书中强调了结对编程的优点：能够随时复审和交流，省下来很多修改测试的时间。但我的疑问是，两个人一起开发，本来能够用两倍的效率被缩减到了一半，并且在交流过程中可能会浪费很多时间。并且两个人如果开发习惯不同，思维方式不同，很容易产生分歧。

在阅读相关论文"Case study: using pair programming in development of a complex module."[1]后，论文提出了结对编程需要满足的条件：

1、结对成员必须在一些编程观念上达成一致

2、结对成员之间必须保持良好的交流，愿意相互合作

3、结对成员技术知识必须具有可比性。如果一个经验丰富的成员和一个没有经验的成员一起工作，他们可以建立良好的指导关系，但他们不同的经验水平不利于有成效的结对编程。

可见结对编程也是有一定适用范围的，并且开发效率也要看具体的情况，不确定的因素十分多。

3、第六章中的敏捷流程

找出完成产品需要做的事情—Product Backlog。Backlog翻译成“积压的工作”、“待解决的问题”、“产品订单”，都可以。产品负责人主导大家对于这个Backlog进行增／删／改的工作。

看到这个地方我还是不太明白Backlog是需要如何来制定和展现，如何评定优先级和进行初始的评估。文章后面也提到，各个需求和任务之间是由各种复杂的依赖关系的，这是我们在除了优先级意外需要考虑的。

而且如果有优先级相等的任务和需求并且无依赖关系，可否将两个backlog平行执行呢？

4、第十六章中的创新迷思

"其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。"

这个地方引起了我的思考，为什么一些先行者会最后在竞争中被淘汰呢。书中提到了Intuit这个公司，是第四十七个进入个人财务软件这个市场的，最后却成为行业的老大。

我在网上上查阅了Intuit的历史,在和微软的竞争当中，微软的Microsoft Money软件由于设计人员的经验不足而设计周期过长，Intuit就利用经验的优势缩短升级产品的推出周期来打击微软。另外，微软并没有全力以赴夺取Intuit的市场。表面上，微软拥有编程队伍的豪华阵容，但就个人财务软件领域来看，1994年，Intuit有1000多名雇员专职于个人财务软件和相关软件研究，微软专门从事该领域的仅60人左右。

在企业的竞争中，强与弱并不是绝对的，一个有效的竞争策略加上公司资源的合理配置和使用，往往起到决定性的作用，因为巨人也并非无懈可击。

5、第十五章稳定和发布阶段：砍掉功能

“沉没成本”（Sunk Cost）从你做事的历史来看，如果类似的功能需要N个单位时间才能最终完成，那么我们没有理由相信新功能会花少于N个单位时间。

在临近发布的时候如果有一个模块看来不能实现预期的设计需求，时间快到了，书中建议砍掉该功能。在实际的开发中，我也有遇到过相关的问题，总是想着再花点时间把功能赶紧做出来。在网上查阅了沉没成本的相关概念，“沉没成本”是指以往发生的，但与当前决策无关的费用。从决策的角度看，以往发生的费用只是造成当前状态的某个因素，当前决策所要考虑的是未来可能发生的费用及所带来的收益，而不考虑以往发生的费用。

人们在决定是否去做一件事情的时候，不仅是看这件事对自己有没有好处，而且也看过去是不是已经在这件事情上有过投入。但是这些不可回收的支出其实对未来的效益并没有改善。

“软件”和“软件工程”

软件最早是由Alan Turing在他1935年的关于可计算数字的论文中提出的，但他所指的软件并不是我们今天所理解的软件。最早在工程背景下出版的术语“软件”是在1953年8月由Richard R. Carhart在兰德公司提出的。
“软件工程”一词第一次出现在1965年6月出版的“COMPUTERS and AUTOMATION”中。玛格丽特·汉密尔顿（Margaret Hamilton）提出了将该学科命名为“软件工程”的想法，以此作为赋予其合法性的一种方式。

常用源程序版本管理软件和项目管理软件分析

在维基百科上找到了开源版本管理软件的排名

1、github：约31,000,000用户量
2、SourceForge：约3,700,000用户量
3、Bitbucket：约5,000,000用户量
4、GitLab：约100,000用户量

各种项目管理软件的优缺点：

Microsoft TFS
- 优点：任务版上能将需求、项目进度一览无余，对于小团队而言，它集成了项目管理、版本控制、BUG跟踪，能有效实现SCRUM与VS无缝接合。易于管理，熟悉的界面以及与其他Microsoft产品的紧密集成。允许持续集成。
- 缺点：个人成本上的消耗相对来说更大一些。整个系统是用 asp 实现的，用浏览器访问相当慢。搭建与维护过程麻烦，硬件要求高。始终需要连接到中央存储库。执行签入和分支操作的速度很慢。
Mercurial
- 优点：从版本控制迁移很容易；提供很好的文档；分布式模型；使用python轻松扩展。
- 缺点：只有命令行系统，没有官方的GUI；所有加载项必须用Python编写。
Git

Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。作为一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。
- 优点:
  
  1．适合分布式开发，每一个个体都可以作为服务器。每一次Clone就是从服务器上pull到了所有的内容，包括版本信息。
  
  2．公共服务器压力和数据量都不会太大。
  
  3．速度快、灵活，分支之间可以任意切换。
  
  4．任意两个开发者之间可以很容易的解决冲突，并且单机上就可以进行分支合并。
  
  5．离线工作，不影响本地代码编写，等有网络连接以后可以再上传代码，并且在本地可以根据不同的需要，本地新建自己的分支。
- 缺点：上手不是很简单，需要时间磨合
Trac
- 优点：
  
  1、Trac是一个SCM配置管理平台，意味着它有良好的扩充性
  
  2、Trac的权限体系是比较完备的设计
  
  3、非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
- 缺点：
  
  1、不支持多项目，
  
  2、需求和缺陷没有分离，
  
  3、用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了，
  
  4、核心功能很少，不安装插件基本上没法用。
Bugzilla
- 优点：
  
  免费的开源的一款功能强大的Bug管理系统，比如强大的检索功能，强大的后端数据库支持, 丰富多样的配置设定等；
- 缺点：
  
  安装需要Perl和配置MYSQL数据库，过程比较繁琐，修改配置文件比较麻烦；英文版的，能汉化但是汉化后容易出现乱码；