Coding by Coincidence

// 程序为什么会有bug -- 思考的不全面

最近在做UVA的题目的时候，一个问题一直困扰我无数次：WA来的太多了。

写程序的过程是美好的，而且一般很快，一个100行以内的code应该不会超过半个小时就能写完;但debug的过程着实痛苦：拿到WA之后，随便就是几个小时的debug。

 

为什么不能一次做好呢？

因为思考地不够全面，就开始动手写代码了。换句话说，对体系还没有足够清晰的认识和了解。

 

// School of Application / School of Theory

现在的还在不断进步的Programmer可以分成两类吧：实践派和学院派。实践派的，讲究遇到问题，解决问题;讲究的是寻找对于一个问题快速高效的解决方案——所以很多时候解决问题的过程是：google，找到了一个solutoin，(try&error) -> Works? use it: find anotehr.

加入刚好找到了一个合适的解决方案，用了就没问题了;但有些时候，如果你遇到的问题有一点点特殊，那么时间就要花在无尽的Google、try&error的过程中;更加严峻的问题是，假设之后问题出现了一个变体，你就需要重新去搜索一遍（因为经验性的记忆总是不如全面了解来得正确）。

 

另外一种人是讲究读书的。他们只做自己有把握的事情，所以他们对于自己做出来的产品、写出来的code有信心——因为他们知道内部所有的来龙去脉。之后出了问题，他们可以迅速的找到原因。

但是这需要极高的前期知识投入和知识储备。

但这类人每解决一个新的问题，都是对于自己知识储备的一次重新完善。

 

// 《The Pragmatic Programmer》 -- coding by coincidence

在《THe Pragmatic Programmer》里面，有一章讲如何coding，其中一个topic就是“Coding by Coincidence”——在自己不了解内部结构的前提下就开始coding，于是在出现问题的时候，自己也不能判断是哪里的问题——所以你只能一点点试错。

 

时间长了你会发现。两种人在解决同一个问题上花了差不多的时间;但第一种人把时间用在了找东西上面，而第二种人把东西用在了积极思考]学习新内容上面。高下立辨。

 

// 该有的好习惯：提前写好code，列在一张纸上面。

我们时间有限。应该把有限的时间放在有价值的事情上面——积极的思考，而不是消极的找原因。与其花30min写程序，2h debug，为什么不花50min一次就把程序写对呢？

怎么写对？在对于你用的component有了解之后，拿来一张纸，一支笔，写下算法的步骤，写下基本的算法证明。然后实现。即使你的算法证明是错的，你在debug的时候，也是一个“positive thinking”的过程——时间久了你自然会进步的。

 

人家讲，Knuth在最初写Latex的时候，是先写在了一个本子上的;后来把代码输入进计算机，直接就能运行的。