1.代码是否需要规范:
代码规范是肯定的，就像是USB借口需要一个标准规范，不然我们我们怎么用一个U盘在多个电脑上用。没有规矩不成方圆，代码规范化对于我们检查，改正也是非常有帮助的。而四个论点中我虽然觉得3是对的，但我还是想选2，因为代码是自己的，有一个自己习惯的方式去编写代码就够了，别人看你的代码需要的就是理解你的规范，看懂一个就可以看懂所有，一个人并不一定要学习别人，一个程序员更需要的是一个创造力，就从代码规范的创新开始。
2.代码复审：
张泽凯的四则运算代码相对而言比较简单，并没有增加什么题目要求之外的功能，在代码规范上，程序并没有任何的标注和注释，导致他人难以看懂，需要花费更多的时间去理解，空格的使用也不是很规范，总的来说，代码需要有一个自己的标准，能够让他人看懂或者说是更好去理解程序的细节，方便检查和修正。
3.psp记录个人四则运算项目耗时分析：
| psp | Time（h） | ||
|
Planning |
计划 | 3 | |
|
Estimate |
估计项目需要多少时间 | 3 | |
|
Development |
开发 | 5 | |
|
Analysis |
需求分析 | 1 | |
|
Design Spec |
生成设计文档 | 0.4 | |
|
Design Reveiew |
设计复审（和同事审核设计该文档） | 0.3 | |
|
Coding Standard |
代码规范（为目前开发定制合适的规范） | 0.3 | |
|
Design |
具体设计 | 0.5 | |
|
Coding |
具体代码 | 1 | |
|
Code Review |
代码复审 | 1 | |
|
Test |
测试（自测，修改代码，提交修改） | 0.5 | |
|
Reporting |
报告 | 1 | |
|
Test Report |
测试报告 | 0.3 | |
|
Size Measurement |
计算工作量 | 0.2 | |
|
Postmortem & Process Improvement Plan |
事后总结，并提出过程改进计划 | 0.5 |