论学习边界感的建立

想谈谈在求学过程中一直拖累我的问题，这个问题最近在工作中也出现了。那就是由于无法确定学习的边界，导致从最初解决问题的出发点开始越学越广，最后变成为学习而学习，如同深陷泥淖之中。最终的结果是耗时长而收益小，自信心与兴趣也被消磨殆尽。

最近工作中遇到一个小任务，是开发一个能够统计Excel表格数据的程序。我做了一番调查后决定采用.NET平台的C#语言来开发一个桌面程序，供同事使用。尽管我没基础过C#，但是我有C++和python的基础，于是信心满满的开始了我的开发之路。

出发的时候路面总是平坦的，类似数据结构、表达式、函数、类等基本内容，学习起来没有困难；但从开始接触WPF这个概念开始，我就开始误入歧途了。

WPF是程序界面开发的核心部分，而我对此毫无了解。我先在文库和msdn上查阅文档，尝试理解这个概念，发现有人推荐《深入浅出WPF》这本书，于是买了这本书开始深入学习；学XAML语法（前面这本书里的一部分内容）时，又提到它衍生自XML，“理解XML会有助于理解XAML”，秉持着这个想法，我又去泛读了XML；后面又学到数据绑定，感觉不好理解，觉得是自己对C#中类的理解不深造成，又去查了《c#高级教程》；又学到了依赖属性，里面提到了.NET平台的技术细节；而在事件和命令两节，又提到了进程与线程等操作系统的概念....

大致就从这里我意识到了异样：毕竟我总不能从头到尾学一下操作系统。我从三月初开始着手做这件事情，到现在已经五月末了。我发现其中真正着手开发程序的时候很少，3/4的时间都用在了学习上。

而恰恰这部分学习的内容，无法直接支撑我开发的实际工作，它们唯一的作用只是让我更深入理解WPF的概念而已。意识到这一点后，我重拾起最初的《C#入门经典》，仅仅跟着做了书中的两个WPF示例，就找到如何解决我自己的问题的方法了。此时我回顾整个历程，才恍然大悟自己误之深矣。

我犯了两个错误。第一个，我忘记了我的初衷。我的目的在于开发程序，而不是学习。学习会让人上瘾，比如说对一个概念恍然大悟的时候，就会忍不住去理解下一个概念。这个过程会让目的与学习过程脱节。想法由早期的“这个模型适合开发我想开发程序的哪一个界面”到“依赖属性和普通属性有什么不同”，学习的目的就由解决问题变成了学习本身，所谓为学习而学习，为理解概念而学习。

第二个，我把概念看成了某种神圣的必须理解的东西，理解后才有应用的可能。如果要用锤子去钉钉子，有人对我说必须理解锤头45钢淬火过程，以及锤柄流线型中蕴含的人机工程学原理，否则我将用不好锤子，我必会大肆嘲笑他。但他如果把锤子换成C#语言，我倒立刻肃然起敬起来了。理解工具和使用工具尽管有联系，但终究是两码事。WPF是我实现目的的手段，我不必对它深入理解，就能实现自己的目的，节省时间。

读书时我经常听到“你理解不了你就用不好”此类的论调，潜移默化成为隐性的处事原则，以致工作做事中频频犯此类错误。读书时处理的是课本的内容，生活中处理的是生活本身。不顾语境死守教条，真是当代版的刻舟求剑了。

在这两个错误的指使下，我越学越广。总有理解不了的概念，这个概念也总有支撑它的概念；支撑它的概念总有涵盖它的理论。学习内容就由树干蔓延到树枝，由树枝蔓延到树叶，要达到我的开发目的，只需一捧水的知识，实际上我却淹没在学习的海洋里。

这两个错误其实就是无法合理界定学习内容的原因。没有能力建立学习的边界，就会浪费时间、劳多功少、破坏心情。时时确认学习与目的相呼应，以及用看工具的眼光看学习，让学习成为实现与创造的支柱，而不是巨大的拖累和时间的蛀虫。