《构建之法：现代软件工程》阅读和发问

阅读提问

快速看完整部教材《构建之法：现代软件工程》（教材还没买到的同学，可以先看邹欣老师的博客园讲义），列出你仍然不懂的至少五个问题，发布在你的个人博客上。

1. 在结对编程的过程中，如果两人水平相差较大，会不会导致效率低下？
   • 书中提到结对编程是为了提高效率，要求不间断的复审从而减少错误。
   • 但如果水平相差较大，将会有大量的时间被浪费在解释代码和思路上，也可能陷入某个技术细节的争论中无法自拔。
   • 在实际工作中，水平较高的一方通常会承担更多的工作，这样反而效率更高，从而让较弱的一方少做少错，并在闲暇时间阅读代码提升水平，做一些力所能及的工作。
2. 敏捷开发中，如何正确预估一个任务的时间？
   • 书中提到敏捷开发中，任务的时间应该是由开发者自己来评估，而不是由项目经理来安排。
   • 但是前文中也提到，开发者可能会因为自己的主观意识而过于乐观或悲观，导致任务时间的不准确。
   • 在实际工作中，可以通过历史数据来评估，但是这样的数据可能会因为人员变动、技术变化等原因而失效。
   • 特别是对于刚接触到软件工程的学生来说，这个任务更加艰巨。如何在学习软件工程，实践敏捷开发中提升预估任务的能力？或者说有什么方面需要注意？
3. 如何在团队创建的初期快速熟悉互相之间水平，找准每个人的定位和适合其负责的工作？
   • 书中给出了很多团队的模式，从最初级的一窝蜂模式，到功能团队模式，官僚模式等.
   • 但其中更重要的是，如何熟悉团队成员的水平，找准每个人的定位和适合其负责的工作，结合起来选择一个适合团队的模式。
   • 在我们团队的组建中，参考上届学长的经验，创建了一个有明确分工的业余剧团模式。团队角色有 PM，前端，后端，运维，架构等。但在团队讨论每个人负责的部分的时候，就连我们自己也很难说是否能完成自己的任务，或者说是否适合该任务。
   • 目前我们的解决方案是，按照当前的任务分配下进行尝试，然后根据实际情况随时调整。
4. 如何将合适地任务进行分解，即分而治之？
   • 书中提到 WBS 策略需要将大型任务分解成小任务，然后再分配给团队成员。在此期间各个任务不能互相覆盖，同时也不能有遗漏，还要保证每个任务足够的小。
   • 那么，PM 作为一个并不一定精通于技术的角色，通过怎样的方式才能确定每个任务合适的粒度？在分解的过程中有什么好的实践法则？是采取个人决策，还是集体决策，抑或是专家决策？
5. 什么时候进行扩大化 / 泛化？
   • 书中提到了过早扩大化 / 泛化会带来会使得软件变得复杂，难以实现，但是过晚扩大化 / 泛化又会导致软件的扩展性差，难以维护。
   • 那么在实际工作中，如何判断当前进行的任务是否需要提前抽象以适应以后可能的任务？如何掌握这个度从而在复杂度和扩展性之间取得平衡？