近期工作心得

做软件开发很多年了，自信能做的事情也比较多，可是回想下来很多项目做的都不太理想，就目前的项目总结一下。

      现在项目已经到尾声，测试问题也还比较多，原因就不找了，回想一下整个过程，可以有很多改进的地方，现在总结一下吧：

    1. 项目启动阶段。项目启动时想着要设计的比较详细，所以花费了将近一周的时间进行项目的用例设计、分析。事实证明此处有些问题，在此阶段不应该进行类的设计及数据库的设计，因为一是时间上不允许在此阶段设计的很详细，二是客户也不会对这块的设计进行确认，因为他们看不懂。所以在此阶段应该将用例捕捉完成后尽快出系统原型与用户确认。而整个项目的原型大概是在项目开始后一个月左右客户才最终确定，而此时项目已经开发一些了，导致后面的调整量大。

    2. 数据库设计把关问题。在前面设计时数据库设计自己把握了大体的框架，细节交给盼盼处理，但因为经验的问题，盼盼没有把细节做到位，因此在后面改动比较频繁。总结一下，数据库的设计应该进行评审，评审时对照系统原型，一个一个将数据库操作的逻额辑进行记录，一是有利于后面的开发，二是有利于原型与数据库的对应，三是统一开发思路。

   3. 类的设计。类的设计不需要一次完成，在原型与数据模型评审完成后即可组织人员进行开发，先从基本的功能开发做起，设计一个子系统就大家一起完成一个子系统，这样的开发方式应该要优于分模块开发的组织方式。在开发过程中完善和设计类图，这样大大减少项目启动阶段的压力。

   4. 测试驱动的开发。项目一开始应该安排和培养专门写集成测试的人员，这样不至于到后期测试问题很多。而且有利于项目的推进。同时集成测试人员的考核应以每天实现2-5个测试用例为目标，按照目前的项目来看，2个月时间可以实现五六十个测试用例，如此会大大提高系统质量及后期测试的压力。ta

    5. 界面问题。在开发初期应该统一界面开发规范，应对常用开发组件使用jsp或js的标签进行封装，一是有利于程序员的调用，二是有利于界面的统一修改。

针对以上问题进行总结并优化后，后面项目开发的时候应按照下面步骤进行：

1. 发布界面开发规范及代码编写规范。
2. 使用uml的用例图进行项目需求分析。
3. 用例需求分析完成后立即进行界面原型设计。
4. 界面原型设计完成后尽快与客户沟通确认，此处应有确认书或确认邮件。
5. 根据uml用例及界面原型设计数据库模型。
6. 进行界面与数据库原型的评审会议（设计人员、测试人员、开发人员、项目经理），形成评审会议纪要，并且记录每个 界面的数据逻辑是什么样的，并且经参与人员认可通过。
7. 以周为单位制定项目里程碑，每周确定一个最小可运行系统。
8. 设计第一周的类图，
9. 集成测试人员编写集成测试用例，程序员实现各子模块。
10. 项目经理每天看看项目进度，检查集成测试代码，运行即可。

自勉

想一想，近些年对我影响最大的书是稻盛和夫的《活法》，以前也经常与别人分享《活法》之六项精进，今天写下来，自勉一下：

1. 每日付出不逊于任何人的努力。

2. 谦虚戒骄

3. 每日反省自己

4. 拥有一颗感恩的心

5. 积善行，思利他

6. 不因感性所困

好久不回顾，都有些忘记了。

1. 每日付出不逊于任何人的努力。努力的方向要对，而且贵在坚持。

2. 谦虚戒娇。要谦虚，但不要自卑，不要没有自信。

3. 每日反省自己。中国古语有云：“吾日三省吾身”也是这个意思，每天花点时间总结一下自己哪些可以做得更好是值得的，包括工作上，包括某些事情的处理，而且写下的东西也应当常常回顾，

4. 拥有一颗感恩的心。想想都有谁在日常生活中帮助过自己，滴水之恩当涌泉相报。

5. 积善行，思利他。想想能为别人或社会做点什么吧。

6. 不因感性所困。把自己能做的事情做到位，其它的就留给老天爷去安排吧。

     感谢老婆总在我身边陪伴着我～

基于springmvc的自动化测试系统构想

        做为一名多年的软件开发人员，软件质量一直是心口的一块石头，一直压抑着自己，因为软件质量的高低关乎我们每一个软件企业的生存和发展。

        事实证明软件的问题消灭在萌芽状态是成本最低的一种方式，因此在开发阶段需要进行大量的测试才能保证软件的质量。

        因此，我认为比较理想的开发模式为“测试驱动开发”，即在开发前首先设计测试用例，在测试用例的基础上进行开发。

       但是如此以来，项目的整体开发周期会加长，而且很多程序员从内心认为编写单元测试会增加自己的工作量，有编写单元测试的时间还不如编写代码能获得更高的效率，因此测试驱动开发往往达不到预期的效果。

      那么如何提高单元测试的效率呢？根据人类几千年的发展变迁史来看，提高效率的方式只有一种——使用工具。

    So，我们要想提高单元测试效率的方式就一种，制造一种自动化的单元测试工具，该工具应该可以进行下面的一些工作：

     1.  实现多项目的管理。一个测试驱动的平台应该可以管理多个项目。
     2.  实现项目基础开发框架的生成。根据项目的包名自动生成springmvc+mybatis+spring的开发框架。
    3. 测试用例管理。测试用例包含持久层测试用例、服务层测试用例、控制层测试用例。
    4. Mock系统的生成，对于无法测试的第三方系统可自动生成mock对象，最终能够基于mock对象完成测试。
    5. 集成测试管理。测试系统可配置复杂情况下的集成测试。
    6. 测试代码生成。系统可根据设置的测试用例自动生成单元测试代码并执行。
    7. 测试报告管理。测试完成后可通过界面阅读测试报告。
    8. 基于git的托管。系统可以将生成的项目发布到git中，以实现对系统版本的控制。
   10. 界面模板管理。系统可生成界面基础模板及模板使用说明文档，第三方前端可提交自己的模板，该模板可以与生成的系统进行整合。
   11. 数据模型定义。后期可定义数据模型，根据数据模型自动创建数据库，支持导入pdm文件。
   12. 系统文档生成。系统能够自动写文档模板，包括：用户手册、管理员手册、测试报告、api接口、数据字典。
   13. 系统可实现压力测试。系统可以使用jmeter实现压力测试报告。
    14. 系统菜单的定义。可定义系统菜单。
    15. 系统原型生成。
    16. 持续集成系统。
    17. 安全扫描。
  
   想象一下，有了这套工具，我们在后面进行项目开发时的场景吧：
   1. 搞清楚用户的需求。可使用系统用例图（user case）进行捕获。
   2. 创建一个项目，指定项目需要使用的数据库、系统包的规划。
   3. 创建数据模型，建立好数据模型（可导入pdm文件哦）
   4. 定义系统功能菜单。
   5. 生成系统基础框架。
   6. 定义单元测试用例。
   7. 程序员根据单元测试编写代码，实现业务逻辑。
   8. 编写集成测试用例。
   9. 生成jmeter压力测试文件并运行。
  10. 安全漏洞扫描。
 11. 生成系统文档。
   12. 交付，放心的交付吧，因为测试做了很多遍了，不会有问题的。


                  理想中的软件建模方法，谁有兴趣呢？留言联系我一起讨论讨论。
       

无题

想不好题目，暂时就叫无题吧。写点什么呢？说说自己想说的话吧。

想在夜深人静的晚上写点东西，内心很矛盾的，想让人看，又不想让人看，其实是想让不认识的人看，现在的网络已经很难隐藏一个人的身份了，大家在网上都像透明人一样，无处藏身。

纠结了半天，还是觉得blogger是我的心声。

第一，国内无法正常访问blogger，我的关系都在国内，大家基本上不会碰见。

第二，发表的东西国外人可能看见，或许能碰到欣赏的人吧。

第三，我还是喜欢使用google的产品。

纪念帖

        好久没有写过博客了，记得第一次使用blogger.com是在十年前，那时候的我还是意气风发的少年一个，如今孩子都已经三岁了，不知道谷歌的博客什么时候可以在国内继续被访问，但这对我来说已经不重要了，因为我自己能访问就可以了。
        后面的日子我不知道会写些什么，但还是供自己十年后再来评价吧。