个人作业四--Alpha阶段个人总结

一、个人总结

在alpha 结束之后， 每位同学写一篇个人博客， 总结自己的alpha 过程；
请用自我评价表：http://www.cnblogs.com/xinz/p/3852177.html 有比较才会有进步。

二、回答问题

我们在课程开始之初，曾经要求大家针对软件工程提出问题：个人阅读作业2，那么在经过alpha阶段，大家是否对软件工程有了一定的了解？请结合自己提出的问题进行回答

Q1：初级软件工程师如何成长？什么是好的软件设计思想？什么是好的软件工程思想？

• 软件工程师可以如此成长
  • 我认为，初级工程师之所以为“初级”，是因为本身能力有限，那么就需要打磨自己的专业，“较小的领域”更容易做出让人印象深刻的成绩，作为初级工程师，要在较小的领域精益求精。
  • 第二点是不懂就问，虚心求教。没有人一开始就什么都懂，都是一点一滴积累起来的知识。听来的学问一定要和实践结合，深刻理解并运用才算真正的掌握。
  • 第三，要能有效管理自己的工作，最好是有一套指标来衡量，越是有明确的指标，就越有能力推动研发的行为。

• 好的软件设计思想

  软件设计是从软件需求规格说明书出发，根据需求分析阶段确定的功能设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。

  好的软件设计思想是能够把上面提到的任务很好地完成并连接在一起，从一开始就必须想好怎么实施，将问题或事物分解并模块化使得解决问题变得容易。

• 好的软件工程思想
  还是有四个要点：迭代开发、以系统架构为中心、持续的质量保证以及管理变更和资产。要做就要做一个有“生命力”的软件，不断修复bug，更新版本，注入新的活力软件才能存在得更久。

Q2：结对编程会出现的问题

• 我认为结对编程的利弊还是因人而异了。结对的双方若是编程水平差太多，或者两人根本不熟悉也不了解对方的编程习惯，结对编程的作用很明显就会弊大于利了。当然在工作中一般不会出现水平相差太多的情况，毕竟能成为同事也是不容易的事呢。如果说为了长远的利益，结对编程是必要的，那么就有必要花些时间去磨合了，不管是以什么样的方式。

• 反之，结对编程的好处就会多多了。就如书上提到的那样：

  在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。

Q3：在稳定和发布阶段，无关大局的缺陷非得马上解决吗？修正方案中又有缺陷怎么办？

  到了稳定和发布阶段，软件已经成型，bug一直都有，有的可以解决，有的目前无法解决，自己也经历过了敏捷开发，明白其实无关大局的缺陷不必马上解决，尤其是快要发布的时候，那时可能做不到修正缺陷后再发布，所以可以等到适合的时机再行修改。软件都会有迭代，一般来说，每次迭代，都会修复已发现的bug，或是新增其他的功能，对用户来说，最重要的是要有良好的体验，在不影响这一目标的情况下应当允许某些bug的暂时存在。前面也说了，bug总是会有，世上没有完美的东西，也不会有完美的软件，给你完美的感觉只是当下，只是浅层面的，后面迭代的至少都会比之前的版本好。

三、再提问题

同时，大家一定会在实践过程中产生更多问题， 结合你的读书（教材，博客，参考书）， 实践， 再提出关于软件工程的 5 个问题。

Q1：书本P16提到很多人认为有Bug就是质量不合格，没有Bug就是质量完美，其实这也未必。

  我认为“Bug”也是因人而异的，对某些人来说是缺陷，对某些人来说这正是特点。就如书上举的例子，裤腿上有洞的牛仔裤，像是年轻人就认为这很fashion，没什么问题，而“老年人”就认为有洞是质量不好，应该拿去退换。汽车有那么多品牌，各有各的好，有些人注重性能，有些人在意外观，等等，在他们眼里“好”是不同方面的，而销售人员就需要针对不同需求的用户推销适合他们的产品，结果才是皆大欢喜，否则最后销量未必理想。

Q2：书本P79提到谁来做代码复审？即最有经验、熟悉这一部分代码的人。

  最有经验、熟悉这一部分代码的人难道不是开发者本身吗？复审者是在替开发者干开发者本应干的事情那么是否需要安排专门的人来做代码复审呢?

Q3：书本中第五章列举了很多团队模式：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式等等。

  这么多模式，怎么清楚定位自己的团队是什么模式呢？而且我认为每个阶段的模式可能不一样。

Q4：书本P122提到敏捷对团队的要求和简单：自主管理（Self-managing）、自我组织（Self-organizing）、多功能型（Cross-functional）

  事实上我们大学生还不能算一个成熟的团队，敏捷开发对我们来说很困难，每个人毛病挺多，能力也不强，所以老师让我们敏捷冲刺，也只是在时间驱动下完成项目而已。或许老师只是让我们体验一下敏捷开发的流程，但是我们真的能有所感悟就好了。就如书上所说：

如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反，往往需要经历多次失败/总结/改进的过程才能让Scrum走上正轨。

Q5：书本P281提到的“灰箱”是什么？我们该怎么选择白箱、黑箱、灰箱呢？

所谓白箱就是机制和结构完全明了的系统，如同电视机对电视发明制造者来说就是“白箱”。

所谓灰箱，就是相当部分的结构机制已经明了，但并没有完全明了的系统，如电视机对一个并不高明的修理者来说就是“灰箱”。

所谓黑箱就是结构机制完全不明了，仅仅知道输入输出信息之间某些简单关系的系统，如电视机对一个根本不懂电器的用户来说，他只知道打开钮就亮、闭掉钮就灭一样。