拿到《code complete》，哇，这么厚一本，看到哪年去。。然后就有这个作业了，正愁不知道怎么下手啃完，课间老师跟我们说针对性的看。所以，并没有吃透这本书，只是在目前的认知水平上，选取了帮助比较大的部分细读。主要的收获如下：
1.高质量的子程序
在过去的学习中，我认识到子程序的若干好处，比如说可以减少代码冗余，减少修改代价。但是我一直是按照自己的感觉，在编程时临时根据具体需要写觉得这里这里写个子程序比较好，并不知道子程序应该满足怎么样规范才能高效，可读性强。学习这本书的第7章，我收获很大。比如，子程序起名的规范可以很好的提高可读性，参数排列，还有在什么情况下用什么种类的子程序。回想我的编程经历，对照书上附的高质量子程序核对表，就感觉到我所写的子程序常常导致程序逻辑很混乱，功能上没有很好的内聚性，这方面一定要有意识的改进。
但是，我有个疑问，子程序应该是在编码之前框架搭建的时候就设计好，还是编码的过程中遇到代码冗余或者功能重复利用的情况下再写？我是后者，但是感觉那样很被动，而且常常要把之前的很多代码进行修改。
2.变量名的力量
对变量命名，我们都知道不能用x，y，而应该使用有意义的词组，但是这个规范也略显粗糙，个人说话习惯不同，也会影响起名的风格，导致变量名同样不好理解。我命名变量也是跟着感觉走，但是每每都很长，书上对这一部分的规范很有必要。比如，命名应该以问题为导向，关注“what”，而不是“how”，eg.一条员工数据可以是inputRec或者emloyeeData，前者是how，反映计算概念的计算机术语，而后者直指问题领域。因此，后者更佳。我常常犯这样的问题，用动宾组合来命名变量，学习之后，才知道动宾适合对子程序命名，反映其功能。而且这本书对各个类型的变量命名规范给了详细的介绍，在这里就不赘述了，总之很有用。
3.结对编程
回想我的结对编程过程，我认为没有完全满足书上的准则，比如说“有规律地对结对人员和分配的工作任务进行轮换”，我们是一个人整体搭结构，一个人写某几个功能的方法，正是因为这样，两个人没有对对方的工作有很好的把握，因而在遇到问题时，讨论起来很费劲，必须得给对方解释我这部分工作是什么。如果我们当时有轮换角色，那么不管是哪里出问题了都是两个人在想，效率肯定更高。但是如果这样的话，结对编程关注的并不是分工而是合作，是吗？
4.调试
调试很重要啊，当时写pair work，写了只有一天，但是调试了两天。书中介绍的调试方法很详尽，我属于迷信式调试，总不觉得是自己的问题猜测各种编译器的bug......我觉得这不叫迷信，这叫逃避式调试。书中说的一句话很对，调试是理解代码的好方法，当时做电梯调度的时候，我是逐个类逐个方法的看，总是看不明白，后来自己勉强开始写了，编写边调试才理解这个工程，所以，调试不仅仅是修改缺陷，也是在运行中理解各个代码部分的功能和调用关系。
综合上述疑问：1.子程序应该是在编码之前框架搭建的时候就设计好，还是编码的过程中遇到代码冗余或者功能重复利用的情况下再写？
2.结对编程关注的是合作，而不是分工，是吗？