一件事情,如果你不能说清楚,十有八九你就作不好
杨军
杨军在 TopLanguage 上也曾分享了三篇非常棒的学习心得的文章,字字珠玑:
[1] 有些事情做起来比想象中容易
[2] 有关读书方法的一点想法
[3] 一件事情如果你没有说清楚,十有八九不能做好
关于他在这三篇文章提到的一些经验,深有感触,时刻提醒,不断学习:
[1]一个问题,如果不实际动手作,仅仅是从外面看,往往会被一些表面上的困难阻塞住,产生不可逾越的感觉,及至真的动手作了,才会发现未必然 .
虽然自己现在在编译器设计实现方面仍存在大量的知识薄弱项需要补充,但这并不意味着自己不可以开始着手作一些实际的工作.总是期待达到一个完美的积累状态再去动手实际作,结果可能就是一直陷入积累的状态不能拔出.
所以说大部分天才都是逼出来的。小马过河的故事很发人深省啊!
[2]此外,我在学习一个知识点的时候,心中始终抱着一个目标,就是最终要能写出一篇很好的survey,这样一来在阅读思考的时候总是有意无意地在整理知识的结构,并且往深处想。我的实践表明这是一个很棒的技巧。
[3]一件事情,如果你不能说清楚,十有八九你就作不好.我一般也喜欢在头脑中将理论说给自己听,容易理清思路和发现漏洞。在路上走着反正也是走着,不如想点问题。
记得有一次开会,我的头儿说了标题所写的这句话,自己深以为然。
有过较多解决问题的经历的人可能会有这样的感觉,很多时候,面对一个问题,我们即使没有完全将之想清楚,也可以基于已有的经验给出一个能够work的解决方案,当然这种情况下给出的方案往往不是最优的。 而即使给出了解决方案,很可能自己都未必能把自己给出的解决方案所基于的推理逻辑,清晰无误地阐述出来. 因为随着人的知识,经验的积累,我们可以越来越多地依靠经验来解决一些问题,这些经验有些是自己身体力行, 实践得来的,有些则是道听途说,经卷纸传,从其他的地方获得的。在获得这些经验的同时,我们的大脑会建立起 这样的一个触发机制:
遇到问题A,经验B会有效。
遇到问题C,经验D会有效。
。。。。
至于为什么经验B对问题A会有效,是不是在所有场景下都会有效,是否还存在更有效的解法,大多数情况下,我们未必会深入去思考挖掘。
于是,在遇到了与自己以前经历过的问题相似,相近的场景时,我们就会条件反射地基于已有经验,设计出一个解决方案,大多数情况下这个方案work得很好。但也有很多情况下,这个方案虽然能work,但并不是最优解,甚至 自己都未必能说得清楚为什么给出这样的方案。
最近在工作中,需要为编译器的语法规则设计相应的数据结构,自己就有了这样的感觉, 在作设计的过程中,有的时候,是旧有经验作祟,有的时候,则是因为偷懒的情绪占了上风,自己会满足于浅尝辄止,对某个问题给出一个未经深思熟虑的解决方案,而随着设计过程的推进,暴露出来的信息越来越多,就会发现已有的设计不能很好地满足一些场景的要求,因而对已有的设计进行调整,但是在调整时,自己往往会发现,对于已经作出的设计,为什么当时自己选择那样的接口,定义那样的数据成员,自己并不能给出清晰明确的解释,这就 说明在作出当时的设计的时候,自己并未将问题想清楚,也未将自己给出的设计想清楚,而是基于一些已有的经验,给出了一个差强人意的方案而已。
在这方面,我的老大作得要比我好很多,对于一个问题,他往往会将之想得非常清楚之后,才会去着手去作。以前的技术讨论会上,凡是他提出的设想和方案,几乎很少会有被我们驳斥倒的,因为只要是他在会议上提出来的东西,几乎方方面面,各种可能,他都已经去思考过了。而在工作过程中经验的积累上,他也经常会作深入的思考和挖掘。一般来说,凡是他解决过的问题,只要不是太detail的,跟他讨论起来,他往往能够对答如流,而能够作到这一点正是因为他在储备这些经验的时候已经作足了功夫。而自己在储备经验的时候则往往不会花费太多精力。一个典型的场景就是我和老大同时遇到一个问题,有的时候,我能更快地给出答案和解法。但是过了一段时间,又遇到了类似的问题,我却可能会忘了当时解决问题的思路,需要重新进行思考,而我的老大往往能够直接从他的经验体系中找出当时的解法思路。遇到一个问题,我往往能较快地给出一个解决方案,但细究起来,我就时有被卡住的场景,而我的老大,虽然给出问题答案需要的时间会较长一些,但一般他给出的答案,往往都经得起推敲。
外人看来,我干起活来很快,效率蛮高,但是自己内心才清楚,这种效率是以损失扎实性为代价的。