• 档案一期总结


        折腾了大半年,总算一期总算是收尾了,从需求开始,到数据库的设计,到项目的搭建,到编码、测试,得到第一个上线版本,需求变更,再修改,又是编码、测试,来到了第二个上线的版本。幸运的是需求只有一小部分的变更,继续修改bug、测试,2个星期又出新的版本。根据用户的意见开始无尽的细节修补,一直持续了2个多月,至今仍然有小bug,呵呵,留二期了!至今系统已经运行了将近3个月了,维护期也临近尾声了。
        回顾这一过程,有通宵,有偷懒,也有投机取巧的时候,当然也导致后期交了更多的学费。
    一、技术方面
    1. 代码路劲、分支考虑不周全,有多个情况时候(if…else)判断没有封死。
    2. 代码不够简洁,思路不够清晰,注释的质量有待提高,某些代码太绕弯了,过于冗余,应该理清思路在写代码。
    3. 没有利用好已有代码(比如框架生成的代码)已经封装好的类、方法、组件,很多底层代码是不需要自己编写,直接调用封装好的接口即可。
    4. 页面尽量用标签(如,<c:forEach>,<c:if>等)而不是用原始的jsp表达式(<%=var%>)
    5. 数据库设计不完善、字段不完善等,给后面的编码增加的难度
    6. 代码没有统一的规范、统一的调用位置(sql语句统一写在service层或者统一写在dao层),方法的命名方式应该使用统一的格式:
        6.1 保存方法:saveXXX
        6.2 删除: deleteXXX
        6.3 修改: updateXXX
        6.4 查询: findXXX
        6.5 判断: isXXX
        6.6 初始化:initXXX
        6.7 销毁初始信息:destoryXXX
    7. 模块间的耦合度太高,分离程度不够
    8. 代码中不能有写死的路径
    9. 代码应该使用统一的结构:action --》 service  --》 dao --》 底层处理接口 -- 》 数据库
    10. 测试不够细致,由于成员都是自己开发自己测试的,没有站在用户的角度测试系统,导致很多细节直到上线才发现,给用户造成不好的印象

    二、管理方面
    1. 任务、功能点分配不合理,没有理出项目的难易点,使得在分配的时候没有做到因人而异,有些人轻松有些人繁重,导致项目延迟
    2. 对小组成员的代码审查不到位,没有及时发现不良的代码习惯
    3. 成员间的沟通不够,应该多开几个小会讨论讨论
    4. 告诫小组成员做好每个动能点的备份,以防意外
    5. 项目赶工的时候特别注意svn的冲突问题,避免同时有多人修改同一份文件
    6. 对用户的需求理解不到位,常常要多次跟用户沟通才得到用户真正想要的功能

       虽然一路上问题一大堆,但是总的来说,对于每位小组成员都有了很大的进步。希望通过一期的经验与教训,在二期的能做的更好、更出色,给用户一个满意的软件。

    版权声明:本文为博主原创文章,未经博主允许不得转载。

  • 相关阅读:
    Python教程(2.2)——数据类型与变量
    Python教程(2.1)——控制台输入
    Python教程(1.2)——Python交互模式
    (译)割点
    Python教程(1.1)——配置Python环境
    Python教程(0)——介绍
    [HDU1020] Encoding
    [HDU1004] Let the balloon rise
    扩展中国剩余定理 exCRT 学习笔记
    51nod 1943 联通期望 题解【枚举】【二进制】【概率期望】【DP】
  • 原文地址:https://www.cnblogs.com/ubuntuvim/p/4796536.html
Copyright © 2020-2023  润新知