一个程序员的2013上半年总结

引----

上次写半年总结距今7个月，又到了年中，必须得停下来好好总结一下。

一、技术

    （1）对j2ee有了全新的理解

            这段时间好好学习和复习一下j2ee的相关知识，对j2ee核心规范了有了更加深入的理解，特别是EJB3，RMI，JTA等。同时深入剖析了分布式企业级应用的分层模型，并做了相应的DEMO，将之部署到j2ee应用服务器（JBOSS，WebLogic）上，从中又再次加深自己对EJB容器和Web容器的理解。

            

    （2）技术杂糅

            在做项目的过程中，牵扯到很多常用技术的学习和应用，有轻量级企业级应用常用的框架，如Struts1,2\Hibernate3\Spring3(SpringMVC等)\I,Mybatis\JSF等，也有重量级企业级应用常用的规范，如EJB3.0，JTA，JPA，JMS,WebService等。一个项目中仅仅有上面这个骨架是不够的，还牵扯到其他一些java框架，如activeMQ，jbpm,junit,log4j,ant,freemark,dom4j,axis,dwr等等.还有一些javascript框架，如Jquery，jqueryUI，ExtJs等。数据库方面，主要牵扯到关系型的MySql，Oracle，SqlServer和非关系型的MongoDB。            

    （3）接下来的关注点hadoop 

            最近面临的一个项目可能要采用面向云的架构，所以三个月前可以了解hadoop方面的东西，在看一本《hadoop实战》，算是一本工具书或者参考书。后来因为要恶补一下外语，打算了那么一个月。现在基本上了解了hadoop的概况，能搭建出hadoop集群的运行环境，并在几台Linux机器上做了测试。同时也搭建了一个eclipse的开发环境，包括本地开发版和远程连接hadoop集群开发版。接下来还需要做更多的测试Demo，并了解hadoop相关框架，看看如何把它们有机的融合在一起，构成我们GX项目的云架构。

二、项目

1、KS项目维护

    （1）项目总结见博客：

            http://blog.csdn.net/shan9liang/article/details/8636221

            在总结中主要围绕项目管理展开，项目经理，开发周期，需求和设计等。

 

    （2）维护总结：

            这个项目是我参与开发的，维护的工作自然也就落在了我身上。在项目上线后，我一般会是那个坐在服务器旁的程序员，在现场的人反应什么问题，我就及时处理，保证程序的正常运转。总结下面几点要注意的：            

            1）对需求的频繁变更点要有所预估和处理。

                在项目上线后，用户又提了几个需求变更。因为提前已经对需求变更可能性比较大的模块做了预估，所以处理起来不是很复杂。总结出一条最佳实践，保证效率的同时，在需求变更频繁的模块采用相应的设计模式，如策略模式等，可以很好地保持程序的灵活性和可扩展性。不要总想着偷懒，完成已有功能是不够的。

            2）在用户的角度思考问题

                 “为人民服务”一个不得不谈的老话题。在使用过程中，我们也发现了一些很不人性化的地方。如果单个页面承载功能过多，操作比较复杂；下拉框选项过多，用户查找困难；有些地方不能批量添加等等。

这些问题的暴露说明在设计的时候，没有站在用户的角度思考问题，犯了想当然的错误，也是一种偷懒的表现，仅仅考虑自己开发方便，没有考虑用户是否使用方便。

            3）对软件在存货周期中将会出现问题的预期，如何规避？

                很多时候，凭借我们的经验，我们会很容易察觉程序可能会出现的问题。如：当数据积累到一定量，查询效率的问题；当网络出现故障时，如何保证数据不丢失等等。

这也算是一条最佳实践吧，对在软件存活周期中可能会出现的问题有一个预期，尽量提前拿出解决方案。

 

            4）很多经验来自项目维护

                设计人员对整个程序有较深的了解，但他们很多并不参与到程序上线后的真实运行环境中去，开发人员一般仅仅对程序的某几个模块比较了解。他们对程序出现的问题都没有最直接的感受。相比设计人员和开发人员，维护人员在这方面就有得天独厚的优势，他们最接近客户，也最了解程序的真实运行情况，能在处理问题的过程中得到锻炼，维护工作更能让他们在今后的项目中站在用户的角度思考问题，对项目可能出现问题有敏锐的洞察力。这里又有一条最佳实践，要重视维护工作，这是一块能帮助程序员迅速成长的磨刀石。

    

2、TSG项目开发

    大概7月份，应别人邀请，接手了一个小项目TSG，开发组成员一共4个。然后我又临时组建了测试组4个人。然后我们就着手开工了，下面谈谈这次项目的几点体会。

 

    （1）过程

            1）新手也具有较高性价比

                 我们小组的成员都是新手，仅仅有那么一点点web项目的开发经验，不过拔拔高应付TSG项目还是没有问题的，因为项目比较紧，不可能要求他们先培训后上手，而是直接边学习边开发。大多时候，我会告诉他们项目中哪些功能需要哪些技术，大概思路是怎样的，需要他们自己搞定，他们的学习能力很棒，能跟上项目的节奏。我觉得有时候项目组成员不一定个个都是精英，只要有人带，加上他们自己良好的学习能力，他们个个都能变成精英，而且对公司的忠诚度也较高，对公司而言这是一笔可观的财富。当然我们需要有合适的项目去锻炼他们，再加上合理的成本和质量把控，相比直接高薪聘请一整队技术大牛而言，项目组中融入一些新手也是有较高性价比的。公司不要总是考虑雇一个人就要求人家什么都会，那不可能，而且仅仅靠工资去留人，总是有些不靠谱。

            2）项目计划

                这里提到项目计划，是因为我没有做好这块内容。导致项目进度不明朗。因为项目比较小，我大意了，我只是初步拟定了一个计划就开始动工，并没有对项目规模进行合理评估，没有划出相应里程碑，导致项目进度松散，不能一目了然，这些直接导致开发人互相扯皮拖延。以后我会再项目文档中注意项目计划这块。而且在项目开发过程中进行微调，这种微调也要落实到文档中，到什么点完成什么事，要清晰可见。

            3）代码质量

                因为我并没有参加编码，我只关心功能的实现，而忽略了代码质量，导致的问题相信各位一定已经猜到了。代码写得一塌糊涂，你以为他们会严格遵守公司的编码规范，但事实并非如此，敲着敲着他们就开始走了自己的风格。从这一点上我意识到，靠人们自觉恐怕并不那么容易，必须把代码走查提上日程。我觉得最好的方式是开发组长参与部分编码，很小一部分就可以，这样他能及时发现代码中出现的问题，及时采取措施。

            

            4）文档

                这又是一个老话题，但还是忍不住说两句，我们的设计人员提交的文档，并不能让我满意。我最直接的感受便是，他们并不用心。他们写文档总是喜欢套用模板，然后站在自己的角度想当然的写，导致文档并不能发挥重要的作用。写文档应该在遵循公司模板的同时，站在读者的角度去写，时刻要记得“怎么写才能让读者更容易接受，更容易明白，更能发挥文档的作用”。如果自己写的东西，自己都认为没用，写出来有什么意义呢？徒费工夫而已。

   

            5）测试

                项目肯定是要边开发，边测试的，不可能等到项目完成了再测试，那样后果很严重，问题发现地越早越容易解决，造成的损失越小。这一点上，我觉得自己做得还可以，及时组建了测试组，在整理需求的时候，测试组成员就已经跟进了，同时指导他们搭建测试环境，为他们测试顺利进行打下了基础。

                

            6）后期总结

                在项目结束后，我给自己项目组成员一点点时间，让他们好好总结一下这次项目的得失，然后开发人员和测试人员坐在一起分享了一下，这次项目我们有哪些做得好的，以后可以借鉴的，哪些做的不好的，可以避免的，以及项目中有哪些技术点可以拿出来分享，将总结的结果以文档的形式保存下来，也算是一种不错的积累。用一天的时间回顾，相信大家都会有所思考，有所提高，对以后做项目肯定有帮助。我们不能总是两眼望着前方，只知道往前冲，适当的时候应该停下来回顾一下，总结与反思，只有这样，我们才能不断提高自己，不断为公司创造价值。

                

    （2）作为开发组长

            作为组长，首先在你的团队必须要有足够的威信，我认为这种威信应该来自一个人的全局观，业务水平和责任心。接下来就是你的沟通能力，你必须带动整个团队，使整个团队信息通畅，有问题及时沟通，这样才能保证项目有条不紊地进行，记得我跟我的组员说得第一个问题便是沟通的问题：“有问题不要憋着，及时提出来，等到问题自己暴露出来，可能已经无法挽回了”。对工作量的评估，对项目进程的把控，对人员的分配，这是一个组长基本的素质，自不必多说。适当地放权，给予成员足够的信任，也是一个组长应有的魄力，这点我在这个项目中做得不是很好，因为我过多地询问了他们的进度，可能对他们造成了不好地心理影响，认为我不够信任他们，在下一个项目中我会非常注意这一点。对于质量把控，我认为不能仅仅依靠测试去发现问题，作为组长应该能够提前规避一些，例如组长参与部分编码，实时把控，或组内代码走查，组内互测等等。文档的把控，我觉得在提供足够优秀样例的同时，实施严格地审核应该能够应对。

             我想说，我想带更多的项目去创造价值，去磨练自己。   

            

三、英语

    由于未来公司需要，我不得不提高自己的外语水平。很有趣，我参加了一个7人小组，主攻英语，历时一个月，感觉还不错。以前我也坚持在学英语，但没有一个清晰的思路，虽然也在进步，但效率比较低下。这一个月里，我们经历精听，跟读，纠音，全英讨论，找老外。我的收获如下：

   （1）精听一遍是不够的，要很多遍，一个短故事，可能要听上一周，这时候这个故事中的一些句子和短语可能仍然不是你的，应该尽可能在平时交流时用上这些句子和短语，多用，才能成为自己的。

   （2）跟读只是第一步；复述是第二步；能快速回答英语问题才是重要的一步，当对一个资料足够熟悉的时候，找你的同伴，从这个材料中抽出n个问题，不断地，反复地提问你，你快速地回答关于这个资料的问题非常锻炼英语思维，快速回答的过程你不会思考。

   （3）纠音，我的感触挺大的，原来自己读的很多都是错的，很多时候听不懂别人说话，不仅仅是因为词汇量不够或练得少，而是自己压根就不认为这个词是这么说的，如果大家一起纠你的音，可以帮助你发现自己很难发现的问题。不会出现自己读错了都不知道错了的情况。练英语绕口令这种方式不错，非常锻炼我们的嘴和舌头，而且有利于我们的语感。

   （4）全英讨论，这里有一个很重要的点，那就是不思考，快速回答别人问题，而且迅速说出自己的句子，哪怕语法不对，经过长期这么锻炼，我想我们的英语思维一定能够建立。

   （5）找老外，利用各种IT工具，最好找那种他想学汉语，但汉语又学得不怎么样的，这样你教他汉语的时候，基本上你们是用英文交流的，这是同伴给我的他最直接的经验。这点我做得不好，至今我在别人帮助下才跟一个老外说了一会，我还会继续努力，一定要突破这道坎。

   （6）一定要有几个志同道合的朋友，你们一起努力，那感觉真的很不错。

   

四、结语

    上半年的总结就到这吧，顺便写下自己下半年的期待：

  （1）英语，能跟一个老外愉快地聊上2个小时

  （2）带领团队克服困难构建面向云的GX系统

  （3）体重控制到160以下

    哈哈，再见。