编程作为inductive theory formation

例行睡前胡说八道时间。

转专业学编程，如果侥幸找到了工作，可能会面对一大堆工业代码无所适从，不知道谁是谁，不知道什么东西放哪，出了bug不知道上哪找。

编程语言的本质也是语言，语言就是符号的互相定义。学语言，是快速把这门语言的语法交教给你。工作中遇到事先学过的语言或语言的某个部分，可以去学，但总有一些东西以前可能没见过而且暂时没时间学。那么就需要根据语料总结语法。

Debug的本质是在一大堆变量中寻找一个或几个关键变量（及其组合），该变量使得bug发生。

这两件事的本质，都是实证主义的基本方法论：induction。及其具体实现方式：控制实验法。

最常见的应用，debug，有100个变量，你对业务逻辑一窍不通不造哪个变量造成了bug，那就试100次每次改一个，看看bug会不会好。

但这样只适用于一个变量（而非变量集）造成的bug，而且试100次太多了。所以实际工作中还是得用debugger和业务知识，缩小可疑范围。但最终确定bug原因，仍然是靠控制变量。

如果在syntax中见到一个不认识的符号，比如Future（java7的asynchronous monad，不懂可以忽略），又没时间去查这是啥，就从代码库里搜索Future，照猫画虎即可。

任何函数都是一个黑箱，知道input和output就能用，搞清input和output关系可能需要一些控制实验。

不过这些都是应急的辅助办法，直接学习和掌握理论（语法，业务知识）还是必要的。我经常用这些办法，是因为之前工作涉及的业务知识我没有兴趣也不需要学，所以用此法帮我节省时间，做更有意义的事。