什么样的技术人才最受欢迎？说下我个人的感受

什么样的技术人才最受欢迎？说下我个人的感受

    也工作几年了，陆陆续续做过很多不同的项目，也面试过不少人，结合我个人的经验及面试的心得，稍微总结一下。
    对于没有工作经验的，一般都是看他的基本功和他的态度；
    对于有工作经验的，怎么看这个人的潜力和水平？
我个人觉得一般做题这东西不太靠谱，面试者他熟悉的东西和他的项目经验未必被你的题覆盖到，另外在写代码过程中，未必会记下所有细节，高人一般都是在用到的时候去资料中查细节问题。大脑中存着太多细节，可能就没有空间去存放一些更重要的东西了。

    我面试，一般一开始就问他有没有处理过什么疑难杂症，疑难杂症一般都是技术问题，要花费一周、一天或几个时间去攻关解决的，可能一个人还搞不定，还需要多人一起搞。
    要解决疑难杂症，一方面需要比较广的知识面，另一方面也需要良好的心理素质。
    就知识面而言，比如，一个新员工要一天解决的问题，某老员工可能只需要几分钟，因为某些问题老员工他可能之前已经花了很多精力去攻关过，这是知识面的一方面，一般我们称之为工作经验，另外知识面还包含业务知识、编程技术、学习能力等，无法用几句话概括（至少我还没有能力用几句话把它概括）。在不同项目中，可能要用到不同的编程语言，或者同种语言中的不同架构和不同组件，数据库、操作系统、编译器、平台等都涉及到不同的技术细节，你涉及过的东西越多，你的视野也就开阔。我个人感觉，如果你做过不同类型的项目，开发过不同的东西（可能会基于不同的编程语言），你的视野一般会比一直做同一个项目的人要开阔，毕竟接触的东西要多，而且需要学习的内容也会多一些。
    心理素质，我个人总结就是信心+耐心+决心。信心最重要，遇到难题，大家都会摸不着头脑，这个很正常，关键是你如何能战胜自己的心理恐慌，信心就很关键了，即使是没有处理过的问题，只要你有信心，你很快就能镇定下来，把心思花在具体的问题上；哈哈，信心是第一步，敢面对难题，我们还需要做好打持久战的准备，还需要有耐心；有时有些难题，会花上几个小时、一天、一周甚至几周才能搞定，这么长的时间内，你会不停地郁闷、痛苦，但你还要找方法去解决问题，哈哈，如果把解决问题的目的给忘了，那结果你知道的；至少决心嘛，一般我们的郁闷达到最高点时，可能就越接近问题的根因了，这时如果扛不住，就功亏一篑了。下定决心吧，不把问题搞定，就不吃饭、不睡觉、不回家、不去见女朋友，还有不干嘛，你自己想吧。只要你有这个决心，那问题就一定能搞定，如果还搞不定，就去找你的领导吧。
    我个人遇到过的难题，如果按解决问题的时间长度来算，应该有20个吧，哈哈。过程确实很痛苦，但问题解决过后豁然，也只有个人知道；你对某个问题的认识，或者对某个知识面的把握，可能一下子就进了一步。

    如果你经常面试人，可以试试我的方法；如果你打算被面试，也考虑一下自己工作几年内遇到过哪些难题；如果工作一两年一个都没有遇到过或者一个都想不起来，哈哈，考虑一下自己的工作态度是不是有问题？就算自己没有亲自解决，也得耳睹目染过别人解决问题的过程吧？如果这个都没有经历过，你是不是对技术一点追求都没有？如果你能想起来那么几个，恭喜你，把过程好好总结一下吧，能总结出的东西越多，那你的升值空间就越大，在解决问题、总结问题的过程中，相信你会有大的提升。

 

 

 

再补充一些我个人认为比较重要的知识点：

1、精通某一编程语言（所谓精通，比如Java，除了熟悉使用常用的工具类、语言特性外，还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等）；

2、某种脚本（Windows的Bat、Linux的Shell），有时熟练使用某些脚本会带来意想不到的便利；

3、对涉及到的协议的掌握，比如你搞页面开发，HTML协议的RFC一定好好看看（比如之前我处理的几个问题，都与Http 1.0与Http 1.1的特性差异有关）；

4、对网络知识要有所了解，及对抓包工具（Wireshark）的熟练使用，在处理一些疑难问题（如各种乱码问题）时，会在你定位问题给你很大的帮助；

5、对数据库要有一些基本的认识，比如常用的sql调优等；

 

我给大家的建议是，至少要在某一方面做到足够深入，让大家知道你在某一方面很强，处理这方面的问题时你就是专家；然后再扩展自己的知识面，尽可能多了解一点其它知识点，至少在遇到这方面的问题时，你知道去哪里找资料；不要让自己什么都学精通，你没有那么多精力的。

你要相信平时的积累会在某个时间点发挥出价值，所以真的不用担心自己的积累会无用武之地。

 

另外，我个人觉得最重要的一点是掌握方法，就像处理疑难问题，处理得次数多了，你会从中找到一些规律和窍门的，这个就是我说的方法。

在 平时的学习和工作的过程中，要注意总结，把自己认为重要的或对自己有帮助的及时输出到文档中；刚开始可能总结不出什么，但多总结几次，可能你就能总结出很 多东西，其实这就是你在进步。哪天你突然发现自己在解决问题时是按照某些特定的步骤去定位的，并且这样处理问题基本能得到解决，相信你的能力已经提高了很 多。

 

所谓功在平时，平时的积累最重要，遇到问题要淡定，积极而平静的心态会让你走得更远。

评论

30 楼 咖啡豆子 2011-06-24  

zhao3546 写道

咖啡豆子 写道

pangpang514 写道

“永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。”
必须ding你了。。。。。我ding你的肺！！！！！

一个程序的价值取决于客户愿意掏多少钱，除非你把计算机当成科学研究，单纯把眼光局限在技术本身上，到最后仅仅是一名经验丰富的熟练工而已

技术是成长的垫脚石，如果你觉得技术一无是处，不知道你为何还要干这个；
我给大家共享一下自己的经验，不是让大家把眼光局限于技术，而是为了给大家一点启示，你工作前几年在做编码，几年后如果你认为自己还只能编码，那你也只能做熟练工了。

我只是说不要单纯局限于技术，在你眼里就成了技术一无是处，未免有些狭隘和偏激了吧。
JVM说大天了也就是一家公司下面的一个工程性质的产品，了解这个产品的细节固然重要，但是天天把这些挂在嘴上和研究茴字有四种写法有什么区别？来这个坛子里的讨论这样问题的人，普遍水平有多高大家心里都清楚，相信这里绝大部分人所在的公司都是做工程性质，商业性质的业务，与其在这里纸上谈兵，大家还不如多想一下，多观察一下自己公司里比自己早几年的人都是什么状态，再分析一下别人都是走的什么路线，不同的路线前景如何，这样或许对自己更有启发。

29 楼 wwwzzz8595 2011-06-24  

说的很好，可惜很多面试官自己都不懂，还说别人说的不对！

28 楼 panggezi 2011-06-24  

Smart and gets things done.

27 楼 lyx4873281 2011-06-24  

<div class="quote_title">zhao3546 写道</div>
<div class="quote_div">
<p><span style="font-size: small;"><strong>什么样的技术人才最受欢迎？说下我个人的感受</strong>
</span>
<br><br>
    也工作几年了，陆陆续续做过很多不同的项目，也面试过不少人，结合我个人的经验及面试的心得，稍微总结一下。<br>
    对于没有工作经验的，一般都是看他的基本功和他的态度；<br>
    对于有工作经验的，怎么看这个人的潜力和水平？<br>
我个人觉得一般做题这东西不太靠谱，面试者他熟悉的东西和他的项目经验未必被你的题覆盖到，另外在写代码过程中，未必会记下所有细节，高人一般都是在用到的时候去资料中查细节问题。大脑中存着太多细节，可能就没有空间去存放一些更重要的东西了。<br><br>
    我面试，一般一开始就问他有没有处理过什么疑难杂症，疑难杂症一般都是技术问题，要花费一周、一天或几个时间去攻关解决的，可能一个人还搞不定，还需要多人一起搞。<br>
    要解决疑难杂症，一方面需要比较广的知识面，另一方面也需要良好的心理素质。<br>
    就知识面而言，比如，一个新员工要一天解决的问题，某老员工可能只需要几分钟，因为某些问题老员工他可能之前已经花了很多精力去攻关过，这是知识面的一方面，一般我们称之为工作经验，另外知识面还包含业务知识、编程技术、学习能力等，无法用几句话概括（至少我还没有能力用几句话把它概括）。在不同项目中，可能要用到不同的编程语言，或者同种语言中的不同架构和不同组件，数据库、操作系统、编译器、平台等都涉及到不同的技术细节，你涉及过的东西越多，你的视野也就开阔。我个人感觉，如果你做过不同类型的项目，开发过不同的东西（可能会基于不同的编程语言），你的视野一般会比一直做同一个项目的人要开阔，毕竟接触的东西要多，而且需要学习的内容也会多一些。<br>
    心理素质，我个人总结就是信心+耐心+决心。信心最重要，遇到难题，大家都会摸不着头脑，这个很正常，关键是你如何能战胜自己的心理恐慌，信心就很关键了，即使是没有处理过的问题，只要你有信心，你很快就能镇定下来，把心思花在具体的问题上；哈哈，信心是第一步，敢面对难题，我们还需要做好打持久战的准备，还需要有耐心；有时有些难题，会花上几个小时、一天、一周甚至几周才能搞定，这么长的时间内，你会不停地郁闷、痛苦，但你还要找方法去解决问题，哈哈，如果把解决问题的目的给忘了，那结果你知道的；至少决心嘛，一般我们的郁闷达到最高点时，可能就越接近问题的根因了，这时如果扛不住，就功亏一篑了。下定决心吧，不把问题搞定，就不吃饭、不睡觉、不回家、不去见女朋友，还有不干嘛，你自己想吧。只要你有这个决心，那问题就一定能搞定，如果还搞不定，就去找你的领导吧。<br>
    我个人遇到过的难题，如果按解决问题的时间长度来算，应该有20个吧，哈哈。过程确实很痛苦，但问题解决过后豁然，也只有个人知道；你对某个问题的认识，或者对某个知识面的把握，可能一下子就进了一步。<br><br>
    如果你经常面试人，可以试试我的方法；如果你打算被面试，也考虑一下自己工作几年内遇到过哪些难题；如果工作一两年一个都没有遇到过或者一个都想不起来，哈哈，考虑一下自己的工作态度是不是有问题？就算自己没有亲自解决，也得耳睹目染过别人解决问题的过程吧？如果这个都没有经历过，你是不是对技术一点追求都没有？如果你能想起来那么几个，恭喜你，把过程好好总结一下吧，能总结出的东西越多，那你的升值空间就越大，在解决问题、总结问题的过程中，相信你会有大的提升。</p>
<p> </p>
<p> </p>
<p> </p>
<p><strong>再补充一些我个人认为比较重要的知识点：</strong>
</p>
<p>1、精通某一编程语言（所谓精通，比如Java，除了熟悉使用常用的工具类、语言特性外，还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等）；</p>
<p>2、某种脚本（Windows的Bat、Linux的Shell），有时熟练使用某些脚本会带来意想不到的便利；</p>
<p>3、对涉及到的协议的掌握，比如你搞页面开发，HTML协议的RFC一定好好看看（比如之前我处理的几个问题，都与Http 1.0与Http 1.1的特性差异有关）；</p>
<p>4、对网络知识要有所了解，及对抓包工具（Wireshark）的熟练使用，在处理一些疑难问题（如各种乱码问题）时，会在你定位问题给你很大的帮助；</p>
<p>5、对数据库要有一些基本的认识，比如常用的sql调优等；</p>
<p> </p>
<p>我给大家的建议是，至少要在某一方面做到足够深入，让大家知道你在某一方面很强，处理这方面的问题时你就是专家；然后再扩展自己的知识面，尽可能多了解一点其它知识点，至少在遇到这方面的问题时，你知道去哪里找资料；不要让自己什么都学精通，你没有那么多精力的。</p>
<p>你要相信平时的积累会在某个时间点发挥出价值，所以真的不用担心自己的积累会无用武之地。</p>
<p> </p>
<p>另外，我个人觉得最重要的一点是掌握方法，就像处理疑难问题，处理得次数多了，你会从中找到一些规律和窍门的，这个就是我说的方法。</p>
<p>在
平时的学习和工作的过程中，要注意总结，把自己认为重要的或对自己有帮助的及时输出到文档中；刚开始可能总结不出什么，但多总结几次，可能你就能总结出很
多东西，其实这就是你在进步。哪天你突然发现自己在解决问题时是按照某些特定的步骤去定位的，并且这样处理问题基本能得到解决，相信你的能力已经提高了很
多。</p>
<p> </p>
<p>所谓功在平时，平时的积累最重要，遇到问题要淡定，积极而平静的心态会让你走得更远。</p>
</div>
<p>小菜鸟路过。。。</p>

26 楼 chenyunhong 2011-06-24  

总结的很好！

25 楼 eman 2011-06-24  

zhao3546 写道

jaystarba 写道

受益匪浅，，很是受教了。
只是不知道的还很多，该怎么学呢？？？

怎么学？其实很简单，踏实地做好本份工作，在做项目的过程中，适当地拓展和延伸，让自己知识的深度和广度得到发展。
在遇到问题的过程中，适当地加以深入学习，这种方式个人觉得收获最大，印象也最深刻。

我第一次花了两三周解决一个内存泄露的问题后，对JVM的内存管理及JVM的一些高级命令的掌握一下子提升了不少，当然中间的过程也很痛苦，但解决了这个问题后，领导一下子就认可了我。

什么高级指令，说来听听。

24 楼 zhao3546 2011-06-23  

咖啡豆子 写道

pangpang514 写道

“永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。”
必须ding你了。。。。。我ding你的肺！！！！！

一个程序的价值取决于客户愿意掏多少钱，除非你把计算机当成科学研究，单纯把眼光局限在技术本身上，到最后仅仅是一名经验丰富的熟练工而已

技术是成长的垫脚石，如果你觉得技术一无是处，不知道你为何还要干这个；
我给大家共享一下自己的经验，不是让大家把眼光局限于技术，而是为了给大家一点启示，你工作前几年在做编码，几年后如果你认为自己还只能编码，那你也只能做熟练工了。

23 楼 zhao3546 2011-06-23  

李飞006 写道

  我毕业到现在没有跳过，所以知道的也就是，同学的公司怎么怎么样。
  LZ说的遇到难题要去解决，还要那么长时间，那到要问问一个公司一个项目允许你去花那么多时间去解决一个问题吗？我遇到过小问题，会给我时间思考解决，但是问题稍微大些 组长如果自己知道便自己解决，不知道绕道而行，坚决不去浪费时间。能给你工资还让你浪费时间在一个问题点上一个月左右的公司有几个，技术部不知道会怎么样，但我觉得不会让一个程序员干那事。

兄弟，如果你遇到一个问题，最后要不就是不了了之，要不就是他人处理，你啥时能发挥价值？
在这样的公司时，我不知道你何时可以成长起来？
---- 建议你早点跳吧

第一次听说解决问题算是浪费时间的？
如果你们的系统在现网运行崩溃了，不知道你们领导是不是也不把这个当回事。

22 楼 咖啡豆子 2011-06-23  

pangpang514 写道

“永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。”
必须ding你了。。。。。我ding你的肺！！！！！

一个程序的价值取决于客户愿意掏多少钱，除非你把计算机当成科学研究，单纯把眼光局限在技术本身上，到最后仅仅是一名经验丰富的熟练工而已

21 楼 李飞006 2011-06-23  

  我毕业到现在没有跳过，所以知道的也就是，同学的公司怎么怎么样。
  LZ说的遇到难题要去解决，还要那么长时间，那到要问问一个公司一个项目允许你去花那么多时间去解决一个问题吗？我遇到过小问题，会给我时间思考解决，但是问题稍微大些 组长如果自己知道便自己解决，不知道绕道而行，坚决不去浪费时间。能给你工资还让你浪费时间在一个问题点上一个月左右的公司有几个，技术部不知道会怎么样，但我觉得不会让一个程序员干那事。

20 楼 dominic6988 2011-06-23  

<div class="quote_title">神之小丑 写道</div>
<div class="quote_div">我那天去面试，面到最后领导了， <br>领导就问我 操作系统 问我算法，因为工作后，学校里的很多东西忘了 <br><br>所以就没打上来，然后他就说我技术不行， <br><br>然后我就跟他理论（已经带情绪了，争论了很久）， <br><br>不过还好，最后那领导改变观点了</div>
<p> </p>
<p> 兄弟其实你不应该这样，以我的经验我就是不会我也瞎忽悠，因为领导不可能懂这些东西，所以你无论讲什么东西他都是听不懂。</p>
<p>他这是故作深沉在跟你玩装比游戏呢。你要看出来。</p>

19 楼 yuchangsheng 2011-06-22  

要记那些遇到困难的时刻，那平时心情能好吗？要不咋说过劳死呢！我基本上处理完棘手问题只要保证下次在遇到知道就行了，我才不记着过程呢，太伤脑细胞！同意的打钩啊

18 楼 kyfxbl 2011-06-22  

我觉得楼主说的“先在某一方面成为专家，再扩展知识面”，这一点很有道理

17 楼 Caedmon 2011-06-22  

Durian 写道

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

遇到过几次内存溢出。
eclipse编译大工程时候溢出，只要设置eclipse的初始化参数 =256m就可以。
死循环也会溢出
递归次数过大肯定溢出
不确定数据连接不关闭，连接数占满是否溢出？
这些问题靠jvm能解决?

另外，看类加载有啥用?

笑而不语，笑而不语。。。。

16 楼 jackra 2011-06-21  

zhao3546 写道

jackra 写道

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

内存泄漏？我见过，有文件句柄不够的，也有数据库连接超越最大允许数的，还有各种不关游标的，各种不关statment的。
程序员不一定必须要犯这样的错误，片面的强调这些，其实不见得是好事。很难想象在一组嵌套的N千行的function里，一个人能控制自己所有的逻辑代码。一些有好习惯和良好的素质教育的程序员，就算没有经验，也不见得就一定要犯你说的错误，他们在创造外部资源依赖的时候，或许已经就对外部资源进行了关闭。这些其实是基础知识，接受过良好的编程教育或者认真的对待这些经验问题的人，是可以通过学习学到的。
对于资源管理的知识，有些人当回事，有些人不当回事。很难说，把结构搞的很复杂，然后自己的资源控制不住，到底是水平问题，还是智商问题，或者是根本没用心思的问题。

程序员的基本素质，永远不会认为自己没有错误，而是计算机在犯错误。任何的错误都可能是由人导致的，而绝对不会是机器。你可以说JVM会有差异，也可以说操作系统有问题，但是机器永远代表的是现实存在的物理规律，而不是可以随便犯违反规律错误的带有情绪和不确定因素的活物。

聪明的程序员，要想办法防止自己陷入麻烦，进而防止团队陷入麻烦。所以聪明的程序员，应该学会挑选合适的团队、合适的领导、合适的团队，更聪明的程序员，就得做到“宁武子邦有道则知，邦无道则愚；其知可及也，其愚不可及也。”该钓鱼的时候钓鱼，该摸鱼的时候摸鱼吧。

事实上，聪明的程序员，会把麻烦的事情想到合适的解决办法。比如对于可能变化的设计，保存足够的生成代码的资料（详细设计），比如避免重复劳动而花费写时间为需要重复做的事情写脚本，还有必须发现项目的潜在危险（比如不确定的需求，无法确定的客户态度，以及无法确定的领导结构）。但是，其实聪明的程序员，不见得是成功的，毕竟现阶段的环境就是如此，天才也不一定能胜的过天朝。呵呵。

也许有时候，技术并不是真正的核心内容也说不定。永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。

如果一个程序员遇到各种难题并能解决，我相信他的基本编程技能肯定是没有问题，至少他遇到过的问题他不会再犯了；另外，解决过一些难题后，心态也会成熟很多，这点我想你多少会有感受。你第一次遇到难题和你第十次遇到难题的心态，肯定会相差很多吧。
你解决技术问题的过程，正是你个人能力和水平的体现，如果你还将这些问题总结并分享出来，在总结的过程中，你个人肯定会收益良多，分享的过程，肯定也会对他人有不少启示。

从长远来看，技术多少还是要为产品服务，如果你做的产品没有任何价值，就算你的技术再先进又能如何？

其实在论坛上和大家交流也是一种分享，就算我的观点你不同意，我的观点多少也引起你的思考了，不是吗？

我不是否认你的观点。而是从另一个方面来阐述问题而已。中国文化里有很多很多的“只有。。。才能。。。”可事实情况真的如此吗？最少从一些天才的事件中一次次的在阐述“如果。。。也能。。。”我只是觉得，没有必要给什么所谓的后辈必要的框框，自由的天空下，才有自由的代码飞翔。不可否认，IT方面是有天才的，我无法想象这些天才的大脑，但我尊重他们与众不同的智慧。

15 楼 zhao3546 2011-06-21  

jaystarba 写道

受益匪浅，，很是受教了。
只是不知道的还很多，该怎么学呢？？？

怎么学？其实很简单，踏实地做好本份工作，在做项目的过程中，适当地拓展和延伸，让自己知识的深度和广度得到发展。
在遇到问题的过程中，适当地加以深入学习，这种方式个人觉得收获最大，印象也最深刻。

我第一次花了两三周解决一个内存泄露的问题后，对JVM的内存管理及JVM的一些高级命令的掌握一下子提升了不少，当然中间的过程也很痛苦，但解决了这个问题后，领导一下子就认可了我。

14 楼 zhao3546 2011-06-21  

jackra 写道

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

内存泄漏？我见过，有文件句柄不够的，也有数据库连接超越最大允许数的，还有各种不关游标的，各种不关statment的。
程序员不一定必须要犯这样的错误，片面的强调这些，其实不见得是好事。很难想象在一组嵌套的N千行的function里，一个人能控制自己所有的逻辑代码。一些有好习惯和良好的素质教育的程序员，就算没有经验，也不见得就一定要犯你说的错误，他们在创造外部资源依赖的时候，或许已经就对外部资源进行了关闭。这些其实是基础知识，接受过良好的编程教育或者认真的对待这些经验问题的人，是可以通过学习学到的。
对于资源管理的知识，有些人当回事，有些人不当回事。很难说，把结构搞的很复杂，然后自己的资源控制不住，到底是水平问题，还是智商问题，或者是根本没用心思的问题。

程序员的基本素质，永远不会认为自己没有错误，而是计算机在犯错误。任何的错误都可能是由人导致的，而绝对不会是机器。你可以说JVM会有差异，也可以说操作系统有问题，但是机器永远代表的是现实存在的物理规律，而不是可以随便犯违反规律错误的带有情绪和不确定因素的活物。

聪明的程序员，要想办法防止自己陷入麻烦，进而防止团队陷入麻烦。所以聪明的程序员，应该学会挑选合适的团队、合适的领导、合适的团队，更聪明的程序员，就得做到“宁武子邦有道则知，邦无道则愚；其知可及也，其愚不可及也。”该钓鱼的时候钓鱼，该摸鱼的时候摸鱼吧。

事实上，聪明的程序员，会把麻烦的事情想到合适的解决办法。比如对于可能变化的设计，保存足够的生成代码的资料（详细设计），比如避免重复劳动而花费写时间为需要重复做的事情写脚本，还有必须发现项目的潜在危险（比如不确定的需求，无法确定的客户态度，以及无法确定的领导结构）。但是，其实聪明的程序员，不见得是成功的，毕竟现阶段的环境就是如此，天才也不一定能胜的过天朝。呵呵。

也许有时候，技术并不是真正的核心内容也说不定。永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。

如果一个程序员遇到各种难题并能解决，我相信他的基本编程技能肯定是没有问题，至少他遇到过的问题他不会再犯了；另外，解决过一些难题后，心态也会成熟很多，这点我想你多少会有感受。你第一次遇到难题和你第十次遇到难题的心态，肯定会相差很多吧。
你解决技术问题的过程，正是你个人能力和水平的体现，如果你还将这些问题总结并分享出来，在总结的过程中，你个人肯定会收益良多，分享的过程，肯定也会对他人有不少启示。

从长远来看，技术多少还是要为产品服务，如果你做的产品没有任何价值，就算你的技术再先进又能如何？

其实在论坛上和大家交流也是一种分享，就算我的观点你不同意，我的观点多少也引起你的思考了，不是吗？

13 楼 ansjsun 2011-06-21  

真正的疑难杂症不是解决了的..而是无缘无故又好了的..坑爹啊..

12 楼 jaystarba 2011-06-21  

受益匪浅，，很是受教了。
只是不知道的还很多，该怎么学呢？？？

11 楼 jackra 2011-06-21  

yizhilong28 写道

jackra 写道

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

内存泄漏？我见过，有文件句柄不够的，也有数据库连接超越最大允许数的，还有各种不关游标的，各种不关statment的。
程序员不一定必须要犯这样的错误，片面的强调这些，其实不见得是好事。很难想象在一组嵌套的N千行的function里，一个人能控制自己所有的逻辑代码。一些有好习惯和良好的素质教育的程序员，就算没有经验，也不见得就一定要犯你说的错误，他们在创造外部资源依赖的时候，或许已经就对外部资源进行了关闭。这些其实是基础知识，接受过良好的编程教育或者认真的对待这些经验问题的人，是可以通过学习学到的。
对于资源管理的知识，有些人当回事，有些人不当回事。很难说，把结构搞的很复杂，然后自己的资源控制不住，到底是水平问题，还是智商问题，或者是根本没用心思的问题。

程序员的基本素质，永远不会认为自己没有错误，而是计算机在犯错误。任何的错误都可能是由人导致的，而绝对不会是机器。你可以说JVM会有差异，也可以说操作系统有问题，但是机器永远代表的是现实存在的物理规律，而不是可以随便犯违反规律错误的带有情绪和不确定因素的活物。

聪明的程序员，要想办法防止自己陷入麻烦，进而防止团队陷入麻烦。所以聪明的程序员，应该学会挑选合适的团队、合适的领导、合适的团队，更聪明的程序员，就得做到“宁武子邦有道则知，邦无道则愚；其知可及也，其愚不可及也。”该钓鱼的时候钓鱼，该摸鱼的时候摸鱼吧。

事实上，聪明的程序员，会把麻烦的事情想到合适的解决办法。比如对于可能变化的设计，保存足够的生成代码的资料（详细设计），比如避免重复劳动而花费写时间为需要重复做的事情写脚本，还有必须发现项目的潜在危险（比如不确定的需求，无法确定的客户态度，以及无法确定的领导结构）。但是，其实聪明的程序员，不见得是成功的，毕竟现阶段的环境就是如此，天才也不一定能胜的过天朝。呵呵。

也许有时候，技术并不是真正的核心内容也说不定。永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。

如果执泥于技术，会出现很搞笑的状况，学着学着就看起道德经起来，哈哈

想起很早以前的一本书《J道》以前一直想读，但是水平不够，没读懂，这家伙，估计肯定看过《道德经》