程序员在学习新技术要思考哪些事

[学习要像天才般那样思考]“即使你不是一位天才，你照样可以使用象爱因斯坦和亚里士多德一样的思考战略与战术来增强你的思维创造性并更好地设计你的未来。”为了找出解决问题的方法，下列的八种战略与战...+阅读

程序员在学习新技术要思考哪些事

先看下面这样的困惑：最近了解了几个MVC的框架，其中有两个是公司内部的。发现这些东西都是类似的，从处理逻辑到页面渲染；从service到layout；配置的实现无非就是XML，或者annotation……我有种感觉，兴许已经跳不出这个思维圈子了？如今的时代，是一个概念翻飞的时代，oschina里的开源软件数量就已经超过了两万，五花八门的技术层出不穷，到底什么技术才是值得学习的？有位朋友说，他想学习一些关于Android上的开发技术，兴趣驱使。几个月过去了，他说他已经能做出许多小程序了，可是他现在回想起来，掌握一门技术是好，可兴趣之外还有什么呢？他说，“如果我的工作中不使用Android平台，我学它还有何用？”。学习技术到底是一件有意思的事，还是一件痛苦的事？读书的时候，我曾经买过侯捷翻译的《深入浅出MFC》，对那时的我来说，似乎太困难了一点，我强迫自己看完了三分之一，实在是没有毅力继续往下读了。

我在其中察觉不到快乐，这本书在当时似乎充满了生涩。如上这样的故事太多了，很多时候，程序员们（包括我在内）辛苦地学习，有的没有好的效果，有的过程充满痛苦，有的更是不知道我学它的目的是什么。国内的教育体制，培养了这样一批人：他们努力、奋进，热爱技术，愿意投身软件行业，愿意写出高质量的代码，他们对业界的东西很感兴趣，他们愿意学习扎实的基础知识，他们渴求火热的新技术…… 几年以后，他们拥有广泛的视野，阅历宽阔、经验老到、言辞犀利，对行业动态了如指掌，显然，他们是行业的博学者。然而…… 他们却缺乏这样一种能力——思考。欠缺思考容易导致这样的现象：不会做设计遇到了问题，拿见到过的、学到了的熟悉的框架、方案、模式往上套，而不仔细分析其中的利弊，只是尽可能地寻找最接近当前问题的解决途径。

有的是不会做系统设计。和少数所谓的“架构师”接触过，他们“只懂业务，不懂技术”，这样设计出来的系统只能满足功能性需求；而论坛上的一些具体问题的讨论话题，则暴露出一些跟帖讨论者“只谈技术，不提业务”，譬如“XXX大容量的解决方案”、“秒杀系统的终极架构”，企图对某一类宽泛的问题，设计出一套放之四海皆准的通用解决方案。还有的则是不会做面向对象设计，缺少抽象和解耦的能力，这样的例子就更多了。朋友告诉我，他的单位有一位写Ruby的老员工，一个庞大的工程，代码里面居然只有一个上帝类，就搞定了所有的问题。不能坚持自己的观点这一点在面试中最容易观察到。应聘者有刚毕业的学生，也有工作超过10年的有丰富经验的从业者。他给出一个粗略的方案以后，在方案没有细化到一定程度以前，很难给出优劣的评论，但是，如果你轻轻地challenge一下，他就迅速放弃本来的构思，跑到你的思路上来。

例如，SNS系统中，服务端有消息要怎样通知到客户端，这样的一个问题，解决方案有很多种，比如客户端轮询、服务端hold住连接推送等，各有利弊。应聘者应当有自己的观点。不能细化一个问题解决方案怎样区分一个空谈家和一个实干家？给他一个具体的问题是最好的办法。在我刚工作的时候，我曾经很钦佩那些在活动中、讨论中高谈阔论的人，我觉得他们很能说。可是后来我逐渐发现，能说的人实在是太多太多了。细化设计、甚至落到编码，才是对一个程序员真实的检验。当然，如果你觉得做软件设计的人可以不熟悉编码、架构师可以不首先是一名高级程序员，那我们也没有什么可谈了：）。如果你会学习，你可以成长得很快；如果你不会思考，你永远只能跟在别人后面。

在新技术的学习上我认为也应当多思考，不同的人有不同的学习动机。在非外界所迫的情况下，对于新技术的学习，我的观点可以概括为：它要解决什么问题，就是所谓的问题域，是我关心的吗？我没有去研究操作系统底层的实现，并非这没有价值，而是我没有兴趣，这就是问题域的影响（不过现在我有兴趣了，我想做一些这方面的事情）。和过往解决方案它的优势在哪里，是否显著？这是competition，重复的技术是没有生存空间的（当然，你是微软的话除外：）），就像互联网同一个类型的网站，竞争到最后就那么两三家。就像Groovy，我很喜欢它，但是有了Scala以后，我觉得兴许有一个要死掉（Groovy创始人说，如果他早些知道Scala的话，就没有Groovy什么事了。具体的报道请去Google上搜他的blog）。

它的实现和带来的效果上看，有没有很有意思的思路，是值得借鉴和思考的？这是最难讲的一个问题。以去年初开始接触的Node.js为例，它可以做到把后端的聚合（譬如portlet之流）放到前端来，后端只保留一种类型的页面服务——页面模板，以及若干易于管理的API接口，大大简化了后端体系的复杂度，而且还能把压力分散到前端来，这是我早些年不曾见到的。这三个问题想过之后，觉得有价值，我才去学习。要不然，对我而言就是不想深入的东西，了解了解也就罢了。新技术学习的方式呢，我想说这么几点：寻找切入点我很喜欢BlueDavy的blog上的一句话：“理论不懂就实践，实践不会就学理论！”。最后最好是要落到动手...

一个程序员需要什么技术素质才是好的程序员

作一个真正合格的程序员，或者说就是可以真正合格完成一些代码工作的程序员，应该具有的素质。 1：团队精神和协作能力把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人就完全不合格了。 2：文档习惯说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30%的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。

缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。 3：规范化，标准化的代码编写习惯作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。有些codingfans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可想象的。 4：需求理解能力程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑，有人曾经放言说写一个广告交换程序很简单，这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也做不出太极链的并访能力。

性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。 5：复用性，模块化思维能力经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成了熟练程序员的主要工作，而这些，其实是完全可以避免的。复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投入到创新的代码工作中去。

一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部代码重写，大部分重复性工作无谓的浪费了时间和精力。 6：测试习惯作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。

当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试，并尽早发现和解决问题，当然这需要上面提到的需求理解能力。 7：学习和总结的能力程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。但是学习也要找对目标，一些小codingfans们，他们也津津乐道于他们的学习能力，一会学会了asp，一会儿学会了php，一会儿学会了jsp...

java软件工程师那里可以学习新的技术以及怎么提升自己薪资希望

每个程序员根据自己的公司业务项目、产品需要或兴趣会往不同的技术路线发展，java体系本身就很庞大，每个体系都够学习一辈子的，我以前公司有个博士尽十年就专门研究消息中间件，在消息中间件领域非常精通。

如果要学习新技术，无非就是上网看资料，可以订购csdn的程序员杂志或infoq的架构师每周精选等等，都会有较新的技术出现，但都是大概说明，感兴趣了可以自己再找相关资料研究，个人觉得对有兴趣的研究下，其他很多东西不必要往深里研究，只为扩展知识面，碰到问题知道这个可以解决就好，倒是针对具体问题再研究会比较好。

至于提高自己薪资能力等，个人觉得一个软件工程师的成长分为技术和业务两部分，要共同成才，技术好了，业务不好，分析问题不透彻，只能永远是个程序员，业务好了技术不好，分析完问题不能实现，站不到技术角度分析问题也是不行，所以要想成长快，两者同时锻炼，业务当然是通过做项目实践，业务分析成长最快，技术锻炼就不说了。业务精通，再有技术，写需求、设计、方案等文档就不在话下，自然最起码是项目经理了。当你的word、excel、ppt等办公软件用的比eclipse还熟的时候工资自然上去了。更何况软件发展到目前程度，很多公司用第三方框架开发，技术难度非常低，这时业务就显的更为重要，所以目前这个状况相比来说，业务还比技术更重要一些。如果你现在还不知道你的发展方向，是因为你积累的还不够，当你积累够了，真正有自学能力了，就自然知道自己的方向了。

个人建议仅供参考。