维护项目小感

现阶段我的主要工作是对项目的维护,一是对项目进行一些缝缝补补的工作,二是对客户提出的一些小的修改,进行修改,三是帮客户修改一些数据。

我发现项目的需求总是变动的,至少我们这边是这样的,虽然项目都已经上线使用一段时间了,不过一些小的变动总是不断的,而且同时也发现有时侯客户现在提的需求和原来的需求相差是比较大的,可能是客户自己当初没有思考清楚,也可能是当时调研时没有完全的搞清楚,当然也可能是因为事情就是在不断的变化的,所以面对变化,面对需求的变化一定要心平气和,我们本来就是来帮助客户解决问题的!再者就是在修改或者调研需求的时候一定要站在客户的角度来思考问题,否则未来会产生更多的问题。当然,自己的思考——客观的思考也是非常重要的,能帮助客户的一定帮,不能帮的也要解释的清清楚楚,至少要思考客户提出的需求是否可行,是否前后有矛盾的地方,是否使用现在的技术能够很好的解决,是否能有更好的解决方案!做事情之前,首先要将所有的问题都理顺都想通是非常必要的,正所谓谋定而后动,这样效率会更高成功的可能性会更高!

再者关于项目本身的问题,也有不少!首先,我发现前台页面的验证/后台数据的验证/数据库的设计,是非常重要的事情,如果在最初的时候没有选择适合的解决方案,往往后期会带来更多的问题和阻碍,比如:前台页面的验证,如果效果不好看,如果多名开发人员使用的方式不统一,如果用户觉得使用的体验度不佳,那么可以说这是比较失败的一种解决方案的!我们现在的这个项目就属于这种情况,前台页面的提示不及时效果不好看用户觉得不够详细,不够多样性。当然,也和项目本身的复杂性有关,也和当初调研时和用户沟通的程度相关!

我们的这个项目,后台的验证没有加上,对于企业级的开发来讲,对于普通的用户尚可,当然他们也不会故意的捣乱的,在前台页面中如果限制的比较好,也能保证数据的正确性/一致性/可用性。不过最好还是要加上这个验证的,这样的软件架构才是一个良好的软件架构!才能够进一步的保证数据的完整性和一致性!

数据库的设计,毋庸置疑是非常重要的!所以,这个工作交给即懂业务又经验丰富且技术上佳的人才对!对于主键/外键/索引/每张表的字段/字段的类型/长度/注释等等都要设计的非常准确合理,又有扩展性又能适应于现在的项目需求才是比较合理的一件事情!

另外就是事务的控制了,这件事情也相当重要,一定要统一/合理/在项目设计之初就找到一个非常合理良好的解决方案,否则数据库中就会出现许多莫名其妙的问题数据!幸好,现在也有许多比较好的解决方案以供选择的!

再者我也发现对于企业级项目开发的时候,对于前台页面防止表单重复提交的工作也是相当重要的一件事情,这个事情也必须在软件设计之初的时候就必须想到并且选中一种良好的解决方案(STRUTS的防止表单重复提交的令牌机制就是一个上佳的选择)!这样才能进一步的保持数据的一致性和完整性,也能避免因前台页面的表单重复提交而产生的各种莫名其妙的数据问题!

当然,软件设计中肯定还会有其他的各种各样的问题,这也是很常见和很正常的事情!其他的我也不再在此列出了,以上这些问题是我在项目开发和维护的过程中遇到的,对于他们因自身的不足而产生的问题和麻烦,我是深有体会的,所以在此稍微列举一下,以便加深些印象对于以后的项目开发中有所借鉴和防范出现上面的这些问题!

时间: 2025-01-04 15:04:48

维护项目小感的相关文章

维护项目的敏捷转型

现在敏捷已经是IT行业的开发的行业标准了,大部分公司在产品开发中都采用的敏捷来解决一些由瀑布模型带来的问题. 敏捷的迭代周期短,每个迭代都有预设目标,而且每个迭代都有相应的产出,能大大地提高项目相关人的满意度. 产品开发的一个典型周期是: 需求澄清->开发->测试->发布->维护. 而当产品成熟后,新的功能和改进将会越来越少,同时维护和客户支持的工作量则会越来越大.维护则包括:技术支持.项目管理.工程维护.版本管理. 对于成熟的组织来说,瀑布模型是所有根据客户的要求进行的维护活动(

测试小感1

本人自从事测试以来已经3个多星期了,一直都是在手动的进行功能测试,在测试的过程中发现很多问题,但做为一名新入职的实习生也不好说什么,毕竟自己还没真正对这个多年组合起来的开发团队模式进行深入的了解过,看到的也可能只是一些表象的东西. 1:测试分工不明确. 2:开发过程对于测试和产品人员来说不透明. 3:需求变更快,但变更后信息传达却比较慢,只有提出需求变更和修改确认的人员明白,但其他未能参与的人员不能及时了解进度便会造成一些无用功. 4:产品和开发人员不能很好的协商解决确认功能的话,则某些bug的

投影机使用维护保养小常识

投影机使用维护保养小常识 随着教育信息化进程的不断推进,各级各类学校都斥资兴建了多媒体教室.LCD投影机是多媒体教室中最重要的设备之一,又非常贵重,因此维护并保养好投影机成为投影机在使用时,有些用户要求信号源和投影机之间有较大距离,如吊装的投投影机是一种精密电子产品,它集投影机在使用时,有些用户要求信号源和投影机之间有较大距离,如吊装的投影机一般都距信号源15米以上,这时相应信号电缆必须延长.由此会造成输入投影机的信号发生衰减,投影出的画面会发生模糊拖尾甚至抖动的现象.这不是投影机发生故障,也不

一些好用的项目小工具

sublime text 2代码编辑器 xmind思维导图 sourceinsight代码阅读器 一些好用的项目小工具,布布扣,bubuko.com

数据库监控和日常维护项目

序号 设备类型 内容/参数 参数类型 备注 1 操作系统层次  系统日志 状态  检查日志的err或warning  进程数 性能参数  检查系统进程数是否相对稳定  系统CPU利用率 性能参数  参考值 Idle > 50%  系统内存利用率 性能参数  参考值 free > 10%  系统IO请求数/秒 性能参数  参考值 < 4000  系统IO请求量/稍 性能参数  参考值 < 100M  网络流量 性能参数  空间使用率 性能参数  参考值 free > 10% 2

美团面试小感——认知撑起的格局

前两天因准备美团的面试,导致公众号文章断更了一天,今天就以一篇纯干货来弥补大家.美团的整个面试收获颇丰,与大家分享. 好多年没有面试了,为此专门准备了一天.在美团一个下午经历了四个多小时的三轮技术面试,才发现为面试所准备的面试题几乎无用,整个过程全靠临场发挥和经验积累. 面试之后对整个过程进行复盘.反思,又有了很大的收获,而且这些收获有必要分享给大家.下面会从面试题的学习感悟."面试"你的面试官.认知与格局等方面与大家聊聊. 缘起 一直在用美团的产品,但真正对美团印象深刻的却是它的技术

全栈项目|小书架|服务器端-NodeJS+Koa2实现首页图书列表接口

通过上篇文章 全栈项目|小书架|微信小程序-首页水平轮播实现 我们实现了前端(小程序)效果图的展示,这篇文章来介绍服务器端的实现. 首页书籍信息 先来回顾一下首页书籍都有哪些信息: 从下面的图片可以看出目前一本图书信息主要有: 图片字段 名称字段 作者字段 出版社字段 除了以上前端页面中可见的信息外,在服务器开发中还需要给每一条记录(数据)都加上下面的几个字段: 创建时间字段 更新时间字段 删除时间字段 最后完成的数据库表如下: ps:由于数据库是直接导入的,之前的数据库是没有时间字段的,所以前

全栈项目|小书架|服务器端-NodeJS+Koa2 实现书籍详情接口

通过上篇文章 全栈项目|小书架|微信小程序-首页水平轮播实现 我们实现了前端(小程序)效果图的展示,这篇文章来介绍服务器端的实现. 书籍详情分析 书籍详情页面如下: 从上图可以分析出详情页面大概有以下几个接口: 获取书籍详情信息 获取用户对书籍的喜欢状态接口 喜欢/不喜欢书籍接口 获取评论列表 写评论接口 以上的接口,有的数据可以直接从已存在的数据表中去获取,比如:书籍详情信息,而其他新接口就需要创建对应的model,然后根据model创建相应的数据表. 比如 用户对书籍的喜欢操作,可以创建li

个人项目小总结

终于完成了“简单”的个人项目,我内心稍有拨动.由于各种因素,我的个人项目启动稍晚,后来因电脑不好使借了室友的电脑,着实命途多舛.我的开发大概分为两个阶段.第一个阶段是实现读入算式,切分文字,中缀转后缀并计算结果.当然,是小数结果.以算法知识尚在,而一气呵成.第二阶段是写分数类,并实现之.本以为更易,然遇难于实现.我自以为分数类编的十分规范完备,然而想了一整天才想明白如何实现.经测试之后终于完成. 这个是我的分数类: 1 //分数类 2 class fraction 3 { 4 private: