随机抽签程序报告

贾玉欣：设计窗体

李   旭：编写代码

            共同完善窗体和编写代码，查看代码结构有没有问题，共同纠正代码和结构的错误。

1．概要部分

（1）代码能符合需求和规格说明么？

       基本符合，但是多人抽签有点欠缺。

（2）代码设计是否有周全的考虑？

        是，代码的输入都是深思熟虑之后的，但肯定有部分欠缺。

（3）代码可读性如何？

        可读性还行，基本上一看就能理解程序的思路和用意。

（4）代码容易维护么？

        还行，架构组织还够完善。

（5）代码的每一行都执行并检查过了吗？

         检查过了，没啥问题。

2．设计规范部分

（1）设计是否遵从已知的设计模式或项目中常用的模式？

        遵从了常用的模式，把空间放在了用户习惯使用的位置上

（2）有没有硬编码或字符串/数字等存在？

        没有硬编码，比较麻烦。

（3）代码有没有依赖于某一平台，是否会影响将来的移植（如Win32到Win64）？

        没有

（4）开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？

        可能会实现部分功能。存在。

（5）有没有无用的代码可以清除？（很多人想保留尽可能多的代码，因为以后可能会用上，这样导致程序文件中有很多注释掉的代码，这些代码都可以删除，因为源代码控制已经保存了原来的老代码。）

        代码中不存在可清楚的无用代码。

3．代码规范部分

（1）修改的部分符合代码标准和风格么（详细条文略）?

        代码编写严格按照代码编写的标准和风格。

4．具体代码部分

（1）有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？

        代码中对错误信息进行了输出。

（2）参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度，是以0开始计数还是以1开始计数？

        字符，1。

（3）边界条件是如何处理的？Switch语句的Default是如何处理的？循环有没有可能出现死循环？

         没有出现死循环。

（4）有没有使用断言（Assert）来保证我们认为不变的条件真的满足？

         没有使用。

（5）对资源的利用，是在哪里申请，在哪里释放的？有没有可能导致资源泄露（内存、文件、各种GUI资源、数据库访问的连接，等等）？有没有可能优化？

         在用到时调用，用完后释放。

（6）数据结构中是否有无用的元素？

         没有

5．效能

（1）代码的效能（Performance）如何？最坏的情况是怎样的？

        最坏的情况就是程序崩溃。

（2）代码中，特别是循环中是否有明显可优化的部分（C++中反复创建类，C#中 string 的操作是否能用StringBuilder 来优化）？

         没有这么做。

（3）对于系统和网络调用是否会超时？如何处理?

         没有出现过， 如果出现关闭重新调用。

6．可读性

代码可读性如何？有没有足够的注释？

      可读性基本可以，注释基本上一看就能理解程序的思路和用意。

7．可测试性

代码是否需要更新或创建新的单元测试？

       不需要