学习技术的第二条路 2014-05-21 我从大学四年级开始，就一直在学习编程技术，至今已有七年。 能够不中断地学习七年，与工作平台的变迁有很大关系，Linux服务端，Windows桌面端，网页，移动端App。所用的语言从追求效率极致的C，到强大而复杂的C#，再到奇迹一样流行起来的JavaScript。数据库方面，从小巧的内存数据库到SQL再到No-SQL。由于各平台差异较大，这些技术之间并无太多交集，因此要不断学习新的技能。 遇到新的技术，过去我都是先找本书来学，看完这本书，有了较为系统的理解，然后再拿来实践。这是沿袭自学生时代的做法。 然而最近几年，先学后用的老套路逐渐暴露出问题。刚刚才读过的书，最后能派上用场的只有十之一二。技术更迭得越快，领域划分得越细，这状况就越发明显。 都说学以致用，学的知识若用不起来会很快淡忘，付出的精力也就浪费掉了。之前在简书上看到一篇文章《求知成瘾，却无作品》，也谈到了这个问题。知识若转化不成作品，人就变成了只见流入却不见流出的知识黑洞。 也有人渴望一劳永逸，走在了与求知成瘾相反的另一个极端。想起刚刚工作的时候，我们应届毕业的新员工上岗之前先技术培训，一波人分成两个方向，C和Java。我是C方向的，当时培训C的老师关起门来，语重心长地讲，还是C好，几十年不变，一招吃遍天下，不像Java知识更新那么快。 后来做了Web开发，每几天就要被新出的牛逼技术震撼一次，才知道那位老师的想法有多么保守可笑。新工具带来的生产力提升，远高于其学习成本。若抱守残缺固步自封，就算你把刀法练得炉火纯青，也终究敌不过飞机大炮。 JavaScript Weekly每周发一封订阅邮件，告诉我JavaScript的世界里又发生了什么，差不多每两三个礼拜就有新东西冒出来，一年足可以颠覆从前。这么快的速度，先学后用的老套路明显跟不上节奏了。 全栈工程师(full stack engineer)是最近流行起来的新角色，指的是全能型的软件工程师，尤其在创业公司，这种工程师非常受追捧。不像传统的专修某个方向的工程师，全栈工程师甚至都没有方向这一说，因为所有的工作他都要做。 从前端到后端，知识浩如烟海，要能应付得来，必须换一种方法。上来先不要做太多技术准备，而是quick and dirty地让软件运行起来。然后再一点一点加功能、做优化。路途中必会遇上很多技术难题，这才到了真正该学习的时候。以前学习，是捧起书来从头看到尾，目标不够具体，容易犯困。带上问题看书就不一样了，主动求解，略过大篇无用的部分，直奔目标。 当然这种由问题驱动的学习，也不是那么完美。它最大的弊端，是因缺乏系统学习而错过一些最佳实践，以至于把笨办法重复若干遍，长期来看反倒降低了效率。 最近在Web Development with Node and Express里看到一段话，对这个问题做了精辟的阐述：
如果一项工作要重复几十上百遍，那么不管它重不重要，都应该看看高人是怎么做的。若一开始就掌握了巧妙的方法，后面一定能把学习花去的时间追回来。 然而现实中，开发产品的工期一般都比较赶，这种情况下，什么时候该停下来学习？答案是，当你觉得有地方不对劲了，一般也就是到了该学习的时候。但对于这条准则，不同人把握的尺度不一样。自我感觉良好的人，从来不觉得哪里不对劲，于是永远错下去，永远重蹈旧辙。相反，过于挑剔和自省过重的人，比如我自己，总希望一切都完美之后再迈出下一步，结果常常是过分纠缠于细节而止步不前。 最后谈一下技术书。在stackoverflow如此强大的今天，技术书的地位已远不如前。开发中被技术问题block，首先想到是去网上寻找快速直接的答案，逢山开路遇水搭桥。但不能忽视其他一些隐性的技术问题，它们虽然没有block你，但是可以拖慢你，长期地消耗你。解决这些重要但不紧急的事情，需要付出大块的时间，收益也是显著的。这时候，技术书就派上用场了。 读技术书，其实就是为了走捷径，作者走过的路，踩过的坑，读者不必再亲历一遍。前人总结的经验教训，早知早受益，但如果准备得过度，也会得不偿失。尤其在IT领域，每一项技术，每一条经验，都是有保鲜期的。刚出来的时候最新鲜可口，半年之后光华已褪，待两三年后，很可能技术已改朝换代，这些前朝老臣全都没有了用武之地。 以上内容如果没怎么看进去也没关系，只需记住一句：学习技术，为的不是做出好产品，而是在极为有限的时间内做出好产品。 |
|
|
