软件工程第一次阅读作业

项目	内容
作业所属课程	BUAA_SE_2019_LJ
作业要求	第一次阅读！

1. 看完教材《构建之法》，列出仍然不懂的问题。

1. 如何在团队中建立相互信任的关系？

   MSF提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间。

     这句话来自书中7.2.3节。“充分授权给团队和成员”意味着团队成员之间是相互信任的，只有在信任的基础上才能给团队成员充分的授权。不过即使没有信任，也是可以对这个原则生搬硬套的，但是这就将信任流于形式了。首先，信任是双向的，第二，团队成员应该是值得被信任的。在一个新组建的团队中，团队成员尚且不能相互认识，如何快速地建立起真正的信任呢？

2. 在软件开发中，如何应用建模方法？

     这个问题来自11.2节的“图形建模和分析方法”。这一节介绍了多种图形建模的方法，我也在之前的课程中使用过ERD、DFD、UML，但结果是，就是书中所说的，有了模型，却不知道下一步该做什么，或者，模型与后续的工作脱节，模型没有能够给之后的实现予以足够的指导。最后，画图的目的就是为了画图。出现这个问题，我觉得可能有这样的原因，模型与最终实现抽象层次不同，对于那些实现中的复杂细节，不知道应该如何体现在模型中，在模型中应该体现多少，或者说，在设计模型的时候，应该体现哪一个层次。那么，如何才能将建模方法融入软件的设计和实现中，避免为了建模而建模呢？

3. 如何进行量化的绩效管理？

     17.6节介绍了衡量个人在团队中的绩效的方法，例如根据工作量，bug数量，队友评估等等。每一种方法都有一定的合理之处，但又存在着明显的不足。

   纯粹强调外接的驱动因素（金钱的报酬或惩罚）仅仅对体力劳动或有明确规则的活动有效（奖金约定，结果越好），但对于需要创造性思维的活动，即使是简单的认知能力的活动，更多奖金反而起到相反的效果。

     如果认为软件工程师的工作是“需要创造性思维的活动”，按照书中的观点，我们在进行绩效管理的时候就需要注意内部的驱动因素。现在的问题是，课程评分中有一项团队贡献分，需要在团队成员中分配，我们不得不面对如何量化个人绩效的问题。那么是否存在一种量化绩效的方法，能给出每个人贡献的比例呢？

     下面给出我的愚见。既然内部驱动因素影响着团队成员的工作效率，不妨从内部驱动因素入手。关注“自主性”，书中解释说“由自己决定工作的部分内容”，我认为在绩效评比的时候也发挥自主性，每个人主张自己的贡献比例，给出自己做了什么，对团队的贡献在哪里，有多大，分析为什么是这个比例。然后团队成员在一起讨论，每个成员分别对其余每个人的主张发表意见，最终讨论得出一致结论，确定每个人贡献的比例。如果这种方式能够施行的话，应该比计算代码行数或bug数会好很多。

4. 为什么每日构建很重要？

   我们的软件构建，就和脚手架一样，每天都要立着，倒下了就麻烦了。

     这句话来自11.5.2每日构建一节。这个比喻很形象，也符合直观，不过我还未能给出具体的论据来支持这个观点。

5. 如果错误的情况很多，怎么进行错误处理？

     书中4.3.3节错误处理说到，“如果你认为某事可能会发生，这时就要写代码来处理可能发生的错误情况”，如果错误的情况很多，要照顾每一种可能的错误，就需要编写冗长的代码来进行错误处理，这一过程就比较机械和繁琐。比如编译器在进行错误处理时，错误的情况无穷无尽，即使要分出每一种错误的类别都是很花时间并且容易遗漏的。这种情况下，我经常怀疑，是否有必要处理每一种可能的错误，有没有一种好的方法能够帮助分析各种可能的错误情况而无遗漏？

2. 请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

• “软件”是由John Tukey于1958年在其论文"The Teaching of Concrete Mathematics"中提出来的。
• “软件工程”一词是由Margaret Hamilton创造的。在1968年北约科学委员会召开的会议上正式使用。

3. 【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

"It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter."

- Nathaniel Borenstein

Explanation

查看解释

  Borenstein说，没有哪个经过职业道德培训的程序员会写出DestroyBagdad过程，基本的职业道德告诉他们，应该写一个DestroyCity过程，而将Bagdad作为一个参数。
  这段话的幽默之处在于，读者会认为程序员的受到的道德(ethics)教育与其他人相同，比如“不要杀人”，“做一个好人”之类的，然而，Borenstein说的是程序员的职业道德，具体地说，就是编码时的一系列规范(coding ethics)，用于在软件工程中写出高质量的代码。
  这段话有一定的误导性，但又不完全是，这就是其幽默所在。要理解这段话，需要琢磨ethics一词的含义，翻译成中文后，由于找不到合适的词，反倒丧失了几分幽默。

4. 上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？ （提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode）?

1. Microsoft TFS: 测试管理和软件生命周期管理工具

   优点：

   • 与Visual Studio等微软产品集成得很好，易于使用
   • 容易访问，可以从客户端、浏览器和Visual Studio访问
   • 源代码管理方面：方便的签入/签出
   • 项目管理方面：易于管理bug

   缺点：

   • 网页的用户界面和用户体验比较糟糕

2. GitHub: 提供代码管理，软件协作开发的平台，用户数31,000,000

   优点：

   • 漂亮的UI
   • 可以与很多开发工具集成
   • 使用Git便于代码管理
   • 方便代码复审等多人协作

3. Git

   优点：功能强大，很好地处理分支，适合大型项目使用

   缺点：难于理解，对初学者不友好

4. Mercurial

   优点：比Git易于使用

   缺点：比Git功能弱，没有部分签出功能，不适合大型项目

5. BitBucket：用户数5,000,000

   优点：

   • 仓库和项目的管理简单易使用
   • 有方便的可视化工具显示分支
   • 与Atlassian产品集成得很好

   缺点：

   • 相比GitHub，缺少第三方工具的集成
   • 搜索方式不如GitHub丰富

6. BugZilla

   优点：缺陷报告可以到处，支持多项目的缺陷跟踪。

   缺点：不支持自定义界面