第四周小组作业：Wordcount优化

1.小组github地址

https://github.com/muzhailong/wcPro

2.PSP表格

PSP2.1	PSP阶段	预计耗时（分钟）	实际耗时（分钟）
Planning	计划	30	30
· Estimate	· 估计这个任务需要多少时间	30	30
Development	开发	500	550
· Analysis	· 需求分析 (包括学习新技术)	20	30
· Design Spec	· 生成设计文档	30	30
· Design Review	· 设计复审 (和同事审核设计文档)	20	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	30	30
· Design	· 具体设计	40	50
· Coding	· 具体编码	210	240
· Code Review	· 代码复审	40	40
· Test	· 测试（自我测试，修改代码，提交修改）	110	110
Reporting	报告	90	100
· Test Report	· 测试报告	30	40
· Size Measurement	· 计算工作量	30	30
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	30	30
	合计	620	680

3.描述代码设计思路

我们小组讲这个工程分成类7大模块：

param：参数解析模块

in ：输入模块

core ：核心处理模块

out ：输出模块

ui ：图形界面模块

util ：工具类模块

start：模块集成模块

我主要负责的是param参数解析模块，各个模块如下图所示：

param模块：

　　参数解析模块，向com.ui，com.in提供输入接口

主要代码：

    /**
     * 参数解析
     *
     * @return 参数解析信息
     */
    public Options decode() {
        int len = args.length;
        Options op = new Options();
        if (len > 1 || len <= 0) {// error
            op.isErr = true;
            return op;
        }
        String s = args[0].trim();
        if (s.equals("-x")) {
            // 图形界面
            op.isX = true;
        } else if (s.endsWith(".txt")) {
            if (!new File(s).exists()) {
                op.isErr = true;
                op.setInfo("文件不存在！");
            } else {
                op.isConsole = true;
                op.setFn(s);
            }
        } else {
            // error
            op.isErr = true;
            op.setInfo("参数异常！");
        }
        return op;
    }

4.测试设计过程

本次的测试设计，主要是为了保证测试用例能够覆盖源程序中所有的可执行语句，测试用例的设计主要分模块内测试和模块间测试（集成测试）可以点击查看。

5.开发规范说明

开发规范采用的是《阿里巴巴Java开发手册终极版v1.3.0.pdf》

　　选定的开发规范以及理解(我用以下的规范检查我的代码)：

常量定义

　　　　1. 【强制】不允许任何魔法值（即未经定义的常量）直接出现在代码中。

　　　　　　理解：就是说常量不能使用变量拼接而成的。

　　　　　　　　反例：int c；static int A=c；

　　　　2. 【强制】long 或者 Long 初始赋值时，使用大写的 L，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。

　　　　　　理解：很简单不解释

　　　　　　举例：long k=123L;

　　　　3. 【推荐】不要使用一个常量类维护所有常量，按常量功能进行归类，分开维护。说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。

　　　　　　理解：有时候我们会专门写一个类来维持常量，这样是不好的因为将所有的常量放在一起就像一个大杂烩一样。应该根据功能进行放置，比如说和单词容量有关的常量可以放在单词的工厂类中。

　　代码格式

　　　　1. 【强制】大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：

　　　　　　1）左大括号前不换行。

　　　　　　 2）左大括号后换行。

　　　　　　 3）右大括号前换行。

　　　　　　4）右大括号后还有 else 等代码则不换行；表示终止的右大括号后必须换行。

　　　　　　理解：就是字面意思，不用解释。

　　　　　　举例：while(i){

　　　　　　　　　　......

　　　　　　　　　}

　　　　2. 【强制】左小括号和字符之间不出现空格；同样，右小括号和字符之间也不出现空格。

　　　　　　举例：void king();

　　　　3. 【强制】if/for/while/switch/do 等保留字与括号之间都必须加空格。

　　　　　　说明：格式上看的清晰一点。

　　　　　　反例：if(t<0){

　　　　　　　　　　.......

　　　　　　　　　}

　　　　4. 【强制】任何二目、三目运算符的左右两边都需要加一个空格。

　　　　　　举例：k = i + j;

　　　　5. 【强制】采用 4 个空格缩进，禁止使用 tab 字符。

　　　　　　说明：很多IDE都可以讲tab设置为4个空格。

　　　　6. 【强制】注释的双斜线与注释内容之间有且仅有一个空格。

　　　　　　举例：// fjei

　　　　7. 【强制】方法参数在定义和传入时，多个参数逗号后边必须加空格。

　　　　　　举例：void f(int a, int b, int c)

OOP 规约

　　　　1. 【强制】避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可。

　　　　　　理解：静态方法属于类，和类是绑定的，通过对象还要先找到类，在从类找到方法。

　　　　　　举例：

　　　　　　　　public class Test{

　　　　　　　　　　public static int a；

　　　　　　　　}

　　　　　　　　使用Test.a即可。不需在定义一个引用。

　　　　2. 【强制】所有的覆写方法，必须加@Override 注解。

　　　　　　理解：Override注解貌似是编译时检查，如果重载出现问题编译时不会通过的。

　　　　　　举例：

　　　　　　　　public class Animal{

　　　　　　　　　　public void voice（）{}

　　　　　　　　}

　　　　　　　　public class Duck extends Animal{

　　　　　　　　　　@Override

　　　　　　　　　　public void voice（）{}

　　　　　　　　}

　　　　3. 【强制】不能使用过时的类或方法。

　　　　　　理解：一般来说过时的方法都会有风险，或者效率问题。

　　　　　　举例：acm中最喜欢用的StreamTokenizer

　　　　4. 【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。

　　　　　　理解：讲逻辑放在构造方法中会造成构造对象浪费大量的时间，有些对象构造了但不一定会使用。

　　　　　　举例：略。

　　　　5. 【推荐】循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展。

　　　　　　理解：+相当于使用多个StringBuilder对象，效率很低下。

　　　　　　举例：String a="asd";

　　　　　　　　　a=a+"few"+"few";

　　　　　　正例：StringBuilder a=new StringBuilder（）；

　　　　　　　　　a.append("fewf");

　　　　　　　　　a.append("dsfew");　

　　　　6. 【推荐】类成员与方法访问控制从严：

　　　　　　 1）如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。

　　　　　　 2）工具类不允许有 public 或 default 构造方法。

　　　　　　 3）类非 static 成员变量并且与子类共享，必须是 protected。

　　　　　　4）类非 static 成员变量并且仅在本类使用，必须是 private。

　　　　　　 5）类 static 成员变量如果仅在本类使用，必须是 private。

　　　　　　 6）若是 static 成员变量，必须考虑是否为 final。

　　　　　　 7）类成员方法只供类内部调用，必须是 private。

　　　　　　 8）类成员方法只对继承类公开，那么限制为 protected。

　　　　理解：这个符合最小访问原则。

　　　　1. 【推荐】集合初始化时，指定集合初始值大小。

　　　　　　理解：ArrayList默认大小是10 Map的默认大小是16，他们一般都会在容量达到75%的时候进行扩容处理，所以如果初始时候知道了容量可以避免扩容的开销，提升效率。

　　　　　　举例：

　　　　　　　　List<String> a = new ArrayList<String>(100);

　　　　2. 【推荐】使用 entrySet 遍历 Map 类集合 KV，而不是 keySet 方式进行遍历。

　　　　　　理解：看过Map源码就知道，HashMap在内部维持了一个Entry的数组，使用entrySet遍历其实就是遍历数组，如果使用keySet就行遍历，是讲所有的key打包成一个set然后再通过遍历key从map中获取相应的value，效率低下。

　　　　　　举例：

　　　　　　for（Map.Entry<String,Integer>e : map.entrySet()）{

　　　　　　　　　.....

　　　　　　}

6.静态代码扫描

使用的是阿里巴巴的p3c 我使用的是eclipse在线安装地址 https://p3c.alibaba.com/plugin/eclipse/update

警告：5

错误：0

运行截图：

问题分析：抽象类应该使用AbstractCounter命名。

问题：Collection是原生类型，应该使用泛型。

7.组内代码分析

我们小组的代码整体上质量比较高。原因如下：

　　　　1.整个项目划分成7大模块，模块之间耦合性很低，各个模块之间可以并行开发，开发效率比较高。

　　　　2.项目代码采用阿里巴巴的java开发规范，各个方面方面遵循一定的规范。

　　　　3.真个小组使用p3c进行静态检查，0警告，0错误。

　　　　4.小组内人员齐心合力，认认真真，仔仔细细修改每一个地方。

　　　　5.小组内遇到逻辑上的问题互相讨论，达到最优方案。

8.测试数据集

　　设计思路：非常简单，我们在开发的时候已经考虑到测试了，因此预留下了一个util模块，其中util模块中有一个方法可以生成一个文件。

　　　　　　　生成随机文件的思路很简单，通过随机数然后将指定字符写入文件即可。后面的测试只需要执行randomFile方法就可以生成一个指定大小的文件测试起来很方便。

package com.util;

import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.io.IOException;
import java.util.Random;

public class Utils {

    private Utils() {
    }

    private static Random random = new Random();
    private static String str = "abcddefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ~`!"
            + "#%^&*_…()[]+=-:'\"|<>,./? \n\t\r0123456789";

    public static void randomFile(String fn, int sz) {//sz 单位字节
        File f = new File(fn);
        StringBuilder sb = new StringBuilder(sz * 2 / 3);
        BufferedWriter writer = null;
        try {
            writer = new BufferedWriter(new FileWriter(f));
            char c = 0;
            int len = str.length();
            for (int i = 0; i < sz; ++i) {
                c = str.charAt(random.nextInt(len));
                sb.append(c);
            }
            writer.write(sb.toString());
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            try {
                writer.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
    public static void main(String[] args) {
        String fn="1.txt";
        int sz=1024*1024*40;//40M
        randomFile(fn,sz);
    }
}

9.同行评审过程描述

角色划分：

　　　　作者、讲解员：母翟龙（17056）

　　　　记录：王玉泽（17042）

　　　　评审：吴静哲（17051）

　　　　主持人：邓国福（17063）

　　目的：针对可能影响或制约程序性能指标的主要因素加以讨论

　　分析：程序的主要开销集中在文件操作上，提取单词的算法，排序的算法等。

　　结论：

　　　　影响程序性能的主要因素有：

　　　　　　1.读取文件的开销。

　　　　　　2.从文件中获取单词的算法

　　　　　　3.单词的保存以及查找算法

　　　　　　4.排序算法（如果使用排序的话）

　　　　　　5.写入文件的开销

　　　　　　6.文件本身的内容（随机因素不考虑）

10.性能分析

实际测试的结果是我们在文件的处理方面已经做得足够好了，对性能造成影响的地方发现是缓冲区的大小设置，还有排序算法的影响。其中排序算法造成很大影响。

11.性能优化

设计思路：打算先从缓冲区的大小设置开始找到最优值，然后改进排序算法，使用更好的快排或者堆排序。

　　优化之后基本上3-4s可以跑完40M的文本。

12.作业总结

这次作业中测试占比很大，可以感觉到是一门测试课程而不是一门面向对象编程课程了。

13.小组贡献率

　　17056：0.46

　　17051：0.18

　　17042：0.17

　　17063：0.19