软工实践寒假作业（2/2）
| 这是这个作业的基本信息 | |
|---|---|
| 这个作业属于哪个课程 | 2021春软件工程实践S班 |
| 这个作业要求在哪里 | 软工实践寒假作业(2/2) |
| 这个作业的目标 | 学习更多技能、提高自身水平，为下学期的软工实践，为今后的学习和工作做好准备 |
| 其他参考文献 | ... |
PART1:阅读《构建之法》并提问
Q1
典型的软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情也很重要，我们叫他们项目经理——PM。
PM的M就是Manager，但是P有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同。《构建之法》第9章 项目经理
- 在很久之前第一次得知项目经理这个存在的时候，我就有一个疑问：“项目经理，是不是可以划水啊？”当然之后我很快就知道项目经理也是很忙的，要和客户交流沟通，要协调团队关系，要跟进项目进度，要带领团队进步。划水的疑问解决了，另一个疑问又来了：项目经理这个职位对编程能力的要求高吗？
- 在邹欣老师的《构建之法》中提到，PM负责做开发和测试之外的所有事情，如果这么看，软件开发和测试都有人做了，PM要做的也似乎与编程没有什么关系，那对PM编程能力的要求是不是并不高？在《构建之法》中有这么一段：
其次，PM的产品是规格说明书（Spec），PM要凭自己的能力，把用户的需求展现成其他成员能够理解和执行的语言，从而赢得同伴的信任和尊敬。如果PM同时又是其他人的老板，则不必写太好的Spec，用命令即可说服别人。再次，PM不一定是很好的行政经理（管人的），硬把管理不同专业人员的任务加到PM头上，反而会坏事。《构建之法》第9章 项目经理
- 在这一段里面有提到PM要凭自己的能力赢得同伴的信任和尊敬，这里的能力除了指PM谈客户、选项目、定方向、带团队的能力之外，是否还有PM自身的编程能力，如果PM的编程能力弱，怎么知道项目功能能不能实现呢？
- 还有就是这一段关于舵手和小船的故事：
如果这个舵手也开始划船，后果会怎么样？可能小船的速率会快一些，但是小船的方向、稳定性会出问题。船是划快了一些，但是划桨的众多队友不能协调一致，船也不稳，而且最后到了一个计划外的地方，你愿意么？《构建之法》第9章 项目经理
- 我明白这段是说团队应该各司其职，PM不要介入开发和测试中，但是这样的话对PM的编程能力的要求又是多少呢？或者说PM要能理解多少代码呢？
Q2
王屋村的居民大志要把一堆砖头从村头搬到村尾。他来到顶球酒吧前，看到前面三三两两地蹲着一些人，有些人面前放着一块包装箱纸板，上面写着“Java，五毛一行”；“网页前端，不酷不要钱”；“专做PS，擅长人体”；“通吃SQL、NOSQL”，等等。《构建之法》第5章 团队和流程
- 刚开始看到这一段，我想的是这些人各有所长，为什么不能组成团队呢？然后我看到书里已经给出了解释：
1.团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作，例如接力赛跑。王屋村搬砖的“非团队”成员则不然，每个人想搬多少就搬多少，不想干了就结算工钱走人。
2.团队成员有各自的分工，互相依赖合作，共同完成任务。王屋村搬砖的“非团队”成员则是各自行动，独立把任务完成，有人不辞而别，对其他的搬砖人无实质影响。《构建之法》第5章 团队和流程
- 为什么不能组成团队的疑问得到解答了，我的理解是王屋村的搬砖人只是零散的个体，没有团聚在一起的动力。假使突然来了一个人，他对这些搬砖人说，我们组个团，赚更多，且假使这些搬砖人心动了，他们成为了一个团队，应该怎么选择一个合适的团队模式呢？《构建之法》中的团队模式各不相同，对于如何选择我也是一头雾水。
PART2：WordCount编程
Github项目地址
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| Estimate | 估计这个任务需要多少时间 | 2.5day | 3day |
| Development | 开发 | ||
| Analysis | 需求分析 (包括学习新技术) | 30 | 50 |
| Design Spec | 生成设计文档 | 20 | 15 |
| Design Review | 设计复审 | 10 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 15 | 12 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 240 | 360 |
| Code Review | 代码复审 | 90 | 60 |
| Test | 测试（自我测试，修改代码，提交修改） | 60 | 60 |
| Reporting | 报告 | ||
| Test Repor | 测试报告 | 60 | 60 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 30 |
| 合计 | 595 | 707 |
解题思路描述
-
看到作业要求的时候确实是很头大的，密密麻麻一长条，尤其是没有接触过的git和github，我感觉很晕。对此，我选择的完成作业的方法是先写代码！写了再说，至于提交什么的，等我写完代码再说吧！于是我开始写代码了。
-
我主要是从需求出发，基本需求就几个：一，统计字符数；二，统计单词数；三，统计行数；四，统计词频。在这几个需求里，我把一和三结合到一起，并编写了函数charAndEntercount
（用enter绝不是忘记行数的英文line了，嗯）。因为换行符就是'\n'，所以我选择在计算字符的时候同时对行数进行计数，但是显然有个问题，就是空白行，应该怎么排除呢，我的方法是设立一个变量isnewEnter，这个变量在遇到换行符后会置1，表示进入了下一行，而只有在遇到非空白字符时，这个变量才会置0，同时行数会+1。 -
解决好了需求一和三，我又把目光转到需求二和四，这两个需求的共同点是都涉及到对单词有效性的判断，在作业要求中有提到对单词有效性的要求，1.至少四个字符；2.前四个字符必须为英文字符。我的想法是用getline函数依次取出文件里的每一行，再把该行字符逐个取出，一般来说遇到空格符就判定结束上一个单词的录入，但是我觉得这样的话会白干活，比如我遇到123hbg，显然这个并不是有效单词，从第一位数字开始它就是无效的，这也就是说这个单词是没必要记录的，于是我设置了一个变量isefct，用于判断单词是否有效，它的用法我会贴在设计与实现过程里。而词频统计和排序这部分，我想到了C#里学到的索引器，但是我不太想自己写一个，所以搜寻过后，我决定词频统计用map，而排序则用vector的sort。
代码规范制定链接
设计与实现过程
类WordCount
class WordCount
{
private:
int w_char; //characters' count
int w_word; //words' count
int w_line; //enter count
map<string,int> wordmap;
public:
WordCount(){
w_char=0;
w_word=0;
w_line=0;
}
//function
void charAndEntercount(string pathstr); //count characters
void wCount(string pathstr); //count words and enter
void writeTxt(string outstr);
};
变量isnewEnter
if(temp=='\n')
{
isnewEnter=1;
}
else
{
if((temp=='\f'||temp=='\r'||temp=='\t'||temp=='\v'||temp=='\b'||temp==' ')&&isnewEnter==1);
else
{
ec+=isnewEnter;
isnewEnter=0;
}
}
变量isefct
if(isefct)
{
if( isdigit(ch)!=0 && wordlength<4 )
{
isefct=false; //if digit show in the first 4 char,the word is not effective
wordlength=0;
word="";
}
else
{
word+=tolower(ch);
wordlength++;
}
}
词频统计
//if the word is effective,store it into wdmap
if( isefct && wordlength>=4 )
{
wcot++;
map<string,int>::iterator iter=(*wdmap).find(word);
if( iter!=(*wdmap).end())
{
(*wdmap)[word]++;
wcot--;
}
else
{
(*wdmap).insert(pair<string, int>(word, 1));
}
}
测试
心路历程与收获
心路历程其实在解题思路描述中有提到一些，就是刚开始看到一大串作业要求头有点大，但是当确定好先打代码的方向后，一点点琢磨作业需求的过程中，既有被error折磨的痛苦，也有编译通过的快乐。但是快乐归快乐我又一次感受到自己知识量的不足。
收获就是不懂的不会的一定要动手去找，天上不会掉馅饼，脑子里也不会自己涨知识，认识源于实践，不动手是会一无所获的。
以及PSP表格我估不准....因为我是边想边写的，这样不好，如果设计好整个流程，思路清晰，结果会更好。下次一定。
