软件工程第一次阅读

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

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

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

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

二、关于第四章中的两人合做

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

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

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

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

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

三、结对成员技术知识必须具备可比性。若是一个经验丰富的成员和一个没有经验的成员一块儿工做，他们能够创建良好的指导关系，但他们不一样的经验水平不利于有成效的结对编程。

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

三、第六章中的敏捷流程

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

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

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

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

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

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

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

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

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

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

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

人们在决定是否去作一件事情的时候，不只是看这件事对本身有没有好处，并且也看过去是否是已经在这件事情上有过投入。可是这些不可回收的支出其实对将来的效益并无改善。

“软件”和“软件工程”

• 软件最先是由Alan Turing在他1935年的关于可计算数字的论文中提出的，但他所指的软件并非咱们今天所理解的软件。最先在工程背景下出版的术语“软件”是在1953年8月由Richard R. Carhart在兰德公司提出的。

• “软件工程”一词第一次出如今1965年6月出版的“COMPUTERS and AUTOMATION”中。玛格丽特·汉密尔顿（Margaret Hamilton）提出了将该学科命名为“软件工程”的想法，以此做为赋予其合法性的一种方式。

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

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

• 一、github：约31,000,000用户量

• 二、SourceForge：约3,700,000用户量

• 三、Bitbucket：约5,000,000用户量

• 四、GitLab：约100,000用户量

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

• Microsoft TFS

  • 优势：任务版上能将需求、项目进度尽收眼底，对于小团队而言，它集成了项目管理、版本控制、BUG跟踪，能有效实现SCRUM与VS无缝接合。易于管理，熟悉的界面以及与其余Microsoft产品的紧密集成。容许持续集成。

  • 缺点：我的成本上的消耗相对来讲更大一些。整个系统是用 asp 实现的，用浏览器访问至关慢。搭建与维护过程麻烦，硬件要求高。始终须要链接到中央存储库。执行签入和分支操做的速度很慢。

• Mercurial

  • 优势：从版本控制迁移很容易；提供很好的文档；分布式模型；使用python轻松扩展。
  • 缺点：只有命令行系统，没有官方的GUI；全部加载项必须用Python编写。

• Git

  Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。做为一个开源的分布式版本控制系统，能够有效、高速的处理从很小到很是大的项目版本管理。

  • 优势:

    1．适合分布式开发，每个个体均可以做为服务器。每一次Clone就是从服务器上pull到了全部的内容，包括版本信息。

    2．公共服务器压力和数据量都不会太大。

    3．速度快、灵活，分支之间能够任意切换。

    4．任意两个开发者之间能够很容易的解决冲突，而且单机上就能够进行分支合并。

    5．离线工做，不影响本地代码编写，等有网络链接之后能够再上传代码，而且在本地能够根据不一样的须要，本地新建本身的分支。

  • 缺点：上手不是很简单，须要时间磨合

• Trac

  • 优势：

    一、Trac是一个SCM配置管理平台，意味着它有良好的扩充性

    二、Trac的权限体系是比较完备的设计

    三、很是灵活，能够为所欲为的定制，能够和TortoiseSVN集成。

  • 缺点：

    一、不支持多项目，

    二、需求和缺陷没有分离，

    三、用 wiki 来替代 Word 等工具编写文档对于产品策划来讲门槛过高了，

    四、核心功能不多，不安装插件基本上无法用。

• Bugzilla

  • 优势：

    免费的开源的一款功能强大的Bug管理系统，好比强大的检索功能，强大的后端数据库支持, 丰富多样的配置设定等；

  • 缺点：

    安装须要Perl和配置MYSQL数据库，过程比较繁琐，修改配置文件比较麻烦；英文版的，能汉化可是汉化后容易出现乱码；

参考资料

[1][Case study: using pair programming in development of a complex module.](https://www.thefreelibrary.com/Case+study%3a+using+pair+programming+in+development+of+a+complex+module.-a0246014267)

[2]https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

[3][版本控制软件比较](https://en.wikipedia.org/wiki/Comparison_of_version-control_software)