《构建之法》阅读报告

问题一：

在“给任课老师和助教的建议”一章的第五条：“模拟实战、根据客观数据来评分”一节引发了我一直以来的一些困惑。

老师太忙，不能仔细地批阅每一次作业，不能细致地分析团队项目的每一个细节，怎么办？解决办法：把学生的作业做成比赛，比程序速度、比测试用例的数量、比博客的阅读量、比下载量······相对的分数自然就出来了。团队项目一定要做解决实际问题，能公开发布和使用的项目，这样就会有很多用户给学生们评分。例如，在2009年北京航空航天大学的课程中，一组同学开发的魔方教程软件有3万多下载；另一组同学的软件只有10个下载，谁好谁坏不难判断，不用老师去查阅代码了。

实际上，即便每一个软件都有老师亲自查阅，评分标准能够唯一确定吗？扩大说，软件市场上的软件孰优孰劣？根据用户评分？评论区的评价？下载量？可能有3亿人认为QQ音乐比网易云音乐好，依然会有1亿人更支持网易云，能直接得出QQ音乐比网易云音乐好吗？

通过在互联网上的查阅，对于软件“好坏”，或者所谓“软件考核标准”有很多不用观点，百度百科上（软件质量评估）就有多达十多项指标。本文作者提出的“程序速度”和“测试用例”都是关于软件质量中的稳定性、可靠性等，而博客阅读量和下载量则依赖于软件功能的实用性和创新等。在作者的例子里我们的确可以简单判别3w和10个下载量的优劣，但我们很难直接判定300和100下载量的软件之间的优劣，恰恰这种情况是更加普遍的，而给下载量赋上一个多大的权值加在总评分上也是值得商榷的。

总结，这是一个因人而异的问题，每个人看法甚至可能天差地别，我们的要做到软件，重点关注哪些点，哪些性能值得注意，希望老师暂且给出一套本门课程上适用的标准。

问题二：

根据作者第三章3.3节关于“技能”的相关描述：

巴克斯顿说技能的反面是“Problem Solving” —— “解决问题”，这个听起来有点绕，我们看看IT人士熟悉的一个例子吧。一个IT专业的大学生来面试，简历上写“技能：精通Visual Studio C#编程”。于是面试官请他用Visual Studio IDE写一段程序。一个“不精通”的面试者的编程过程实际上就是一个“解决问题”的过程。例如：

• 嗯，怎么开始一个C#的命令行程序呢？
• 定义数组是怎么弄的？是“int [] arr”还是“int arr []”，还是ArrayList，还是Array<>。哦，我平时都是上网查的。哦，我不知道还有MSDN网站。
• 嗯，为什么编译没过呢，哦，这里少一个分号。
• 嗯，怎么设断点？怎么定义命令行参数？额，我要查一查······

…
你发现他把时间都花在“解决（底层次）问题”上了，你要考察的“算法技能”、“C#程序设计技能”都无暇顾及。注意，这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么？
那怎么提高技能呢？答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。

这个例子太真实了，简直就是我自己的写照。

我们都知道软件工程依赖多种计算机技术包括操作系统、计算机网络、数据库等，这些都是我们必要学习的。而编程语言又是多种多样的，由于时间和精力的限制我们往往（根据经验）只能尽量“精通”一门语言。

事实上，在很多高校（包括我的本科学校河工大和研究生学校东师），在本科阶段和研究生阶段都开设了高级编程语言课程，而这些课程的基本目标大多是要求学生熟练使用某种语言，更高的标准则是要求学生通过学习该语言的过程，熟练学习编程语言的方法。

另外在实际学习和实践过程中，我们往往需要用到多门语言，在这个过程中，不得不同时进行着解决“底层次问题”和“中间层次的问题”，而所谓把所有“低层次问题”都解决了，再解决“较高层次的问题”的方法实施上存在许多问题。

问题三：

在第五章团队与流程中讲到的团队模式这一概念:

可以看出，这些团队有共同的特点：

1. 团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。
2. 团队成员有各自的分工，互相依赖合作，共同完成任务。

…
主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式…

作者列举的近十种模式确实形象地描述出了不同形态的团队合作模式，我不由想起了本科阶段唯一一次团队合作的程序，软件工程课程设计——企业管理系统，当时小组七个人的合作模式现在看来，的确符合业余剧团模式，而开发流程我们尽量按照瀑布模型严格执行，在需求分析和系统设计阶段全员参与，开发测试阶段分模块进行，最终进行程序整体测试。

然而实际过程中出现了诸多问题：

1. 因组员能力差异，分配任务很难做，最终每个人的完成情况差异也很大，甚至出现不得不由某些组员完成多个模块。
2. 需求和设计阶段的许多问题未得到重视，在开发阶段问题放大，只得亡羊补牢，同时效率极低。
3. 最初的系统设计不够细致，导致通过测试的不同模块整合在一起出现各种bug。
4. 关于各类文档，我们选择了交给一个人完成（他只负责写文档），这个决定让团队的进度大大减慢。

另外，关于团队管理者问题。团队中确实要有一到两人对软件整体理解更透彻，来负责任务分配。但对组员的监督，开发过程种种问题的解决更应该是全员的任务。团队中任意两个组员之间的协作和监督无处不在才能使整个开发过程不变得支离破碎，此时队长（组长、领导）的作用反而不在那么重要。

总结，团队分工协作开发不论哪种模型，总是会在软件开发的不同阶段出现或大或小的各种问题，这些问题有的能在早期的分析设计阶段提前避免，有的问题却几乎无法避免，我们只能在每一次的项目中吸取教训作为下一次参与开发的经验。