第一篇：老程序员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分假，或偷换概念，总之目的就是把一棵小草说成一座森林。信息是有欺骗性的，商业运作会大量运用这种特性，换来的除了肾上腺素之外还有人和人之间不信任的感觉。信息爆炸的时代，交流的作用变成空前重要，但在交流越来越方便的同时，效率也越来越低了。也许几十年后，人类会不堪信息的重负，那时信息规范化和有序化才会真正站上历史的舞台。
第二篇：程序员-从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分假，或偷换概念，总之目的就是把一棵小草说成一座森林。信息是有欺骗性的，商业运作会大量运用这种特性，换来的除了肾上腺素之外还有人和人之间不信任的感觉。
信息爆炸的时代，交流的作用变成空前重要，但在交流越来越方便的同时，效率也越来越低了。也许几十年后，人类会不堪信息的重负，那时信息规范化和有序化才会真正站上历史的舞台。
第三篇：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++程序员更感兴趣的吧。
第四篇：从程序员到技术总监,分享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.产品管理(项目管理等)
这一块的工作主要体现在管理上,当然适合有一定经验或管理能力的人员来担当, 最后的技术从业方向总结：
技术型:先选择好一种技术平台,熟练一种开发语言和数据库...专业专注的搞几年再说
技术+管理型:如果你有一定的技术经验了,并且人际交往,管理能力不错,你就可以向这个方向发展
技术+业务型:精通一种技术平台,精通一种业务,好好搞,这种人才最受欢迎...管理型: 如果你有一定的社会经验,从业经验,如果人际交往,管理能力还可以,老板也喜欢,就搞这个
业务型(市场):如果你对业务很感兴趣,跟客户的交往等也不错,你可以选择了,有适合的专业技术就更能锦上添花了
技术+市场+管理:老大的位置....:)
第五篇：2016年终总结—从技术助理(采购)到 程序员
2016年终总结
从2015年的7月份，…给了我一个以应届生的身份感受社会的机会。在…的第一份工作是…。经过2015年的对岗位职责的了解，2016年我已经能够独立负责一些部门业务。我的工作主要是以下几个部分，线上线下的采购、ERP系统的操作（主要包括bom搭建、采购、生产、销售）、台账统计、部门报销以及部门小库房的出入库管理。
采购应该是一个公司节约成本的开始，电子元器件这个市场本身就是质量鱼目混珠，价格参差不齐，一件物品辗转几手可能就成为了高价。质量放在首位，货比三家，保证价格的合理性，是我们采购时的最好的追求。线上平台主要用于一些量小、不太常见的且不在硬件中起到主导地位的电子元器件以及一些部门研发需要的附属物品等。线下平台一般是合作过多次并且有良好的信誉的供应商，建立了一些商业上的信任，可以大批量的采购一些硬件所需的主要器件，这样能保证质量的同时，价格也是相对低的。当然平时也要注意供应商的扩展，以免采购处于被动状态。
ERP操作，是记录生产流程，财务流向的直接有效的工具。从一开始的采购到后来的生产，销售，能够保证每一项工作有理可依，有据可循。也是部门与部门之间的无声交流。一条贯穿公司业务流程的主线。我在2016年1月到6月，完成了IDTT、故障指示器、总保、核心板等上千个设备的ERP生产操作，主要包括搭建BOM、采购、生产、委外、销售一系列的流程。虽然实际的采购、生产、销售等是很重要的一环，但其实对于公司来讲记录这些也是不可或缺的一步。台账的记录，如果说ERP是部门与部门的沟通，那么台账就是自我记录的很好的例子。采购中合同的签署，付款的规则，合同执行的进度等等，在台账中可以很直观的看到。自我总结是必不可少的，2016年上半年几十甚至上百个合同的记录和执行都很详细的记录在了我们的台账中，并且实时检查，每个月通过台账制定下个月付款计划等。
2016年7月，公司又给了我另一个机会，岗位从技术助理调整成软件工程师。工科毕业的我本就对编程有着浓厚的兴趣，得知本部门有软件岗位的需求，便提出了转岗的要求。
我接触的第一个项目是…，我负责此项目的客户端部分，初遇C#我，是措手不及的,C#的面向对象对于我来说是一个新的思维模式，所以学习新的知识成为必经之路，转岗之前自学了C# Primer Plus，涵盖了计算机语言的基础知识和面向对象语言的独特之处。但这本书是以入门为主，看完这本书之后直接接触了…项目的部分程序，经过两个星期的熟悉，基本上能了解之前程序的思路，此时我主要负责的是winform搭建界面部分。
这部分还需要实现的是…这些功能。2016年7月到8月，基本完成了上述几项任务，也学到了很多，此时才是我感觉自己真正入门的时候。通过这两个月的学习和工作，我对面向对象的理解也更加深刻，在修改或者添加程序时，也会去学习功能的具体实现方法，思考逻辑上合理性。尤其是在修改的时候，必须兼顾上下运行的逻辑，避免错误的出现，慢慢的感觉到其实语言真的是互通的，不管是C还是C#我的逻辑是一样的，只是在面对不同语言时，就像是在使用不同的工具，但是殊途同归，顺着自己的思路不管用哪种语言总是能实现相同的功能，体会到这一点后，我感觉自己对C#的学习又多了几分信心。因为对这个程序的了解，在功能实现阶段之后，客户端程序都交由我负责。在上个阶段时，为求快速实现功能会有很多逻辑简单但是代码冗余的情况出现，比如…功能、…功能、…功能。自此我便走上了简化代码的道路。统计分析和分辨率自适应都是因为多用了列举的方法，各种不同情况出现都要重复几乎相同的代码，所以摒弃了这些方法，做到让程序自己判断不同情况做出不同处理。设备配置是关乎用户体验的一项功能，之前的操作较为繁琐，不能只是简化方法那么简单。而此时软件正在强调设计文档重要性，本着试试的态度，开始了就设备配置而言的程序设计文档的编写。
从界面设计到每个方法的实现都写了下来，发现写文档是一个很好的拓宽思路并记录思路的过程。其实之所以决定写文档更大的原因在于写这个程序之前，虽然有一定的思路和想法，但是无从下手，从何写起是一个大问题。这次文档编写，规范思路，找到程序入手点，拓宽思路，有条不紊的实现过程其实是有一种成就感的，没有紧张混乱的情绪使这次开发感觉很轻松。之后也写完了这个功能程序并封装成了类库放进了原来的项目中。9月到10月期间对此项目的完善也让我对winform的运用更加熟练，也有了一些自己对于程序的思路和 想法。
应项目需求，需要把…的实物展示改造为线路模拟形式的展示，并实现原来界面上的所有功能，包括…功能、…功能、…功能、…功能、…功能等。这次改动的特别之处在于…，之前…项目的的总保最高上限是6个，所以把每个都作为一个单独的对象处理。现在数量是20到30个，之前的方法在此显得不太合理了。在11月完成了这个任务，这个解决方法应该再用回到…项目中（正在实施）。
12月份参与了…的编写，初步了解了Window系统的API函数和Winform的GDI+画图技术，当然这两项技术需要今后在学习中巩固。但是因为故…持续时间应该准确到毫秒级别，但受Windows系统的限制，精确度并没有达到。对于这次开发，我也认识到了自己的不足，知识面狭窄，利用新的技术的手段有很大的局限性。学会一项技术很重要，在开发项目面前最有效的方法是使用技术。
2016年对我来说是很特别的一年，感谢所有给过我机会的人和事。我在2017年一定会更加努力的去学习更好更多的技术，从网络、书籍等不同的途径获取更多的知识，拓宽我的知识面，为之后的工作打下坚实的基础，也希望我的知识能够为公司创造更多的利益。
点击咨询 