近期工作心得

     从实习到现在工作已有7个多月的时间，基本完成了从学生到打工仔的转变，收获还是不少！一直想把这些收获与大家分享，苦于自己太懒总是不愿下手！刚和baobao聊完天，虽然已是凌晨，却十分精神，心想不能辜负了这么好的精神、这么好的心情，甚至这么寂静的深夜，决定在“亲亲我的宝贝”的歌声中写一些对项目的认识！

    总体来说，这几个月的工作对我最大的提高并不是在编程能力方面（当然不是没有提高），而是对项目、工程的理解。我先后参加了几个项目的研发，更多的是在维护以前的项目，所以时常感觉自己不像研发而是一个技术支持工程师——维护项目、支持现场、升级版本等，也有过几次公出现场的经历。正是对过往项目的维护中，我有机会比较前人代码的优缺点、思考如何管理项目、版本，也有机会反思解决问题的方式。

 

1、版本管理

 

    项目从设计、实现到正式上线要经过很多次的测试、修改，特别是定制化的项目；在运行过程中客户还会反馈新的bug、提出新的需求。为了在很短的时间内解决问题、实现需求，必须对项目的版本做好管理，这对于后续的维护、开发十分重要。

    版本管理最基本的应该做到以下几点：

 

    (1) 撰写详细的设计文档——包括功能的实现细节、操作说明、使用限制以及仍待考虑的问题；

    (2) 编写详细的配置说明——包括运行环境配置、注册表配置、ini文件配置、数据库配置、字典等；

 

    (3) 编写版本升级说明文档——包括注明版本号、升级时间、版本升级历史，详尽的叙述修改、增 

         加的功能，遇到什么问题而作如此修改;

    (4) 编写版本升级要求其他相关文档——配置是否有改变、字典是否有改变等这些都要有记录，为现

         场升级方便，也为自己方便。  

    (5) 修改的源代码一定要同步更新到源代码管理器上，比如VSS，并做好修改记录，打好版本升级的

         label；

    (6) 发布现场时一定要用邮件发送包括领导在内的所有相关人员，邮件内容详细写明升级的原因，以

         及如何修改的。 

 

2、独立软件发布

 

    当你需要发布一款独立软件时，需要给该软件整理出独立bin包，说白了就是找到软件需要的dll、exe、配置文件等，项目管理做好了整理出配置文件很简单，比较难的是d依赖库的整理。一般来说，软件依赖的库分静态加载和动态加载。分别介绍如下:

 

    静态加载的库通过C++开发平台自带的depends工具很清楚的看到，把凡是不在系统目录system32下的库全部拷到当前bin下，注意拷入的库往往又会依赖其他库，也要拷到当前bin下。

    动态加载的库整理起来相对困难，从depends无法看出。一种比较笨的方法就是：调试软件的源程序，尽可能测试到软件的所有功能，这样在开发环境的输出中会看到所有的依赖库（静态和动态的库）。查看动态加载的库的工具没专门找过，不清楚有没有这样的工具！

    当你整理完bin包，最好把软件依赖的所有库写一个批处理文件（比如copy.bat）放在bin中，以后发布时会轻松许多。

 

3、项目维护

 

    项目维护不像开发那样单一，它需要你和现场实施人员、客户进行很好的沟通，了解问题的真实情况。一般解决项目问题的原则就是从宏观着手，根据现象分析问题可能的原因，最坏的情况就是细致入微，调试代码找问题（貌似这种思路应用于生活中也是如此）。

    首先弄清楚问题的来龙去脉，从现场实施人员了解到的多半是问题的现象，然后你需要思考这些问题背后的原因，这是最难的地方。为了确定问题根源，可以进行一下尝试：

 

    (1) 借助日志分析（前提是程序要求相应的日志输出），确定问题原因；

    (2) 获取现场环境配置，包括配置文件、注册表、数据库配置等，确定问题原因；

    (3) 获取现场测试数据，很多情况下数据格式的不同也会导致错误，确定问题原因；

    (4) 最坏的情况，拿出杀手锏——还原现场环境调试代码，确定原因。

 

4、代码规范

 

    代码规范是一种约定俗成的东西，对于代码的可读性十分有利。对于项目来说，它也是发现问题确定问题的良好手段。

   部门有两招很绝：所有的return必须有日志输出，所有的异常必须被捕获。当然这是以降低程序的执行效率来提高代码的健壮性、提高解决问题的速度，在实时性要求较高的场合需要合理取舍。

   各公司都有各自的代码规范，也许相互之间会有很大差别。这时不要迷惑认为谁错谁对，因为规范只是一种习惯，不是定理。你只要遵循自己团队的编码规范就足够啦！

 

     就先写这些吧，该进入梦乡啦！