这几年的个人经验小结

51testing

对过去的总结：
经过几年断断续续的开发，做出了一个功能简单的系统，它可以运行，在低负荷下可用，但是也有问题：
1.精密编码的习惯使得进度十分缓慢，但是仍然没有避免编译错误、运行时异常、出错和艰难的调试。虽然无法回头验证如果放弃精密编码的习惯是否会使得这些困难更加严重，但是可以得出这样的结论：
1.1.精密编码并不能使自己在拥有全局把握的同时对全部细节也拥有完整精细的认识，因为：首先，精密编码是无法在整个开发过程中连续无误的实施的，而且一旦中断往往会产生严重的心理负担；其次，同时在宏观和微观两个层面都有良好的把握在理论上也是不可能的，同时在设计良好的情况下这也是不必要的；最后，人脑的长处在于创造而不是精确，而电脑的长处则正好相反，电脑擅长精确但缺乏创造，因此开发人员的主要任务在于创造，而其他的精确性的保障应该由电脑来提供，所以应该充分相信编辑器在排版方面和编译器在语法检验方面的保障，应积极使用程序来检验代码并信赖这些程序。
1.2.虽然在错误发生之前就找出错误是很好的事情，但是对于编程来说，编译时提示出错和运行测试时发现出错相对于在编码时人工发现错误其实都并不晚，但是人脑的负担能够因此大为减轻，间接地保障之后编码的质量。理论上，在编译和测试之前，由人工精细地检查每一行代码的确可能发现在编译和测试时无法发现的问题，但是在这几年的实践之中这种情况发生得非常少，相比之下为此的付出是极大的，并且这会间接得降低之后编码的质量，所以总体上这种事必躬亲式的人工的精细检查不仅不能提高代码质量而且实际上降低了代码的质量和生产效率，在这种负面效应发生时却又会误以为是人工检查做得不够好于是把更多的精力投入到这种收益不太可能增长的工作上，于是在没有获得更多好处的同时进一步降低了代码的质量和生产效率，至此开始形成恶性循环，最终导致编码工作的停滞。实践经验得出如下结论：人工检查是一项高投入低产出的工作，而且往往产出为0，因此人工检查应只在必要的时候（或者是不得不的时候）才进行，不应成为常态，日常检查应该交给程序来做。
精密编码：指在编码时由人来尽力确保代码在排版、编码等方面的正确性、精确性，尽量在编码时就把可能的问题找出或杜绝，总是以写出越好越好的代码为第一要务，由人而不是电脑来承担编码方面的主要的质量确保责任。
规则一：充分利用电脑为主要工具，把人脑解放出来做电脑做不了的事。
2.设计时总是在发现一个可能的或潜在的需求时就沿着它深入下去并不断发现更多可能的或潜在的需求，当意识到这一点时大脑的思考重点早已从初始的需求转移到距离它很远的其他需求上了。初始需求往往是很迫切的现实需求，一般都是应该尽快满足的需求，但由它所引出的“可能的”或“潜在的”需求则经常不能从初始需求那里继承迫切性。所以思考的重点从初始需求转移到派生需求的过程实际上是把宝贵的大脑资源从重要的事情上转移到了次要的事情上的过程，是一个在幻想之中逐渐脱离实际的过程。尽量把能想到的每一件事都想清楚，这在理论上是很好的，但实际上由于人脑资源的有限，总有一些事会没法想清楚，这样必须在各个等待思考的问题之中先把最重要、最迫切的问题想清楚，与此同时，对于那些从现实需求所引出的引申需求则暂时只做记录而不做详细思考，必须克制住这种发现一个问题就立刻转向详细思考它的冲动，这种冲动会使得最重要、最迫切的需求永远得不到足够的资源来思考。如果初始的现实需求得不到满足，那么由它所引出的其他需求也往往会失去意义。
现实需求：由现实直接引出的需求。
引申需求：由现实需求所引出的、推测出的需求。
规则二：在不丢弃任何想法的同时，确保把有限的大脑资源用在最重要的问题上。
3.有时发现实现不了预定的目标，在沮丧之中往往会就此放弃。但事后想起来，其实即使把标准降低一点，也总比什么都做不成要强多了，但在还来得及选择的时候往往因为懊恼和沮丧的情绪而无法认识到这一点。
规则三：不要因为得不到最优解而放弃次优解。
4.宿舍的电脑桌设计的不好，鼠标只能放在比键盘高不少的地方，于是这几年的结果就是右边的肩膀长时间的疼痛和不适。
规则四：把键盘和鼠标放在同样的高度，或者尽量只用键盘。