1. 是否需要有代码规范
1、这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率, 浪费时间的东西。
也许规范对个人的开发效率会有负面影响。但是放到整个团队层面上，它恰恰是能够节约大家的编程时间的东西。那个版本管理员花费的三、四个小时，本来可以用来测试、用来修正bug，却因为我的代码不规范而被浪费掉了。
2、我是个艺术家，手艺人，我有自己的规范和原则。
一个人的那也叫规范？最多叫个人习惯。足球里有一句话，没有哪个球员比球队更重要。项目组也一样，没有哪个人的个人习惯大过团队规范。
就我那个错误来说，我也有我的规范和原则。事实上，我犯错误的那次所使用的格式化规范，也是我原来所在 项目组的通用规范。但是，在新的项目组里，它变成了我的个人习惯，并且，我的个人习惯导致团队工作受到了严重的影响。如果你是那个新项目组的成员，你能忍我？
3、规范不能强求一律，应该允许很多例外。
规范应该尽量一致；即使有例外，也只能是少数情况，而不能是很多例外。
说到这个例外，我想起另一个例子来。古人取“字”的时候，常常按兄弟次序取“伯仲叔季幼”，例如“季常”、“幼常”。但有一次有个哥们就问我：为什么这个哥哥字“叔x”，而弟弟字“伯y”？是不是史书写错了？
这就是规范中“例外”情况导致的混淆甚至是混乱。
4、我擅长制定编码规范，你们听我的就好了。
我原项目组使用的规范就是我编订的。到新项目组里，它就捅了篓子。
如果对规范有意见，可以通过一定方法修订并发布新的规范。但是在新的规范发布之前，请遵守旧的规范。
2.代码复审
我复审的对象是王硕彭的代码，他的代码完整无误，运行正常。在生成代码的数值上，他取得是100以内的数值范围，比我的数值范围定义要大了许多，考虑到了用户的体验和实用性。
3、PSP
PSP2.1 PSP Stage Time（%）SDE
Planning 计划 6%
Estimate 估计这个任务需要多少时间 6
Development 开发 88%
Analysis 需求分析 12
Design Spec 生成设计文档 4
Design Review 设计复审（和同事审核设计文档） 8
Coding Standard 代码规范（为目前的开发制定合适的规范） 1
Design 具体设计 10
Coding 具体编码 23
Code Review 代码复审 9
Test 测试（自测，修改代码，提交修改） 21
Reporting 报告 6%
Test Report 测试报告 2
Size Measurement 计算工作量 1
Postmortem & Process Improvement Plan 事后总结，并提出过程改进计划 3