编程工作总结
不知不觉从校园出来已经有两年了，在两年的工作过程中，也着实悟出了点经验，下面进行总结。
1. 如果可以，请选择一个有资深工作经验的人负责的项目。一个好的系统离不开一个好的框架，好的框架必定由好的架构师来架构。XPR项目从一开始就是一个错误，首先是Vision的错误，开发这个项目的目的是用目前较流行的开源框架来重新实现现有系统XPC的全部功能，并且把XPR的部分功能能开源出去。要重新实现现有系统XPC的全部功能，这本身就是很不现实的做法，XPC已经发展了8年有余，并且后继还会不断有新的功能要求，要这种情况下，XPR要做到功能上与XPC完成一致，这是非常困难的。开源并非说你有这个想法就能实现的，得事先看看这个开源项目存在的价值，就是说有哪些人会用，为什么要用，不用行不行，或者有没有同类产品已存在。这些公司都没有进行调研，失败也是常情之中。最为重要的是，所有开发人员包括leader，都对这个开源一知半解，在这种情况下，开源实际上就是无知之谈；其次，负责项目的几位核心开发人员对原系统并不了解，也对新技术比如一些开源软件不了解，甚至对整个领域都不了解。特别是UI层的leader，对UI层的开发并无实际经验，不熟悉javascript，JSP和Servlet，言之可以边学边做！做了大半年后在一次会议上还有惊人的议论：页面的内容版块要做成浮动窗口，因为现有系统也应该是这样的！结果可想而知，一开始用的是Tapestry，后来直接使用Dojo，代码写得连开发人员都不愿维护，项目一再延期也成必然。
2. 对陌生领域或需求不明确或对于新技术的应用，开始时不需要太多的想法和设计，直接地编程应用，在应用中发现问题并解决问题开是关键。XPR项目因为想着需求明确，就完成按照软件开发工程学的那一套的开发流程来开发，先是分了几个模块，然后为几个模块找了owner。开始的时候会议会多，文档也很多，都是在讨论每个模块之间如何交付，应该如何提供API让其它模块调用的问题。说得我是头脑发帐，也听不出个所以然来。细想下，也许是因为自己经验不足吧。会后再细问owner，言之我也不清楚，反正这个也不用管，其它模块会写好给我们的了。我在怀疑是真不知还是假不知，后来事实证明原来真的是不清楚的。结果又可想而知，API不断变动，先前花了一个季度写的POC文档和设计文档作用全无！分模块开发是好事，能够把责任分配到家，但并不是说各个模块之间就不需要理会其它模块了。在模块化开发中，我甚至变为模块之间的交互才是最重要的成功之本。如果这时有位角色能负责各个模块之间的沟通工作的话，项目开发会好许多。这当然少不了提及敏捷开发方式，我认为，对于陌生领域或需求不明确或对于新技术的应用，采用敏捷开发方式是再好不过的了。无需太多文档，一切让事实说话，代码出结果，结果行就是行，不行就是不行，没有任何二义性可言！
3. 大学专业基础课程非常重要，像数据结构，算法设计，编译原理，操作系统，计算机体系结构，微机原理，汇编，TCP/IP原理，C/C＋＋。这些都是我们今后学习技术的保障。我认为，国外的程序员和中国程序员相比，不是说OpenAPI，SOA，开源软件的差距，最重要的是那些底层的技术和思想！不过说实话，如果学习过程中没有应用，事实上也无法把这些基础学习个通透，这就是为什么我们总是说大学学到的东西简单是在浪费时间。所有的一切都离不开深入理解，要深入理解java的collection，必须对数据结构有个非常清楚的认识；要学习JDK原理，编译原理知识一个都不能少；要知道多线程编程，操作系统能帮上大忙；要想知道对象在内存中的分配和状态，微机原理能够告诉你。假如我们作为程序员能把写一段代码后，到输出结果的每一过程都如大致说清楚，那就算合格了。比如要对这一段代码进行编译，再执行，编译过程中作了哪些工作？词法分析，语法分析，语义分析到中间代码的生成后，java的字节码为何是中间代码，为什么不能直接是最终的目标代码。为什么说JVM是一个虚拟机，既然是虚拟机必定会有CPU，输入输出，内存等等的概念，这些需要对应JVM的什么部分，为什么可以这样子做，又为什么需要这样子做。java基础编程也是相当重要的，比如说如何创建一个对象，如何对这个对象赋值，如果管理这个对象等等，这些都是学习Spring的基础，也是Spring IOC需要解决的问题。一般而言，无须查看Spring源码，我们都知道Spring必定也会按这样的一个流程要走。曾经有个同事，有一次我看到有个Test Case需要用到一个Mock Service，我就问他为什么不直接new一个Service算了，还要引入Spring？答之只会用Spring里的Bean而不会编程生成一个对象！如果只是一次的话倒也可以说成是谦虚，但后来的接触证明，他真是只会调用Spring管理的Bean对象，如此谈何精通Spring！
4. 认真做事，诚实做人！在项目开始阶段，对新技术实现还没有做过测试的情况下，先是写了大量的可行性分析报告，告诉领导层说这个可实现，那个简单，好象用了就可以解决一切问题似的，结果把个领导哄得开开心心，对项目信心十足，期望值大增。但是，做了那么多工作，实际上只是为了讨好领导而已。反正以后的事情也不重要了，能把项目做成功固然是好，做不成功也没什么，大不了就跳呗。反正现在得到了领导的赞许和肯定，以后的日子再从长计议。当然，我这似乎有点以小人之腹度君子之心。但我参加项目开始半年后，我的owner就离职了，接着是到了三四个月前，所有owner也都辞去了工作。这跟项目实在做不下去也有很大关系。没错，项目是有风险的，但我们的过程从一开始就是错的。
5. 注重代码的规范性，保证代码质量！这就涉及到写Test Case，遵照一定的编程规范和习惯的问题了。我们可以使用工具来保证我们个代码的质量，比如用Spoonet来检查代码的规范性，用luntbuild来保证代码可编译，甚至在maven中保证Test Case的执行。工具保证不了的，我们就需要leader或owner来保证。比如通过Code Review来查看手下的代码，甚至可以叫到身边来解释程序大概的流程，甚至可以用结对编程方式来保证代码的质量。比如Test Case，我们知道要完全能够把它写好实在不易，比如对比两个对象是否相等就要做大量的工作，有时我们情愿用Debug的方式来人工查看一个对象的各个属性值。这对于leader或owner来说运行这些test case意义也不大，但可以询问程序员每一个test case都测试些什么内容，看看是否测试的到位。这是非常简单而且非常有必要的。本来我们对Test Case是非常重视的，但是有个leader说以后可以把项目的Test Case做成一个framework，目的是非常方便地让程序开发人员写Test Case。人都有惰性，得知会有简单的工具后，现在就不会写或认真对待Test Case的了。且不说这个framework方便不方便，单单从它的发展经过来说就知道不可行，framework的出现是要经过千千万万的编程实践后总结出来的。比如说Struts的出现，是MVC编程发展到一定阶段后出现的，并不是某个人头脑发热就有了Struts。我们要写个test case的framework，一定要先经过大家各自写自己的test case，然后再由资深开发人员的总结，才能设计出一个符合项目本身的test case来。反正我不太看好这个test case framework，所以我的test case还是照写。但其它开发人员已经不再写自己的test case了，后来项目连正确性都没有保障，跟这个也有莫大的关系。有些错误本来可以是单元测试阶段发现并解决的，都延迟到QA测试阶段才能解决了。直到现在，那个所谓test case framework还没有人理会，就像共产主义一样摸不着边际。
6. 对新技术保持热情，但要牢记，任何知识和技能的获取都是一个长期沉淀的过程！罗马不是一日建成的，万有引力不会只是一颗苹果掉下来就能发现的，原子弹不是一不小心造出来，现在千奇百样的灯离不开爱迪生的发明，如今强大计算机也离不开1946年的那一台庞然大物。XPR想着用最新的开源软件实现，还要Web2.0，SOA等等，概念的炒作的确令高层领导很是开心，但是一个高性能，高可靠，高可用性的系统，还是得有大量的技术沉淀基础。XPR完全抛开原有的XPC系统，这本身就是一个错误。应该在XPC的基础上，加上新技术进行重构才是根本。中国软件产业，出路是在国际化！国际化对于软件企业本身，没有任何意义可言，但对于客户企业来说，这无疑是相当重要的。中国现今的事实就是，凡是国外来的，都代表了声望和质量，无疑声望又是重中之重。现今在ERP市场上，人们相互问得最多的就是“上ERP没有？”，倘若说没有，那对不起，可能一单生意就没有了；接着是“上了哪个公司的ERP？”，如果说出了个不知名称的ERP提供商，那也对不起，这说明你企业管理还是很差，没有达到国际化。竞争优势有时来自于对概念的炒作，人们总是对新鲜事物比较的感兴趣。比如96年时家电企业的全面胜利就归功于低价和炒概念。在ERP市场上，国内著名的ERP企业也不例外，比如03年金蝶的ERP2，URP，用友，神州数码的RTE的疯狂炒作等。对技术的炒作归炒作，别人不知道那炒作是件很好的好事，但自己必须相当清楚，这些在目前只是炒作，还得时时刻刻注意怎样把炒作的东西真正地用起来。不然，就会面对一个非常残酷的现实，当消费者越来越理性的时候，我们的家电企业还无法生产一部真正是由国人造的电视，洗衣机！
1. 如果可以，请选择一个有资深工作经验的人负责的项目。一个好的系统离不开一个好的框架，好的框架必定由好的架构师来架构。XPR项目从一开始就是一个错误，首先是Vision的错误，开发这个项目的目的是用目前较流行的开源框架来重新实现现有系统XPC的全部功能，并且把XPR的部分功能能开源出去。要重新实现现有系统XPC的全部功能，这本身就是很不现实的做法，XPC已经发展了8年有余，并且后继还会不断有新的功能要求，要这种情况下，XPR要做到功能上与XPC完成一致，这是非常困难的。开源并非说你有这个想法就能实现的，得事先看看这个开源项目存在的价值，就是说有哪些人会用，为什么要用，不用行不行，或者有没有同类产品已存在。这些公司都没有进行调研，失败也是常情之中。最为重要的是，所有开发人员包括leader，都对这个开源一知半解，在这种情况下，开源实际上就是无知之谈；其次，负责项目的几位核心开发人员对原系统并不了解，也对新技术比如一些开源软件不了解，甚至对整个领域都不了解。特别是UI层的leader，对UI层的开发并无实际经验，不熟悉javascript，JSP和Servlet，言之可以边学边做！做了大半年后在一次会议上还有惊人的议论：页面的内容版块要做成浮动窗口，因为现有系统也应该是这样的！结果可想而知，一开始用的是Tapestry，后来直接使用Dojo，代码写得连开发人员都不愿维护，项目一再延期也成必然。
2. 对陌生领域或需求不明确或对于新技术的应用，开始时不需要太多的想法和设计，直接地编程应用，在应用中发现问题并解决问题开是关键。XPR项目因为想着需求明确，就完成按照软件开发工程学的那一套的开发流程来开发，先是分了几个模块，然后为几个模块找了owner。开始的时候会议会多，文档也很多，都是在讨论每个模块之间如何交付，应该如何提供API让其它模块调用的问题。说得我是头脑发帐，也听不出个所以然来。细想下，也许是因为自己经验不足吧。会后再细问owner，言之我也不清楚，反正这个也不用管，其它模块会写好给我们的了。我在怀疑是真不知还是假不知，后来事实证明原来真的是不清楚的。结果又可想而知，API不断变动，先前花了一个季度写的POC文档和设计文档作用全无！分模块开发是好事，能够把责任分配到家，但并不是说各个模块之间就不需要理会其它模块了。在模块化开发中，我甚至变为模块之间的交互才是最重要的成功之本。如果这时有位角色能负责各个模块之间的沟通工作的话，项目开发会好许多。这当然少不了提及敏捷开发方式，我认为，对于陌生领域或需求不明确或对于新技术的应用，采用敏捷开发方式是再好不过的了。无需太多文档，一切让事实说话，代码出结果，结果行就是行，不行就是不行，没有任何二义性可言！
3. 大学专业基础课程非常重要，像数据结构，算法设计，编译原理，操作系统，计算机体系结构，微机原理，汇编，TCP/IP原理，C/C＋＋。这些都是我们今后学习技术的保障。我认为，国外的程序员和中国程序员相比，不是说OpenAPI，SOA，开源软件的差距，最重要的是那些底层的技术和思想！不过说实话，如果学习过程中没有应用，事实上也无法把这些基础学习个通透，这就是为什么我们总是说大学学到的东西简单是在浪费时间。所有的一切都离不开深入理解，要深入理解java的collection，必须对数据结构有个非常清楚的认识；要学习JDK原理，编译原理知识一个都不能少；要知道多线程编程，操作系统能帮上大忙；要想知道对象在内存中的分配和状态，微机原理能够告诉你。假如我们作为程序员能把写一段代码后，到输出结果的每一过程都如大致说清楚，那就算合格了。比如要对这一段代码进行编译，再执行，编译过程中作了哪些工作？词法分析，语法分析，语义分析到中间代码的生成后，java的字节码为何是中间代码，为什么不能直接是最终的目标代码。为什么说JVM是一个虚拟机，既然是虚拟机必定会有CPU，输入输出，内存等等的概念，这些需要对应JVM的什么部分，为什么可以这样子做，又为什么需要这样子做。java基础编程也是相当重要的，比如说如何创建一个对象，如何对这个对象赋值，如果管理这个对象等等，这些都是学习Spring的基础，也是Spring IOC需要解决的问题。一般而言，无须查看Spring源码，我们都知道Spring必定也会按这样的一个流程要走。曾经有个同事，有一次我看到有个Test Case需要用到一个Mock Service，我就问他为什么不直接new一个Service算了，还要引入Spring？答之只会用Spring里的Bean而不会编程生成一个对象！如果只是一次的话倒也可以说成是谦虚，但后来的接触证明，他真是只会调用Spring管理的Bean对象，如此谈何精通Spring！
4. 认真做事，诚实做人！在项目开始阶段，对新技术实现还没有做过测试的情况下，先是写了大量的可行性分析报告，告诉领导层说这个可实现，那个简单，好象用了就可以解决一切问题似的，结果把个领导哄得开开心心，对项目信心十足，期望值大增。但是，做了那么多工作，实际上只是为了讨好领导而已。反正以后的事情也不重要了，能把项目做成功固然是好，做不成功也没什么，大不了就跳呗。反正现在得到了领导的赞许和肯定，以后的日子再从长计议。当然，我这似乎有点以小人之腹度君子之心。但我参加项目开始半年后，我的owner就离职了，接着是到了三四个月前，所有owner也都辞去了工作。这跟项目实在做不下去也有很大关系。没错，项目是有风险的，但我们的过程从一开始就是错的。
5. 注重代码的规范性，保证代码质量！这就涉及到写Test Case，遵照一定的编程规范和习惯的问题了。我们可以使用工具来保证我们个代码的质量，比如用Spoonet来检查代码的规范性，用luntbuild来保证代码可编译，甚至在maven中保证Test Case的执行。工具保证不了的，我们就需要leader或owner来保证。比如通过Code Review来查看手下的代码，甚至可以叫到身边来解释程序大概的流程，甚至可以用结对编程方式来保证代码的质量。比如Test Case，我们知道要完全能够把它写好实在不易，比如对比两个对象是否相等就要做大量的工作，有时我们情愿用Debug的方式来人工查看一个对象的各个属性值。这对于leader或owner来说运行这些test case意义也不大，但可以询问程序员每一个test case都测试些什么内容，看看是否测试的到位。这是非常简单而且非常有必要的。本来我们对Test Case是非常重视的，但是有个leader说以后可以把项目的Test Case做成一个framework，目的是非常方便地让程序开发人员写Test Case。人都有惰性，得知会有简单的工具后，现在就不会写或认真对待Test Case的了。且不说这个framework方便不方便，单单从它的发展经过来说就知道不可行，framework的出现是要经过千千万万的编程实践后总结出来的。比如说Struts的出现，是MVC编程发展到一定阶段后出现的，并不是某个人头脑发热就有了Struts。我们要写个test case的framework，一定要先经过大家各自写自己的test case，然后再由资深开发人员的总结，才能设计出一个符合项目本身的test case来。反正我不太看好这个test case framework，所以我的test case还是照写。但其它开发人员已经不再写自己的test case了，后来项目连正确性都没有保障，跟这个也有莫大的关系。有些错误本来可以是单元测试阶段发现并解决的，都延迟到QA测试阶段才能解决了。直到现在，那个所谓test case framework还没有人理会，就像共产主义一样摸不着边际。
6. 对新技术保持热情，但要牢记，任何知识和技能的获取都是一个长期沉淀的过程！罗马不是一日建成的，万有引力不会只是一颗苹果掉下来就能发现的，原子弹不是一不小心造出来，现在千奇百样的灯离不开爱迪生的发明，如今强大计算机也离不开1946年的那一台庞然大物。XPR想着用最新的开源软件实现，还要Web2.0，SOA等等，概念的炒作的确令高层领导很是开心，但是一个高性能，高可靠，高可用性的系统，还是得有大量的技术沉淀基础。XPR完全抛开原有的XPC系统，这本身就是一个错误。应该在XPC的基础上，加上新技术进行重构才是根本。中国软件产业，出路是在国际化！国际化对于软件企业本身，没有任何意义可言，但对于客户企业来说，这无疑是相当重要的。中国现今的事实就是，凡是国外来的，都代表了声望和质量，无疑声望又是重中之重。现今在ERP市场上，人们相互问得最多的就是“上ERP没有？”，倘若说没有，那对不起，可能一单生意就没有了；接着是“上了哪个公司的ERP？”，如果说出了个不知名称的ERP提供商，那也对不起，这说明你企业管理还是很差，没有达到国际化。竞争优势有时来自于对概念的炒作，人们总是对新鲜事物比较的感兴趣。比如96年时家电企业的全面胜利就归功于低价和炒概念。在ERP市场上，国内著名的ERP企业也不例外，比如03年金蝶的ERP2，URP，用友，神州数码的RTE的疯狂炒作等。对技术的炒作归炒作，别人不知道那炒作是件很好的好事，但自己必须相当清楚，这些在目前只是炒作，还得时时刻刻注意怎样把炒作的东西真正地用起来。不然，就会面对一个非常残酷的现实，当消费者越来越理性的时候，我们的家电企业还无法生产一部真正是由国人造的电视，洗衣机！