程序员-从C到Java,10年技术生涯的几点思考(精)

第一篇：程序员-从C到Java,10年技术生涯的几点思考(精)

不知不觉,做程序工作已经10年了,从最初学习C++到Java,从困惑到清晰,感觉真的有不少东西可写,不过总觉得不成体系，大概看了太多八股文章的缘故，被憋得实在难受。所以不管了，想到什么写什么吧。

1、从C++到Java

C++和Java谁快？从算法上讲我认为毫无疑问是汇编〉C++〉Java，不要迷信某些个别评测，单纯的回圈测试什么的，比如JNode的官方网站上有Java写的JVM的性能和SUN的JVM

进行性能比较的结果，JNode中用Java写的JVM竟然能比SUN公司用C++写的JVM还快！编译器完全可以作针对性优化影响测试结果，毫无意义的东西。而且，评测结果不会具备多少实际意义，真正的应用系统的效率是80%取决于整体的设计架构，而非你使用哪种语言。所以讨论汇编、C++、Java谁更快这个问题的人恐怕更多是为了自己的面子考虑，虽然Java当前如日中天，但其总是针对C++的批判性态度却再明显不过，所以Bruce才会有“C++不垃圾，只是Java很傲慢”之说。

C++和Java根本的区别是什么？我认为毫无疑问是内存分配。编程思想和设计模式是活的东西，和语言没有直接关系。Java没有指针，C++写程序也可以只用引用。JVM是Java在 内存管理上真正有别于C++的地方。JVM的好处是显而易见的，跨平台、更智能的内存管理，但能解决所有问题吗，答案是否定的。

Java没有内存泄露吗?当然不是，我认为java的内存泄露往往比C++更加难以排查，因为JVM的缘故，程序员没法直接对内存进行操控，隐患往往藏的更深。我曾经花了大量时间研究JVM的内存机制，虽然也有了不少心得，但直到现在仍然处于迷惑期。循环引用，缓存机制不合理，Spring等常态Bean的属性重复加载都是可能吃内存的元凶。

对于一个单一的，低用户低并发的系统，使用Java是很舒服的，程序员不用去考虑太多事情，照着业务逻辑做设计编代码就行，不用管内存分配，不用管并发和互斥(其实还是要管的，就算万一有内存泄露的隐患，大不了每天重启JVM一下就能解决了。但对于一个可能在多个应用环境中部署的软件产品而言，内存泄露这种问题却绝不能放过。我曾经遇到过在一个环境中运行非常良好，但在另一个环境中却天天出问题的情况，即使每天重启JVM也无济于事。当时怀疑过很多方面，网络、数据库、容器等等。那时还不是很有概念，现在想起来还是后来好好看程序，优化了不少代码，解决了几个内存泄露，这样才最终解决了不稳定的问题。举例来讲，在应用环境A中，服务

器性能较好，JVM有2G内存，某个应用存在内存泄露的隐患，每次大约造成2M的内存消耗，这样1000次左右就没

有内存可用了，就会造成JVM性能大幅降低。但在应用环境B中，服务器就没那么好的性能了，JVM仅有256M，那么100多次操作就足以导致问题出现。而且，每个应用环境的应用使用率是不一样的，在A中如果每天仅出现10次隐患应用操作，2-3个月都不会暴露问题，而且即使使用内存分析工具，开始阶段也很难查出有无问题，但在B中，如果每天有100次隐患应用操作，只需一天问题就出现了。但实际应用过程中，应用的使用率往往很难精确统计的到，也无法预判，这也是造成问题排查困难的关键因素之一。应用环境的不确定性不单体现在地域上，也体现在时间上，不同时间的相同应用环境也不尽相同。挑选一个应用环境，常态性监测JVM的内存情况是避免这类问题发生的好办法。

结论就是，对于中高端的产品化，多用户，高并发应用，Java和C++一样，不考虑内存是不可能的，毕竟语言最终操纵的还是计算机。

那Java的优势在哪里？我认为其在中低端应用上的门槛更低。对大多数小型信息管理类系统而言，并不需要很严谨并且考虑周到的设计和编码，学习java可以让一个新手很快

上路，而C++却没有这种优势，动不动就越界是新手常犯的错误。在一个通常的软件团队里面，水平一定会有高低，而且也不是每个人都能通过学习进入深层次，这是C++难以解决的问题，Java在由于规范性方面的优势更加适合新手使用。

C++就像手动档汽车，Java更像自动档，尽管越来越多人愿意开自动档，可是要想真正跑得快，赛车还得手动挡的。

问题出现总会让人头疼,追根溯源常常也会非常艰苦和漫长,但只要还有办法,就不能放弃,规避问题可以解决阵痛,但永远无法治根。

2、关于云计算想到的 毫无疑问云计算的概念被扩大化了，云服务、云存贮，SAAS、IAAS、PAAS，理论和概念早已满天飞。但当我仔细读来，却发现大多还是新瓶装旧酒。虽然说还是有不少实质性内容，但与真正的分布式计算概念还是想去甚远。在网络越来越发达的时代背景下，存贮、软件、外设甚至内存都网络化了，唯一缺少的就是CPU，依靠网络使大量CPU协同工作真的是个很诱人的想法，但也是困难而遥远的事情。也有人认为Cloud Computing是个过度炒作的东西，我觉得有一定道理，如果要我选择，我也会希望把自己的东西放到自己的电脑上，我会更希望

在任何地方使用便携设备随时操纵我的电脑，却绝对不是放到一个看不见摸不到的“云端”上头，天天被“云端”盘剥和控制。因此，如果云端仅仅是服务或存贮的集中式管理，它是不值得如此进行炒作的。

其实

我觉得我不是一个重组概念进行炒作的反对者，炒作对于技术和社会进步是有一定作用的，但水可载舟、亦可覆舟，将一些本无关系的东西牵强附会的联系在一起进行炒作，只会搅乱理论和学术体系，而理论体系的混乱一定会导致交流上的障碍-----虽然交流变得更多（必然变得更多）更方便了，可是交流的障碍却大幅度增加了，同样的一个名词可以被一百个人给出一百个解释，本来一句话可以说清楚的事情，现在变成了几十句才能说明白。

药厂可以把10几块钱的药重新包装卖200-300块，利润当然是惊人的，可是赚到了钱的老板们却天天打算着转移资产到国外，认为国内没有可持续的发展。这样的人到底是高素质还是低素质呢？

我上大学的时候曾经在医院实习，见过一个食物中毒的病人家属连夜赶了几十里山路，把一堆借来的硬币交给医院做透析；后来工作了，搞图书馆的项目也知道很多地方的人连100块钱的借书证押金都捉襟见肘。那些天天生活在优越环境下的概念重组专家们会为这些人群考虑多少呢？“云端”的概念炒作显现了他们的垄断思想，现在中国的贫富差距基本还是在财产方面，信息方面基本还是对等的，这也是一个农村的孩子经过十几年苦干可以成为大企业家的前提所在。可是“云端”一来，你的一举一动都在我掌控和监视之下，没错，你是方便了，也少花钱了，可是却失去了信息方面的平等地位，于是，屁民将永远是屁民，永远没有咸鱼翻身的机会。

3、关于信息爆炸

10年来我也做了很多技术方面的工作了，最初几年看到一项新技术、新概念，肾上腺激素浓度就会大幅度增加，要是不用一下晚上恐怕觉都睡不着。可是后来慢慢地就变得理性多了，技术的选择一定要根据需求来，绝不能为用技术而用技术。很多的新技术、新概念，看几眼就差不多知道来源，也知道优点和缺点了。以前总以为环境得适应程序，后来明白了程序得适应环境。

大型的应用系统，越简单越好，如果做不到简单，宁可拆分为多个系统单独设计。否则，当我面对一大堆连自己都难以看懂的概念和代码，真会有抓狂的感觉。

CSDN是不错的技术社区了，但是依然缺乏体系组织和管理。论坛、知识库，Q&A，这些东西的模式差不多，虽然方便了信息交流，但缺乏信息的组织和管

理。比如我希望做一个信息系统，那应该选择什么样的技术？这个问题目前只能靠自己去摸索，慢慢体会，找到真正适合自己的技术方案。Wiki可能是更好的平台，但普及度不够。

其实每一个Questioner或者Answerer都在极力寻求相互之间的共同

语言，共同语言和语义的理论体系形成之后，交流才能顺畅。翻翻CSDN的帖子，不乏问东答西的案例。一个交流平台如果能形成一套语言和思维方式，那就是非常成功的了。而这也使得技术选型的模型成为可能，当你想采用一套新技术时，Google一下，各说各话，对的有，错的也有，搜索引擎为何判断不出已定论的东西谁对谁错呢，就是源于语义的复杂性。信息的膨胀速度远没有我们想象中那样快，其中相当一部分是语言语义产生的泡沫，挤掉这些泡沫呢？信息真的有统计数据显示的那么“海量”吗？

统计数据经常是面子工程强有力的支撑者，可扔掉这些浮华，细细究一下统计数据是怎么做出来的？常常就会让人哭笑不得，而且大多是7分真，3分假，或偷换概念，总之目的就是把一棵小草说成一座森林。信息是有欺骗性的，商业运作会大量运用这种特性，换来的除了肾上腺素之外还有人和人之间不信任的感觉。

信息爆炸的时代，交流的作用变成空前重要，但在交流越来越方便的同时，效率也越来越低了。也许几十年后，人类会不堪信息的重负，那时信息规范化和有序化才会真正站上历史的舞台。

第二篇：老程序员10年技术生涯的思考 从C++到Java

老程序员10年技术生涯的思考 从C++到Java 2011-04-20 08:17 蔡晖 蔡晖的博客 我要评论(20)字号：T | T

不知不觉,做程序工作已经10年了,从最初学习C++到Java,从困惑到清晰,感觉真的有不少东西可写,不过总觉得不成体系，大概看了太多八股文章的缘故，被憋得实在难受。所以不管了，想到什么写什么吧。AD：

1、从C++到Java

C++和Java谁快?从算法上讲我认为毫无疑问是汇编〉C++〉Java，不要迷信某些个别评测，单纯的回圈测试什么的，比如JNode的官方网站上有Java写的JVM的性能和SUN的JVM 进行性能比较的结果，JNode中用Java写的JVM竟然能比SUN公司用C++写的JVM还快!编译器完全可以作针对性优化影响测试结果，毫无意义的东西。而且，评测结果不会具备多少实际意义，真正的应用系统的效率是80%取决于整体的设计架构，而非你使用哪种语言。所以讨论汇编、C++、Java谁更快这个问题的人恐怕更多是为了自己的面子考虑，虽然Java当前如日中天，但其总是针对C++的批判性态度却再明显不过，所以Bruce才会有“C++不垃圾，只是Java很傲慢”之说。

C++和Java根本的区别是什么?我认为毫无疑问是内存分配。编程思想和设计模式是活的东西，和语言没有直接关系。Java没有指针，C++写程序也可以只用引用。JVM是Java在

内存管理上真正有别于C++的地方。JVM的好处是显而易见的，跨平台、更智能的内存管理，但能解决所有问题吗，答案是否定的。

Java没有内存泄露吗?当然不是，我认为java的内存泄露往往比C++更加难以排查，因为JVM的缘故，程序员没法直接对内存进行操控，隐患往往藏的更深。我曾经花了大量时间研究JVM的内存机制，虽然也有了不少心得，但直到现在仍然处于迷惑期。循环引用，缓存机制不合理，Spring等常态Bean的属性重复加载都是可能吃内存的元凶。

对于一个单一的，低用户低并发的系统，使用Java是很舒服的，程序员不用去考虑太多事情，照着业务逻辑做设计编代码就行，不用管内存分配，不用管并发和互斥(其实还是要管的)，就算万一有内存泄露的隐患，大不了每天重启JVM一下就能解决了。但对于一个可能在多个应用环境中部署的软件产品而言，内存泄露这种问题却绝不能放过。我曾经遇到过在一个环境中运行非常良好，但在另一个环境中却天天出问题的情况，即使每天重启JVM也无济于事。当时怀疑过很多方面，网络、数据库、容器等等。那时还不是很有概念，现在想起来还是后来好好看程序，优化了不少代码，解决了几个内存泄露，这样才最终解决了不稳定的问题。举例来讲，在应用环境A中，服务器性能较好，JVM有2G内存，某个应用存在内存泄露的隐患，每次大约造成2M的内存消耗，这样1000次左右就没有内存可用了，就会造成JVM性能大幅降低。但在应用环境B中，服务器就没那么好的性能了，JVM仅有256M，那么100多次操作就足以导致问题出现。而且，每个应用环境的应用使用率是不一样的，在A中如果每天仅出现10次隐患应用操作，2-3个月都不会暴露问题，而且即使使用内存分析工具，开始阶段也很难查出有无问题，但在B中，如果每天有100次隐患应用操作，只需一天问题就出现了。但实际应用过程中，应用的使用率往往很难精确统计的到，也无法预判，这也是造成问题排查困难的关键因素之一。应用环境的不确定性不单体现在地域上，也体现在时间上，不同时间的相同应用环境也不尽相同。挑选一个应用环境，常态性监测JVM的内存情况是避免这类问题发生的好办法。

结论就是，对于中高端的产品化，多用户，高并发应用，Java和C++一样，不考虑内存是不可能的，毕竟语言最终操纵的还是计算机。

那Java的优势在哪里?我认为其在中低端应用上的门槛更低。对大多数小型信息管理类系统而言，并不需要很严谨并且考虑周到的设计和编码，学习java可以让一个新手很快

上路，而C++却没有这种优势，动不动就越界是新手常犯的错误。在一个通常的软件团队里面，水平一定会有高低，而且也不是每个人都能通过学习进入深层次，这是C++难以解决的问题，Java在由于规范性方面的优势更加适合新手使用。

C++就像手动档汽车，Java更像自动档，尽管越来越多人愿意开自动档，可是要想真正跑得快，赛车还得手动挡的。

问题出现总会让人头疼,追根溯源常常也会非常艰苦和漫长,但只要还有办法,就不能放弃,规避问题可以解决阵痛,但永远无法治根。

2、关于云计算想到的

毫无疑问云计算的概念被扩大化了，云服务、云存贮，SAAS、IAAS、PAAS，理论和概念早已满天飞。但当我仔细读来，却发现大多还是新瓶装旧酒。虽然说还是有不少实质性内容，但与真正的分布式计算概念还是想去甚远。在网络越来越发达的时代背景下，存贮、软件、外设甚至内存都网络化了，唯一缺少的就是CPU，依靠网络使大量CPU协同工作真的是个很诱人的想法，但也是困难而遥远的事情。也有人认为Cloud Computing是个过度炒作的东西，我觉得有一定道理，如果要我选择，我也会希望把自己的东西放到自己的电脑上，我会更希望在任何地方使用便携设备随时操纵我的电脑，却绝对不是放到一个看不见摸不到的“云端”上头，天天被“云端”盘剥和控制。因此，如果云端仅仅是服务或存贮的集中式管理，它是不值得如此进行炒作的。

其实我觉得我不是一个重组概念进行炒作的反对者，炒作对于技术和社会进步是有一定作用的，但水可载舟、亦可覆舟，将一些本无关系的东西牵强附会的联系在一起进行炒作，只会搅乱理论和学术体系，而理论体系的混乱一定会导致交流上的障碍-----虽然交流变得更多(必然变得更多)更方便了，可是交流的障碍却大幅度增加了，同样的一个名词可以被一百个人给出一百个解释，本来一句话可以说清楚的事情，现在变成了几十句才能说明白。

药厂可以把10几块钱的药重新包装卖200-300块，利润当然是惊人的，可是赚到了钱的老板们却天天打算着转移资产到国外，认为国内没有可持续的发展。这样的人到底是高素质还是低素质呢? 我上大学的时候曾经在医院实习，见过一个食物中毒的病人家属连夜赶了几十里山路，把一堆借来的硬币交给医院做透析;后来工作了，搞图书馆的项目也知道很多地方的人连100块钱的借书证押金都捉襟见肘。那些天天生活在优越环境下的概念重组专家们会为这些人群考虑多少呢?“云端”的概念炒作显现了他们的垄断思想，现在中国的贫富差距基本还是在财产方面，信息方面基本还是对等的，这也是一个农村的孩子经过十几年苦干可以成为大企业家的前提所在。可是“云端”一来，你的一举一动都在我掌控和监视之下，没错，你是方便了，也少花钱了，可是却失去了信息方面的平等地位，于是，屁民将永远是屁民，永远没有咸鱼翻身的机会。

3、关于信息爆炸

10年来我也做了很多技术方面的工作了，最初几年看到一项新技术、新概念，肾上腺激素浓度就会大幅度增加，要是不用一下晚上恐怕觉都睡不着。可是后来慢慢地就变得理性多了，技术的选择一定要根据需求来，绝不能为用技术而用技术。很多的新技术、新概念，看几眼就差不多知道来源，也知道优点和缺点了。以前总以为环境得适应程序，后来明白了程序得适应环境。

大型的应用系统，越简单越好，如果做不到简单，宁可拆分为多个系统单独设计。否则，当我面对一大堆连自己都难以看懂的概念和代码，真会有抓狂的感觉。

一些社区虽然是不错的技术社区，但是依然缺乏体系组织和管理。论坛、知识库，Q&A，这些东西的模式差不多，虽然方便了信息交流，但缺乏信息的组织和管理。比如我希望做一个信息系统，那应该选择什么样的技术?这个问题目前只能靠自己去摸索，慢慢体会，找到真正适合自己的技术方案。Wiki可能是更好的平台，但普及度不够。

其实每一个Questioner或者Answerer都在极力寻求相互之间的共同语言，共同语言和语义的理论体系形成之后，交流才能顺畅。翻翻帖子，不乏问东答西的案例。一个交流平台如果能形成一套语言和思维方式，那就是非常成功的了。而这也使得技术选型的模型成为可能，当你想采用一套新技术时，Google一下，各说各话，对的有，错的也有，搜索引擎为何判断不出已定论的东西谁对谁错呢，就是源于语义的复杂性。信息的膨胀速度远没有我们想象中那样快，其中相当一部分是语言语义产生的泡沫，挤掉这些泡沫呢?信息真的有统计数据显示的那么“海量”吗? 统计数据经常是面子工程强有力的支撑者，可扔掉这些浮华，细细究一下统计数据是怎么做出来的?常常就会让人哭笑不得，而且大多是7分真，3分假，或偷换概念，总之目的就是把一棵小草说成一座森林。信息是有欺骗性的，商业运作会大量运用这种特性，换来的除了肾上腺素之外还有人和人之间不信任的感觉。信息爆炸的时代，交流的作用变成空前重要，但在交流越来越方便的同时，效率也越来越低了。也许几十年后，人类会不堪信息的重负，那时信息规范化和有序化才会真正站上历史的舞台。

第三篇：Java从入门到精通读书笔记—c++程序员学java

Java从入门到精通读书笔记—c++程序员学java

第一章：

2分钟看完，老生常谈，即使没怎么用过java也知道这些。

第二章：

1.instanceof应该是c++中没有的，c++使用RTTI解决这个问题的，很难用。

2.super这种引用父类的方法也是比较简单的，C++中是用父类名::父类方法()解决的，有点难看。

3.自动类型转换和C++一样，精度变高的随便转，精度变低的会丢失。

4.强制类型转换只有(type)这一种，不像c++有static_cast、dynamic_cast、reinterpret_cast、和const_cast。

5.运算符什么的和c++几乎一模一样。

半小时看完。

第三章：

1.break可以跳出语句块，c++中没有语句块。语句块的定义就是在一段语句前加上花括号和冒号；

其他基本上和c++一样，5分钟看完。

第四章：

1.java数组越界会在运行时抛异常，c++不会，声明数组的方法也有些不一致。

java 声明数组的所有办法

int[] a = new int[4];

int a[] = new int[4];

int[] a = {1, 15, 26};

int a[] = {1, 15, 26};

2.java的数组是一个对象，自带length属性，使用简单。c++的数组不自带方法和属性，要知道数组长度只能sizeof(arrayObject)/sizeof(int)。当然如果使用STL中的vector之类的也和java一样简单。

3.java的所谓数组赋值（或者叫数组拷贝）其实就是c++中的两个数组指针的赋值，java没有指针，所以作者费了一大堆口水。好在java有垃圾回收，要不然一个指针的内存就算泄露了。至于真正的数组内容赋值，是使用System.arraycopy(ir, srcPos, ir, destPos, length);而C++一般使用memcpy等函数。若使用STL中的vector，那么就看vector的拷贝构造函数怎么写的，应该是vector的对象赋值过去而不是指针指过去。

4.重温了冒泡排序（时间复杂度O(n2)），和快速排序（最坏情况的时间复杂度为O(n2)，最好情况时间复杂度为O(nlog2n)）。

5.For-Each语法被引入java了，在很多地方用起来真是简单。Python和c#早就支持了，c++中虽然STL的algorithm包中引入了for_each，但是由于需要使用函数指针还是略显繁琐。

这章挺多，看了一个多小时啊！

第五章：类和对象

1.Java中方法的重载和c++的一样，都是通过参数的不同来区别。但是c++中可以设置默认参数，而java不可以。

2.java中的对象大部分只能new出来，或者clone出来，或者反射出来，而不能直接在栈上定义出来。而c++的对象在栈上和堆上创建的都很多。

3.基本类型的参数传递，java和c++都是传值。对象的参数传递，java是传引用，c++是拷贝，也就是传值。其实c++中大部分时候也是传引用或者传指针，但java没有指针，也没有选择耗时耗空间的拷贝，只能传引用了。

这章对于c++程序员来说太简单，几分钟过一遍就可以了。

第六章：继承

1.方法被覆写后，如果要调用父类的方法，c++必须用父类名：：方法名，而java用super.方法名即可。

2.多态和动态绑定，java和c++几乎一样，都很简单。

3.final关键字：java中的final关键字可以将一个类限制为无法继承的，同样的还有C#中的sealed关键字。而c++是没有这个玩意的。

4.java的抽象类和c++几乎一样。

5.java是独根语言，引入了Object类，它的clone方法就好像c++中的拷贝构造函数，它的equals方法是用来比较内容的，而toString方法是将对象作为字符串输出的。

这章对于c++程序员来说同样简单，几分钟过一遍就可以了。

第七章：接口

1.java中有接口。C++没有，唯一类似的是含有纯虚函数的虚类（没有纯虚基类这个说法）。但是COM、CORBA等中间件中都有IDL语言（接口定义语言），使用这些中间件的c++程序员也没有少写接口。

2.接口实现的一些规定：

1）如果实现接口的不是抽象类，则必须实现其接口的所有方法才能被实例化；

2）接口中所有的方法默认为public；

3.接口可以用来实现多态；

4.java的内部类和c++差不多，都没人关心，最多懒得想名字的时候用用那个匿名内部类（例如什么UI的响应函数）。

5.java的对象克隆，吹了一堆就是个c++中的拷贝构造函数。所谓什么“浅克隆、深克隆”问题，就是c++中拷贝构造是遇上类中定义了指针的问题。C++程序员一望即知。

接口是为了维护单继承机制弄出来的，花半小时看看还是值得的。

第八章：面向对象编程

C++程序员不用看。

第九章：异常处理

1.java的异常处理中有finally语句块，而c++中没有，所以程序员要自己想办法来处理异常发生后诸如“资源释放”之类的问题；

第十章：线程

1.java语言自带线程机制，c++目前还是不带线程机制的。虽然boost::thread库也被众多c++程序员广泛使用。但是windows下用得最多的还是windows SDK自带的线程函数；而linux下用得最多的还是pthread。另外还有一些号称同时支持多个平台的多线程库。

2.java多线程有两种方法实现，第一是派生Thread类，第二种是实现Runnable接口。

3.java线程分为4种状态：new、runnable、non runnable和done，这和其他线程库大同小异；

4.run、start、stop、sleep、suspend、resume、yield、wait、notify和notifyall等方法的含义也和其他线程库一致。但suspend、resume和stop等方法是不建议使用的，因为可能会导致死锁。

5.java可使用join方法来等待线程结束，而在某些线程库中join方法经常是不可用的。

6.java的互斥使用synchonized关键字实现，它很类似于boost.thread中的lock(mutex)，只不过它是对线程对象隐含的锁加锁。其实这很不利于新手理解。另外还介绍了synchonized的一些乱七八糟的用法，相信对于新手这只有反作用。

这一章对于线程，介绍得比较浅显，实现简单的多线程应该没问题，但是稍微复杂一点的也许就需要其他的开发包了。Java线程连个Mutex类都没有，这是最让我吃惊的，仅仅使用synchonized来实现同步、互斥、信号量该多麻烦啊，也许是我还没弄懂java多线程吧。

第十一章：图形编程

1.IDE的年代，GUI还是画出来吧。Java中也就Layout类需要看看，其他大部分Layout类也是凑数的，根本不会有人用。

第十二章：事件处理

随便看看了解即可，新手可以试着写写代码，老手直接IDE中添加事件即可。

第十三章：Swing用户界面设计

同第十一章，随便看看即可。界面一般有专人搞，普通程序员能看懂就行了。

总结：《java从入门到精通》这本书整体质量尚可，c++熟手大概一到两天可以看完，掌握程度在80%左右。看完后能够有一些基本概念，可以写一些基本程序。看完后离入门还早，更谈不上精通了。

说说我看完后的两个迷惑之处吧，第一是从来没有提到java中的对象、常量、代码所在的堆、栈等内存分布情况，对于c++程序员来说是很难适应的，可能是篇幅的原因吧；第二没有介绍垃圾回收机制，这可能是c++程序员更感兴趣的吧。

第四篇：java程序员到架构师之路

作为Java程序员来说，最痛苦的事情莫过于可以选择的范围太广，可以读的书太多，往往容易无所适从。我想就我自己读过的技术书籍中挑选出来一些，按照学习的先后顺序，推荐给大家，特别是那些想不断提高自己技术水平的Java程序员们。

一、Java编程入门类

对于没有Java编程经验的程序员要入门，随便读什么入门书籍都一样，这个阶段需要你快速的掌握Java基础语法和基本用法，宗旨就是“囫囵吞枣不求甚解”，先对Java熟悉起来再说。用很短的时间快速过一遍Java语法，连懵带猜多写写代码，要“知其然”。

1、《Java编程思想》

在有了一定的Java编程经验之后，你需要“知其所以然”了。这个时候《Java编程思想》是一本让你知其所以然的好书，它对于基本的面向对象知识有比较清楚的交待，对Java基本语法，基本类库有比较清楚的讲解，可以帮你打一个良好的Java编程基础。这本书的缺点是实在太厚，也比较罗嗦，不适合现代人快节奏学习，因此看这本书要懂得取舍，不是每章每节都值得一看的，挑重点的深入看就可以了。

2、《Agile Java》中文版

这本书是出版社送给我的，我一拿到就束之高阁，放在书柜一页都没有翻过，但是前两天整理书柜的时候，拿出来一翻，竟然发现这绝对是一本好书！这本书一大特点是以单元测试和TDD来贯穿全书的，在教你Java各种重要的基础知识的过程中，潜移默化的影响你的编程思维走向敏捷，走向TDD。另外这本书成书很新，以JDK5.0的语法为基础讲解，要学习JDK5.0的新语法也不错。还有这本书对于内容取舍也非常得当，Java语言毕竟类库庞大，可以讲的内容太多，这本书选择的内容以及内容的多寡都很得当，可以让你以最少的时间掌握Java最重要的知识，顺便培养出来优秀的编程思路，真是一本不可多得的好书。

虽然作者自己把这本书定位在入门级别，但我不确定这本书用来入门是不是稍微深了点，我自己也准备有空的时候翻翻这本书，学习学习。

二、Java编程进阶类

打下一个良好的Java基础，还需要更多的实践经验积累，我想没有什么捷径。有两本书值得你在编程生涯的这个阶段阅读，培养良好的编程习惯，提高你的代码质量。

1、《重构 改善既有代码的设计》

这本书名气很大，不用多介绍，可以在闲暇的时候多翻翻，多和自己的实践相互印证。这本书对你产生影响是潜移默化的。

2、《测试驱动开发 by Example》

本书最大特点是很薄，看起来没有什么负担。你可以找一个周末的下午，一边看，一边照做，一个下午就把书看完，这本书的所有例子跑完了。这本书的作用是通过实战让你培养TDD的思路。

三、Java架构师之路

到这个阶段，你应该已经非常娴熟的运用Java编程，而且有了一个良好的编程思路和习惯了，但是你可能还缺乏对应用软件整体架构的把握，现在就是你迈向架构师的第一步。

1、《Expert One-on-One J2EE Design and Development》

这本书是Rod Johnson的成名著作，非常经典，从这本书中的代码诞生了springframework。但是好像这本书没有中译本。

2、《Expert One-on-One J2EE Development without EJB》

这本书由gigix组织翻译，多位业界专家参与，虽然署名译者是JavaEye，其实JavaEye出力不多，实在是忝居译者之名。

以上两本书都是Rod Johnson的经典名著，Java架构师的必读书籍。在我所推荐的这些书籍当中，是我看过的最仔细，最认真的书，我当时读这本书几乎是废寝忘食的一气读完的，有小时候挑灯夜读金庸武侠小说的劲头，书中所讲内容和自己的经验知识一一印证，又被无比精辟的总结出来，读完这本书以后，我有种被打通经脉，功力爆增的感觉。

但是后来我看过一些其他人的评价，似乎阅读体验并没有我那么high，也许是因为每个人的知识积累和经验不同导致的。我那个时候刚好是经验知识积累已经足够丰富，但是还没有系统的整理成型，让这本书一梳理，立刻形成完整的知识体系了。

3、《企业应用架构模式》

Martin的又一本名著，但这本书我只是泛泛的看了一遍，并没有仔细看。这本书似乎更适合做框架的人去看，例如如果你打算自己写一个ORM的话，这本书是一定要看的。但是做应用的人，不看貌似也无所谓，但是如果有空，我还是推荐认真看看，会让你知道框架为什么要这样设计，这样你的层次可以晋升到框架设计者的角度去思考问题。Martin的书我向来都是推崇，但是从来都没有像Rod Johnson的书那样非常认真去看。

4、《敏捷软件开发原则、模式与实践》

Uncle Bob的名著，敏捷的经典名著，这本书比较特别，与其说是讲软件开发过程的书，不如说讲软件架构的书，本书用了很大篇幅讲各种面向对象软件开发的各种模式，个人以为看了这本书，就不必看GoF的《设计模式》了。

四、软件开发过程

了解软件开发过程不单纯是提高程序员个人的良好编程习惯，也是增强团队协作的基础。

1、《UML精粹》

UML其实和软件开发过程没有什么必然联系，却是软件团队协作沟通，撰写软件文档需要的工具。但是UML真正实用的图不多，看看这本书已经足够了，完全没有必要去啃《UML用户指南》之类的东西。要提醒大家的是，这本书的中译本翻译的非常之烂，建议有条件的看英文原版。

2、《解析极限编程 拥抱变化》XP

这是Kent Beck名著的第二版，中英文对照。没什么好说的，必读书籍。

3、《统一软件开发过程》UP

其实UP和敏捷并不一定冲突，UP也非常强调迭代，测试，但是UP强调的文档和过程驱动却是敏捷所不取的。不管怎么说，UP值得你去读，毕竟在中国真正接受敏捷的企业很少，你还是需要用UP来武装一下自己的，哪怕是披着UP的XP。

4、《敏捷建模》AM

Scott Ambler的名著，这本书非常的progmatic，告诉你怎么既敏捷又UP，把敏捷和UP统一起来了，又提出了很多progmatic的建议和做法。你可以把《解析极限编程拥抱变化》、《统一软件开发过程》和《敏捷建模》这三本书放在一起读，看XP和UP的不同点，再看AM是怎么统一XP和UP的，把这三种理论融为一炉，形成自己的理论体系，那么你也可以去写书了。

五、软件项目管理

如果你突然被领导提拔为项目经理，而你完全没有项目管理经验，你肯定会心里没底；如果你觉得自己管理项目不善，很想改善你的项目管理能力，那么去考PMP肯定是远水不解近渴的。

1、《快速软件开发》

这也是一本名著。可以这样说，有本书在手，你就有了一个项目管理的高级参谋给你出谋划策，再也不必担心自己不能胜任的问题了。这本书不是讲管理的理论的，在实际的项目管理中，讲这些理论是不解决问题的，这本书有点类似于“软件项目点子大全”之类的东西，列举了种种软件项目当中面临的各种问题，以及应该如何解决问题的点子，你只需要稍加变通，找方抓药就行了。

六、总结

在这份推荐阅读书籍的名单中，我没有列举流行的软件框架类学习书籍，例如Struts，Hibernate，Spring之类，也没有列举AJAX方面的书籍。是因为这类书籍容易过时，而上述的大半书籍的生命周期都足够长，值得你去购买和收藏。

第五篇：从程序员到技术总监,分享10年开发经验

在中国有很多人都认为IT行为是吃青春饭的，如果过了30岁就很难有机会再发展下去!其实现实并不是这样子的，在下从事.NET及JAVA方面的开发的也有10年的时间了，在这里在下想凭借自己的亲身经历，与大家一起探讨一下。

明确入行的目的

很多人干IT这一行都冲着“收入高”这一点的，因为只要学会一点HTML, DIV+CSS，要做一个页面开发人员并不是一件难事，而且做一个页面开发人员更容易找到工作，收入比普通的工作还要高一些，所以成为了很多高校毕业生的选择。如果您只是抱着这样一个心态来入行的话，那阁下可真的要小心了。因为干IT这一行竞争本来就比较激烈，特别是页面设计这方面，能够开发的人很多，所以为了节省成本，大部分公司都会在需要的时候才招聘这类人员;在没有订单的时候，一些小公司还可能找各类的借口或者以降薪的手段去开除这类员工。而在招聘信息上常常会看到“招聘页面设计师，条件：30岁以下„„欢迎应届毕业生前来应聘”这样一条，因为这一类工员对技术上的要求并不高，找应届生可以节约成本。所以在下觉得“IT行业是吃青春饭的”这句话只是对着以上这类人所说的，如果阁下缺乏“进取之心”，而只抱着“收入高，容易找工作”这样的态度而入行，那“IT行业是吃青春饭”将会应验了。

选择合适的工具

JAVA、C#、PHP、C++、VB„„10多种热门的开发语言，哪一种最有发展潜力呢?其实开发语言只不过是一个工具，“与其分散进攻，不如全力一击”，无论是哪一种开发语言，只要您全力地去学习，到有了一定的熟悉程度的时候，要学习另一种的语言也是轻而易举的事情。开发语言主要分为三大类：

1.网络开发

现在网络已经成为世界通讯的一座桥梁，好像Javascript、PHP、Ruby这几类开发语言大部分是用作网络开发方面。

2.企业软件开发

JAVA、C#、VB这几类开发语言都实现了面向对象开发的目标，更多时候用于企业系统的开发。

3.系统软件

C语言、C++、Objective-C这些软件更多是用在系统软件开发，嵌入式开发的方面。

当然，这分类不是绝对，像JAVA、C#、VB很多时候也用于动态网站的开发。在很开发项目都会使用集成开发的方式，同一个项目里面使用多种开发语言，各展所长，同步开发。但所以在刚入门的时候，建议您先为自己选择一种合适的开发工具，“专注地投入学习，全力一击”。

明确发展方向

当您对某种开发语言已经有了一定的了解，开始觉得自己如同“行尸走肉”，成为一个开发工具的时候，那您就应该要明确一下自己的发展方向了。

平常在公司，您可以看到做UI层的开发人员大多数都有20多岁，他们充满干劲，而且没有家庭负担，在两年前ASP.NET MVC、Silverlight等刚出现的时候，他们可以在晚上回家的时候买几本书或者直接上网看看，研究三五个星期以后，对需要用到的技术就已经有一定的了解了。而年过30的人多数是已经成家了，他们每天9：00点上班唯一的希望就是快些到6：00点，能回家吃饭。吃完饭只想陪孩子玩一下，看看孩子的功课，对新增的技术缺乏了学习的欲望。所以很多接近30岁的程序员都有着一种逼迫感(包括30岁时候的我自己)，再过几年应该怎么办?这时候，您就更应该明确一下目标，努力向自己的发展方向前进了。归纳一下，可从下面几项里选择适合自己的一条道路：

1.从技术向业务过渡

在国外，很多发达国家都很重视人才，一个高级的程序员与一个Project Manager收入相差一般不超过15%。但中国是世界上人口最多的国家，国内人才众多，所以人才滥用的情况经常可以看到。一个小公司的开发部里面经常会见到新面孔，但PM却不会常换。因为做老板的对技术是一窍不通，依他们看来只到拉住PM的心，那技术方面方面就能搞得定，至于技术部要换人，他们根本不需要费力气去管。所以从一个技术员过渡到一个PM是向前发展的一个选择，但开发人员也需要知道，要成为一个PM不单单是使用技术，而更重要的是对管理方面的认识。一个PM主要的工作是组织团队，控制成本，管理业务，控制项目进度，与客户进行沟通，协调工作，定期进行工作报告等。所以要成为一个成功的PM更要重视组织能力，PM必须能提高团队的积极性，发挥团队所长，在有限的开发资源前提下为公司得到最大程度上的利润。成为一个PM后，通常不需要直接接触技术开发，而着重管理的是业务发展，但PM对技术也需要有一定的了解(在下曾经为PM对技术了解的必要性写过一篇文章，得到很多支持但也惹来不少的争议)。在这里我还是要强调自己的观点：要成为一个成功的PM最重视的是管理能力，但对技术也应该有足够的了解，因为这是与团队成员沟通的桥梁，只有这样才能与整个团队的成员有着紧密的结合，让团队成员感觉到他们自己存在的意义，从而调动团队的积极性，而不是漠视技术人员的存在。技术并非成为一个成功PM的充分条件但却是必要条件!

2.从程序员向技术管理发展

其实一个Team Leader的职责与Project Manager相像，但Team Leader更着重于技术开发方面，通常一个大型项目都会有一两个开发团队由Team Leader带领，负责开发核心部分，而其它部分分派给不同开发小组或者分派给外包公司。在网上常看到几句话，贴切地形容了PM与TL的区别：“技术人员乐于被领导;但他们不喜欢被管理，不喜欢像牛一样被驱赶或指挥。管理者强迫人们服从他们的命令，而领导者则会带领他们一起工作。管理是客观的，没有个人感情因素，它假定被管理者没有思想和感受，被告知要做什么和该如何做。领导是引领、引导，它激励人们达成目标。领导力是带有强烈个人感情色彩的，它不是你能命令的，也不是你能测量评估和测试的。”

无论是PM与TL，对业务与技术都要有深入的了解，只是PM更侧重于业务的管理，盈利的多少，风险的大小等等，而TL则侧重于项目的成本，开发的难度，软件的架构等技术方面的问题。在某些人眼中，技术与管理就像鱼与熊掌，不可兼得，但依在下看来，两者却是秤不离砣，密不可分。只要及时提升自己对技术与管理的认识，不断地向深一层发展，要从程序员提升到技术管理人员只是时间的问题。打个比方，一个普通的.NET程序员，开始可能限制于ASP.NET的页面开发，但一旦他有了发展之心，他自然会对ASP.NET MVC、Silverlight、WinForm、WPF这些UI的开发手法感到兴趣，学习不需要多少时间，他可能就会认识这些UI开发只不过是一些工具，其实在开发原理上没什么区别。接着他就会向深一层的通讯模式进行了解，认识TCP/IP、Web Service、WCF、Remoting这些常用到的通讯方式，这时候他可能已经感觉到自己对开发技术有了进一步的了解。进而向工作流、设计模式、面向对象设计、领域驱动设计、面向服务开发等高层次进发，最后成为技术的领导者。上面只是一个比喻，但要注意的是，在学习的时期必须注意的是与同事之间沟通，很多的开发人员喜欢独来独往，开发的项目总想一个人搞定，不受外界的干扰。但要明白，就算你有天大的本事，一项大型的项目也不可能由你一个人全扛着。所以团队的合作性与同事间的沟通是必要的，这也是成功一个TL的必要条件。

3.单方面向技术发展

能成功进行技术开发的尖端人才，这是在下最向往的工作，却也没本事登上这个位置。很多从事开发的人都会认为，业务总会带着“金钱的味道”，老板从来不管开发是否合符开发原则，是否经过必要测试，他们只会在客户面前无尽地吹嘘，项目到期能成功交货，只要不出什么大问题那这个项目就算成功了。其实我们也要明白：开发项目最终目标是为了赚钱，在开发过程中对项目成本的限制和效率的控制这也是必须，所以这才需要管理人员对项目进行管理。但开发人员也很想避开这“金钱的尘嚣”，全心投入到技术的世界当中。所以对技术有着浓厚兴趣的人，往往会深入地研究某一项技术，成为技术上的精英。但在这里说一句令人心淡的话：中国已经属于是世界上第二大经济体同盟国，但国民生产总值主要来源于第三方加工产业方面。中国可以说是人才济济，但却在高新产业上却比发达国家落后。这几年的确看到我们国家在高新科技上有着质的飞跃，但跟欧美发达国家还有着一段距离。所以想在中国成为尖端技术的人才，无可否定比在国外要难。依在下看来，要想成为尖端的开发者，必须对C、C++、汇编语言、嵌入式开发、Windows API、Linux API这些底层技术有着深入的了解。要知道解JAVA、.NET„„等这些之所以称为高级开发语言，并不是指它们比C、C++、汇编语言更高级，而是指它们封装了C、C++等等的功能，更适合用于企业软件的开发，使开发变得简单。但如果要开发一些底层的软件，大型的系统的时候，就必须用到C、C++、汇编等开发语言，这是成功尖端人才的一个条件。

确定未来的目标

人是从历练中成长的，古人云：三十而立，形容的不是一个人的社会地位，经济来源，而是形容一个人对未来的目标，对人生的意向。要成为一个成功人，就应该早日为自己定下长期的发展目标，作为一个开发者也当如此。随着人的性格，取向各有不同，大家为自己所选择的路也有不同：

1.自立门户，勇敢创业

快30岁了，很多人会认为要想真正赚得了钱，就应该自立门户，为自己创业建立一个基础。像北京、上海、广州这些一级城市，要买房子，一手楼基本要在2万~4万元/平方米左右，而在一家普通的IT公司当上一个项目经理，基本收入一般都在1.5万~3万之间(除非在大型的跨国企业内工作，那另当别论)，要买一间100平方米左右的房子，就算不吃不喝也几乎要10年的年薪，所以选择自主创业，是很多IT开发人员的一个未来目标，想要达到这个目标，就应该更多地把业务作为重点。不可否认的一件事，在中国社会里很多时候讲的是“关系”，即使这30年的改革开放使中国的经济蓬勃地发展起来，但几千年来留下的歪风还是不能完全的磨灭。所以想要创业的人事建议你要多跟客户打好关系，与合作伙伴保持互利互动的模式，这将有利于日后事业的发展。

2.急流勇退，退居二线

这也是不少人的选择。很多人在有了家庭以后，感觉到压力太大，人的一生并非只有事业，他们想把更多时间用于对亲人的照顾，对孩子的关心上。所以很多人会选择一份像系统分析、系统维护、高校教师、专业学院讲师这一类的工作。收入稳定，而且往往没有一线开发人员那么大的压力。

3.不懈努力，更进一步

无论你是一个Project Manager或者是Team Leader，如果你想继续晋升一级，那还是会两极分化的。从一个PM到一间公司的管理层，那所面对的事件会有很多变化。一个公司的总经理，要管理的不再是一到两个项目的成本，而是整个部门的运作，整间公司的业务流程，所以要肩负的任务会更重。在下曾经有一位上司彭博士，他是企业的最高领导人，年薪超过三百万，而且在报纸杂志上也曾经亮过相。平常只会在某些会议上轻轻地亮下相，说两句讲词，平常的公司运作与业务管理都不需要他直接执行。这并不是说一个作为管理层很清闲，因为他们要面对的是更多的社会关系，与公司合作企业的联系上。这跟一个PM的工作有很大的区别，所以要从一个PM晋升到管理层，那可是要付出更多的努力与汗水。

如果要从Team Leader上升为一个技术总监，那工作的方向也有所改变。像之前所说：一个TL可能更重视的是技术层面，讲求与团队之间的互动合作性，更注重的是开发的完善。而一个技术总监就无需要直接参加某个项目的开发，而注意的是开发的效率与成果，如何合理使用有限的开发资源，控制开发的风险和可能带来的效果。

发展感受

经历了8年多时间，在下从一个程序员到一个项目经理，之间经过很多的曲折，但因为每一个人的际遇都有所不同，所走的路也有不同，正所谓条条大路通罗马，成功的路不止一条，在下也不想令各位误解，而只想为大家说一下我的发展方向。如果您是一位开发人员，“程序员->架构师->Team Leader(Project Manager)->技术总监”是一条不错路，这也是在下选择的路。在我国，想要进一步提升自己，无论你想是以技术为重点还是以业务为重点，都离不开管理二字。在一些大型的企业，一个团队往往会配备一个PM与一个架构师，尽管两个人负责的任务各有不同，但你会看到一个架构师的收入往往不如一个PM，PM往往是这个团队的核心领导者，是关键人物。因为公司能否赚钱，PM有着重要的作用。PM与TL并没有绝对的区别，而且在一些中小型企业，一个开发团队只有3~5人，一个TL往往会兼备业务处理、成本控件、架构设计、开发管理等多项任务。所以在下会把Team Leader与Project Manager定于同一层次，一个公司的老板往往不会知道团队的架构师、程序员是何人，而只会向PM询问项目的进度，所以只有晋升到这个层次，才有机会进一步提升管理能力，让自己有上升的空间。至于要成为一个技术总监，那要求就不再单单是对单个项目的管理，而应该更则重于新兴技术的引用，开发资源的合理利用，对开发项目敏捷性的处理等等，对此在下也在试探当中，未敢多言。

与编程牵手 和代码共眠 从程序员到技术总监

从业IT十年,从程序员成为技术总监,现在回头看一看,这条路也伴随国内的IT一起风雨兼程10年,对IT技术由其是IT的纯软件开发这一块,向即将要从事软件技术研发的朋友谈一谈我的看法:

一.认清当前IT形势,选择合适的技术方向和技术起点

估计大家都多多少少知道,这个IT行业知识的更新很快,竞争很急烈.如果你对自己以后发展的方向在从业前有一个清析的计划或认识,相信你会比别人走得更好,走得更远,赚的钱也更多...呵呵

IT软件从业的方向,一般都会有这些机会:产品售前(市场,业务),产品开发(编码,设计,测试),产品售后(支持,实施),产品管理(项目管理等)

A.产品售前(市场,业务)

要从事这一块的工作,主要是在软件开发的前期(无产品),或者合同签订前期(有产品).一般要求对相关的业务和技术都要求很高,这可不仅仅是要求人际关系,交际能力.要想别人买你的产品,你得以专业的产品品质为后台,以专业的谈吐,专业的技术和专业的业务理解能力来取胜.从业者要求:

要求从业者要有一定的社会经验,技术经验或业务经历,或一定的社会圈子和交际能力.建议:

刚刚从学校毕业的朋友或不符合上面条件的朋友最好要考虑清楚了.当然这世上没有什么绝对的东西,就看你自己了.现实情况:

据我所了解的,作这一块的都会是公司一些高层(有关系,有经验)和业务专家或特殊背景的人员等.B.产品开发(编码,设计,测试)

这一块的工作,当然是IT从业大军的主力了,但也得要考虑清楚.如果你要作设计师,或测试,最好先作一段时间的编码, 一个好的设计师是不可能不精通相关技术平台的!

国外好的测试人员也几乎是从开发人员中选出来的,基至是软件开发高手.a.代码编写

在这一个职业选择范围内最好是从代码编写开始.当然你也可以先作测试,看看人家是怎么写代码的是如何来作这个软件的，借用人家的测试经验也可以,以后有机会再来编一段时间的代码也行.有时自己去写一个软件也可以,所以作编码和测试都是一个双向交互的.而不是编码在前测试在后的.作代码的编写最好自己先看看别人的软件,或由一些高手带着指导一下,现在技术的学习都不成问题,关健是要连成一条线来学习和思考就会有一定的局限了.所以要熟悉整个的项目流程或业务流程不是靠个人编码或在培训班学一下就能解决的,个人的技术学习和培训班大部分只能解决技术的学习问题,但作软件不仅是要技术呀

三分技术七分业务说得不为过,业务的学习也是一个开发人员所要必备的,如果你在不熟悉业务细节之前建议你不要急着去写代码,那样肯定会是对以后软件的影响很大.先要熟悉一下业务.所以软件开发人员掌握一门技术平台和语言是必备条件但同时也必须要有一定的业务知识,这样才是一个合格的软件开发人员.当然精通软件编码,懂设计,熟悉业务,熟悉软件项目开发流程的软件开发人员是优秀的,那是高级研发人员的必备条件.如果你才入门或转行或刚毕业,建议从基础的代码编写开始,跟着高手或找一些成熟的项目多学习, b.软件设计

当然这个职业要求行业的经验,技术经验都要有一定的基础,薪水一般也会高很多,所以也是一些开发人员热烈追逐的目标.但一个好的设计师不是一二年所能练就的,精通编码,熟练设计模式和公司所采用的技术平台,熟练一些设计理论并实际多运用,熟练公司业务,其实这个层面的压力也最大,一个好的软件在设计上的比重几乎要占到七成.建议刚毕业的朋友或软件初学者不要在这一块来凑热闹,即使你作成了设计师,但在我眼中看来你也不是一个合格的设计师...当然你有这个能力来作设计师就要恭喜你了.c.软件测试

熟练软件测试的各种理论或实际运用,也要熟悉编码技术及相关的技术平台,熟练掌握业务.软件测试中一般都会有:

单元测试,要求你熟练开发技术进行跟踪调试,也就是白盒测试了

集成测试,对整个项目流程的测试,要求掌握业务知识,对设计的软件能作功能上的测试或压力测试等 ,属黑盒测试

确认测试,对业务要很熟悉,测试软件是否完全满足了客户的业务需求.总体建议:

1.熟练一种技术平台,熟悉一种业务

刚入门的朋友很容易犯的一个毛病是,熟练:VB,VC,.NET,JAVA,C++,C,Dephi,PB,几乎市场上要用的他全部会,唉,如果我看到他的简历上有这么一句话,这个人肯定不会在我考虑的范围了.现在全球用得最广最多的技术平台体系也就三大体系:

sun的J2EE技术体系(JAVA):在高安全性,高性能上更胜一步,中高端市场上用得多

微软件的技术体系(C++,.NET,c#,VB):在中,低端市场占绝对优势,也是全球个人电脑操作平台用户最多的.CORBA技术体系统(一种分布式技术体系和标准)，全称:Common Object Request Broker Architecture：公共对象请求代理结构,可以用不同的编程语言写成，运行在不同的操作系统上，存在于不同的机器上。

一般介于底层和上层管理软件之间，其他的还会包括底层开发:C,汇编,属纯底层的开发,当然要求技术的起点和业务背景更强,最好是学的专业:电子电气,嵌入式行业,机械制造,数据采集等...看中你想要从事的技术体系,选好一门语言工具,好好上路吧...:)

永远要记住:你什么都想学,你什么都学不精

2.从基础入手,不要好高鹜远,眼高手低,要与实际结合 B.产品售后(支持,实施)

这一块对于开发技术的要求来讲不是那么明显,主要工作会在软件开发后的工作,跟客户打交道多,但更多要求体现在对业务的把握和客户的交际上.有些软件产品业务比较成熟,如果参与这一阶段的工作,可以快速学习很多的业务知识,积累客户交往的经验

建议:刚入门或刚毕业的朋友,可以在这个工作上多选择,等待时机成熟,立马杀入软件的开发或设计阶段,当然,这一块的工作作得好也不容易,如果适合你作, 工作环境或工资都不错你就大可不必多想了...C.产品管理(项目管理等)

这一块的工作主要体现在管理上,当然适合有一定经验或管理能力的人员来担当, 最后的技术从业方向总结：

技术型:先选择好一种技术平台,熟练一种开发语言和数据库...专业专注的搞几年再说

技术+管理型:如果你有一定的技术经验了,并且人际交往,管理能力不错,你就可以向这个方向发展

技术+业务型:精通一种技术平台,精通一种业务,好好搞,这种人才最受欢迎...管理型: 如果你有一定的社会经验,从业经验,如果人际交往,管理能力还可以,老板也喜欢,就搞这个

业务型(市场):如果你对业务很感兴趣,跟客户的交往等也不错,你可以选择了,有适合的专业技术就更能锦上添花了

技术+市场+管理:老大的位置....:)