软工个人作业 – 分析与提问

软件工程不能只有干巴巴的原则，“人”才是工程的最重要因素。

​ —— 读《构建之法》有感

问题 1：

阿超：在写技术模块的规格说明书 ( Specification ) 的时候 , 要越详细越好 , 最好各项要求都可以表示为一个单元测试用例 。

小飞：如果不能表示为一个单元测试用例呢 ?

阿超：那就是你写得还不够细。

按照书中的说法，单元测试用例似乎是需要在进行具体编码之前就要完成，如果是这样的话，那么基本上可以推断，单元测试是“功能”粒度的。但是在实际编程的过程中，程序员会将功能以一种“不确定“的方式进行细分，比如说对于输出 Hello, world 的功能

实现一

#include<iostream>
using namespace std;
int main()
{
  cout<<"Hello,World!"<<endl;
  return 0;
}

实现二

#include<iostream>
using namespace std;
void print1()
{
	cout << "Hello," << end;
}

void print2()
{
	cout << "World!" << endl;
}

int main()
{
  print1();
  print2();
  return 0;
}

在实现一中一个主函数就可以完成的事情，在实现二中变成了独立的两个函数。按照原文的意思，我们需要针对 “hello, world!” 的输出编写一个单元测试样例，那么如果在具体编码的时候，程序员采用实现二去实现代码，那么其实“单元测试”并不是“单元”的，它并没有测试每一个函数的功能。但是如果在编码前就“未卜先知”的编写了这两个函数的功能样例，这无疑又限制死了 Hello, world! 程序的其他版本的实现，换句话说，单元测试的书写限制了代码的可能性。

针对这个问题，我个人的理解是不应当让“单元测试”成为编程中的“金科玉律”，它应当像画家起稿时用的辅助线，随着作品的进行不断调整，而不是让编程的过程了无生趣，成为了为了迎合“单元测试”而不得不进行的“苦力活”。

在 Rails 中，单元测试是可以根据所书写的方法自动生成的，我们只需要调整单元测试的用例即可，单元测试是“伴随”编程过程进行的，而不是“先写测试，后编程”这种泾渭分明的方式。

问题 2：

当一个小孩说长大了要做音乐家，你会让他走上单人乐队的道路么 ？

这是出现在书上的一个反问句，在这句话中表达了作者对于“单人乐队”的不赞同观点，引申出作者对于某种“全面人才”的批判，相反的，据我了解，作者可能更加赞同的是“作曲家”式的“全面人才”：

一个作曲家在写一首交响乐的时候，他可以写各个乐器的乐谱，充分发挥不同乐器的特点。

确实，似乎单人乐队与作曲家相比，显得并不是那么的专业，这突然让我想起了马哲课上对于“异化”的定义：

在异化活动中，人的能动性丧失了，遭到异己的物质力量或精神力量的奴役，从而使人的个性不能全面发展，只能片面发展，甚至畸形发展。

社会分工固化是异化的根本根源。

然后我就查询了一些更加近代的观点，比如近代哲学家卢卡奇的观点

这是科技所带来的巨大力量让人们产生了一种难以遏制的自负，而人类的自负又加剧了科技的自负。

人类已经被一种虚幻地、自满自足地考虑实践构造的科学遗弃了；这种科学所从属并为之服务的实践，就好像某种在科学界限之外的东西一样；这种科学满足于思想与行动的分离。

我个人的思考是这样的：

首先我的小孩将来如果要做音乐家，他如果希望去当一个单人音队的演奏家，我是可以接受的。不可否认，“音乐家”是一个需要社会认可的，高难度的，殿堂级的称谓，确实与“单人乐队”啥都要掺和一下的特性不符。但是同时，我个人认为“音乐家”的落脚点是“音乐”而不是“家”，相比于“家”所代表的专业性，我更看重“音乐”所代表的快乐和自然。我小时候常去南美洲多个国家玩耍，单人乐队的形式在桑巴中十分常见，我不认为我的小孩去做一个给美丽热情的巴西姑娘跳桑巴的时候配乐的人，有什么不合适的。

但是同时，我也认为，在软件工程中，确实是需要“分工”的，就好像我即使既会前端又会后端，但是对于大的项目，我也不可能一手操办，那么就不是工程了，“一个人干的不是工程”。

但是确实分工会影响人的“全面发展”，就好像大多同学，如果在数据库大作业中作为后端，那么在软工中，也会主动或被动的担任后端，可以想见，如果写简历，那么工作经历也会只有后端，那么应聘到的工作大概率也只能是后端，这显然是十分悲哀的。

但是这否是一种异化呢？还是一种简单的分工呢？

问题 3：

驾驶员：写设计文档, 进行编码和单元测试等 XP 开发流程 。

领航员：审阅驾驶员的文档; 监督驾驶员对编码等开发流程的执行; 考虑单元测试的覆盖率 ; 思考是否需要和如何重构; 帮助驾驶员解决具体的技术问题。领航员也可以设计 TDD 中的测试用例 。

对于结对编程中的分工，可以看到分工是十分复杂的。我觉得这是一个自然的现象，因为合作就意味着沟通，而沟通就需要代价，就好像 P89 页以跳舞举例，一开始一定是互相踩脚的，那么这个时候文档应该是会变多的，因为文档是一个良好的沟通手段。

但是 XP 又是极限编程的意思，它属于是敏捷编程，它的定义也可以找到

敏捷方法论有一个共同的特点，那就是都将矛头指向了“文档”，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量，不但不能够有效体现灵活性，反而显得是不解决问题的方法论似的。因此，就有了一次划时代的会议，创建了敏捷联盟。

这么看似乎需要花费大量时间的文档会在结对编程中得到弱化。那么文档量应该会减少。这应该是因为结对的两个人心意相通，所以省去了一些常见的沟通步骤，文档量也就减少了。

那么是不是可以这么理解，结对编程就好像长期投资一样，需要先投入一定的资金（早期大量的文档），然后才能有利润，并且利润越来越大（文档越来越少）？

问题 4：

TSP 原则：

1. ……
2. 团队的各个成员对团队的目标 、 角色 、 产品都有统一的理解 。
3. ……

我在数据库大作业的实践中，发现让团队成员有一个统一的理解是十分困难的事情，因为大家从小的教育和生长环境并不相同，所以很难对于一个事务有统一的理解（甚至连基础的理解都做不到）。比如说团队一开始希望做一个电影推荐网站，但是团队中有人连基础的“院线”的概念都不知道，那显然是无法为项目的设计贡献自己的一份力量的。

我认为“统一的理解”是一个很重要的事情，因为可以明显感受到，如果团队对于一个项目是有“想法”的，是有“见解”的，那么开发的热情和效率会大很多，但是这并不是一个容易的事情，我自己总结了如下方法：

• 选择大家更有共同话题的选题，比如说学校平台、笔记软件等。
• 选择更有可能有共同话题的同学组成团队。
• 利用自身的人格感染力和频繁平等的会议，让大家的理解统一起来。
• 将任务细化到不需要统一的理解为止。

虽然衍生了一些的方法，但是我觉得依然是缺少科学的、可复现的、高效的且正面的“让团队每个成员对团队的目标、角色、产品都有统一的理解”的方式，希望能在软工中有所学习。

问题 5：

第一步：构造总体模型( Develop an Overall Model )
进入条件：团队已经选好了问题领域专家、主程序员、架构师。

在构造设计文档的时候，需要一个被称为“架构师”的角色，在我看来，他的角色和项目经理产生了一定的重叠

​ 架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作，具备管理职能。一般小型项目中，常见项目经理兼架构师。

可以看到，两者并不是相同的。

从我的个人实践来看，如果让项目经理兼任架构师，那么项目经理就需要花费大量的经理去了解每一项可能需要用到的技术。这对于项目经理来说是一个很重的负荷。

但是又说回来，“了解整个工程架构和需要用到的技术”，本身就是一个很困难的事情，除非是有过很好的积累的天赋型选手，对于软工初体验的我们来说，应当如何培养出一个架构师？架构师需要掌握哪些技术，与专业的技术员或者领域专家相比，他要多了解什么？少了解什么？我是有一些疑虑的。