【软件工程】 第1次个人作业

项目	内容
这个作业属于哪个课程	软件工程 罗杰
这个作业的要求在哪里	第一次阅读作业
我在这个课程的目标是	熟悉软件开发整体流程，提升自身能力
这个作业在哪个具体方面帮助我实现目标	通过学习《构建之法》，了解敏捷编程

读《构建之法》的思考

Q1：3.1 re-work是否能够衡量代码质量呢？

     “有人试图用“re-work”来表示质量，如改动少的代码最初质量高，因为re-work的次数少。笔者认为，re-work只是表明在软件开发过程中花费的时间，re-work的多寡并不跟最终的质量成正比。”

     读到此处，我想起了2.3章节中所提到的大学生和工程师在完成任务时的时间分配比例对比。其中，工程师将更多的时间用于“需求分析”、“具体设计”上，而少量时间用于“具体编码”，其意义就是要先整体设计好在进行编码，而笔者也认为这样的工作方式是高效的。
     那么问题出现了，充分的设计的目的就是为了减少re-work，倘若某段代码需要大量的re-work来进行修正，是否也就意味着设计阶段不充分，并未为后续的编码节约时间呢？一段没有被充分设计的代码是否也可以说质量并不是很高呢？

Q2：4.3 函数中goto的使用？

     “函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。”

    犹记得之前在学习C语言时，老师尽量不要使用goto语句，因为它可能会导致程序结构比较复杂，且难以维护，还可能会使得程序存在某些隐患。
    在这里我们姑且不讨论goto语句到底是让程序的逻辑更清晰还是更复杂，我单纯地没有理解“用goto函数设置唯一出口”的意思是什么呢？书中的举例我认为完全可以写一个ERROR()函数实现，所以还是没有太理解goto语句的必要性。

Q3：4.5 结对编程真的利大于弊？

     “在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘......结对编程中有两种角色：驾驶员和领航员。”

    根据书中所说，这种编程模式需要两个人一点点磨合，一开始可能两个人的开发效率甚至不如一个人，造成“1 + 1 < 1”的情况。用这种成本来培养，是否真的值得呢？最终又真的能够达到“1 + 1 > 2”的程度嘛？一对结对编程小组中，如果一个人出现情况，如生病、出差、甚至跳槽，另一位只能孤身奋战，或是和新的伙伴再次磨合，这不确定性是否有些高呢？
    其次，书中将结对编程小组类比为赛车中的驾驶员和领航员、飞机中的驾驶员和副驾驶，但不同的是，结对编程小组中两个人的身份是不断切换的，且频率很高（15分钟切换一次），如此高的切换频率是否会浪费精力在适应身份上而无法专心于编程或设计呢？

Q4：9.3 & 9.4 懂技术的PM是否要参与开发？

     曾经我一直以为PM就是客户与开发人员的连接通道，存在意义就是将客户提出的需求转化为设计交给开发人员。读完第9章以后，才明白PM所需要做的远远不止这些，甚至PM的种类，也不是单一的一种。
     在班级中阅读到HansBug的博客，发现博客中所说的“个人承担了过多任务，而队员无法提供很多帮助，最终累垮”这种情况，与书中9.3中将PM类比为舵手有些相似。如果舵手参与划船，可能小船的速率会快一些，但方向、稳定性都会出现问题，众多队友无法协调一致，最终到了一个计划外的地方。由此可见，PM懂技术和参与开发并不是必然的关系，懂技术是好事，现在只会写原型PPT的PM比比皆是，懂技术起码不会给开发部门提出难题，但并不意味着要直接参与到开发中去，正如9.3的标题“PM做开发和测试之外的所有事情”，做好需求分析、设计好产品，这本身也是对工程的很大帮助。

Q5：14.2 优化该何去何从？

     “分工之后，每个角色为了自己的绩效而优化，会出现局部最优而全局未必最优的情况。”

     读到这个地方的时候我不禁想起了之前第三章中提到的：“过早的优化是一切罪恶的根源”。所以到底应该何时优化呢？前期代码质量过低会导致后期优化任务过重，前期优化过多又会导致限制了全局的上限。而且该按照何种顺序进行优化呢？

Q6：17.4 猪、鸡和鹦鹉的故事

     *“猪：提供猪肉，坐熏肉。
     鸡：提供鸡蛋，做煎蛋。
     鹦鹉：提供咨询，每天阅读大量博客，给其他团队成员提供建议......

     ** 猪——全身心投入 鸡——参与 鹦鹉——围观 *”

     这是个很有趣的比喻，重点在于要认清自己在一个团队中的位置，“不要拿着卖白菜的钱，操那卖白粉的心”。但同时，也说明了一个稳定的团队，其核心竞争力还是在于“猪”的能力，“猪”可能指的是PM，可能指的是开发部门的老大，他一定是扛起公司的一分子，而他的综合实力，决定了公司的实力。或者说，把能力强的人吸引到自己的团队中，也许他最初只是“鹦鹉”或“鸡”，但团队的前景吸引着他加入团队变为“猪”，这个团队就一定会越来越好。倘若找了一群“鹦鹉”组成团队，最后也只落得作鸟兽散吧。

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

• 软件
      化学家和统计学家约翰·图基（John W. Tukey）在1958年的论文“The Teaching of Concrete Mathematics”中提出了“软件”这一概念，用来指代计算机程序，与使用程序的计算机（硬件）来加以区分。

• 软件工程
      玛格丽特·哈密尔顿（Margaret Hamilton）在1968年的“阿波罗计划”期间提出了“软件工程”这一概念。

软件工程发展的过程中，有哪些有趣的冷知识和故事？

• 第一个Bug
      在程序中bug一词用于技术错误，这一术语最初由爱迪生在1878年提出的，但当时并没有流行起来。几年之后，美国上将葛丽丝·穆雷·霍普（Grace Murray Hopper）在她的日志本中，写下了她在Mark II电脑上发现的一项bug。不过实际上，她说的真的是“虫子”问题，因为一只蛾子被困在电脑的继电器中，导致电脑的操作无法正常运行。她将这只蛾子保存在自己的日记本中，并写道“这是我在电脑上发现的第一个bug”。（从未写过bug的程序员可太强辽orz）

目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

1.Git
     - 优点：功能十分强大，适合分布式开发，速度快较为灵活，很好地处理分支，可离线工作。
     - 缺点：学习周期较长，不易上手，对初学者不太友好。

2.Mercurial
     - 优点：与Git相比学习门槛低，易于掌握。
     - 缺点：功能比Git弱，分支管理不灵活。

3.Github
     - 优点：操作简单，极为友好，开源代码多（用户量最多的同性交友平台）。
     - 缺点：（我感觉好棒想不出啥缺点qwq）

4.Microsoft TFS
     - 优点：与Visual Studio完美接合，方便小团队查看需求、项目进度等。
     - 缺点：搭建和维护都比较复杂，同时对硬件的要求也比较高。

5.Bugzilla
     - 优点：免费，有中文版，支持多项目缺陷追踪，有极为丰富的配置设定。
     - 缺点：需要Perl和配置MySQL数据库，修改配置比较麻烦。