思考、学习新技术的原则和方式

 

　　先看下面这样的疑心：

最近相识了几个MVC的框架，其中有两个是公司内部的。发现这些工具都是类似的，从处置惩罚逻辑到页面渲染；从service到layout；设置的实现无非就是XML，或者annotation……我有种感受，兴许已经跳不出这个头脑圈子了？现在的时代，是一个观点翻飞的时代，oschina里的开源软件数目就已经凌驾了两万，五花八门的手艺层出不穷，到底什么手艺才是值得学习的？有位朋侪说，他想学习一些关于Android上的开发手艺，兴趣驱使。几个月已往了，他说他已经能做出许多小程序了，可是他现在追念起来，掌握一门手艺是好，可兴趣之外另有什么呢？他说，“若是我的事情中不使用Android平台，我学它另有何用？”。学习手艺到底是一件有意思的事，照旧一件痛苦的事？念书的时间，我曾经买过侯捷翻译的《深入浅出MFC》，对那时的我来说，似乎太难题了一点，我强迫自己看完了三分之一，着实是没有毅力继续往下读了。我在其中察觉不到快乐，这本书在其时似乎充满了生涩。

　　如上这样的故事太多了，许多时间，程序员们（包罗我在内）辛劳地学习，有的没有好的效果，有的历程充满痛苦，有的更是不知道我学它的目的是什么。

　　海内的教育体制，造就了这样一批人：

　　他们起劲、奋进，热爱手艺，愿意投身软件行业，愿意写出高质量的代码，他们对业界的工具很感兴趣，他们愿意学习扎实的基础知识，他们渴求火热的新手艺……

　　几年以后，他们拥有普遍的视野，阅历宽阔、履历老练、言辞犀利，对行业动态了如指掌，显然，他们是行业的博学者。

　　然而……

　　他们却缺乏这样一种能力——思索。

　　欠缺思索容易导致这样的征象：

不会做设计

　　遇到了问题，拿见到过的、学到了的熟悉的框架、方案、模式往上套，而不仔细剖析其中的利弊，只是尽可能地寻找最靠近当前问题的解决途径。

　　有的是不会做系统设计。和少数所谓的“架构师”接触过，他们“只懂营业，不懂手艺”，这样设计出来的系统只能知足功效性需求；而论坛上的一些详细问题的讨论话题，则袒露出一些跟帖讨论者“只谈手艺，不提营业”，譬如“XXX大容量的解决方案”、“秒杀系统的最终架构”，贪图对某一类宽泛的问题，设计出一套放之四海皆准的通用解决方案。

　　另有的则是不会做面向工具设计，缺少抽象息争耦的能力，这样的例子就更多了。朋侪告诉我，他的单元有一位写Ruby的老员工，一个重大的工程，代码内里居然只有一个天主类，就搞定了所有的问题。

不能坚持自己的看法

　　这一点在面试中最容易视察到。应聘者有刚结业的学生，也有事情凌驾10年的有富厚履历的从业者。他给出一个大略的方案以后，在方案没有细化到一定水平以前，很难给出优劣的谈论，可是，若是你轻轻地challenge一下，他就迅速放弃原来的构想，跑到你的思绪上来。

　　例如，SNS系统中，服务端有新闻要怎样通知到客户端，这样的一个问题，解决方案有许多种，好比客户端轮询、服务端hold住毗连推送等，各有利弊。应聘者应当有自己的看法。

不能细化一个问题解决方案

　　怎样区分一个空谈家和一个实干家？给他一个详细的问题是最好的措施。在我刚事情的时间，我曾经很钦佩那些在运动中、讨论中高谈阔论的人，我以为他们很能说。可是厥后我逐渐发现，能说的人着实是太多太多了。细化设计、甚至落到编码，才是对一个程序员真实的磨练。固然，若是你以为做软件设计的人可以不熟悉编码、架构师可以不首先是一名高级程序员，那我们也没有什么可谈了 :)。

　　若是你会学习，你可以发展得很快；若是你不会思索，你永远只能跟在别人后面。

　　在新手艺的学习上我以为也应当多思索，差别的人有差别的学习念头。在非外界所迫的情形下，对于新手艺的学习，我的看法可以归纳综合为：

它要解决什么问题，就是所谓的问题域，是我体贴的吗？

　　我没有去研究操作系统底层的实现，并非这没有价值，而是我没有兴趣，这就是问题域的影响（不外现在我有兴趣了，我想做一些这方面的事情）。

 1/2    1 2 下一页 尾页