如果要应用到项目中那还是有原则的,比如:A.不能简化代码量的,不用;B.难以上手的,不用;C.不稳定的,不用;D.自己造轮子的(缺乏可持续维护),不用。
基于这几个原则,目前热门技术中,我们不用EXT或者Flex,因为它违反了A和B;不用ibatis,因为违反了A;不用GWT,因为违反了 B;基本不用微软的方案,因为很多MS的方案都违反C;而不自己造轮子,尽量基于标准的Spring/Struts2/Hibernate框架,则是处于人员更迭和维护的考虑,具体可参考J2EE design and development without EJB;我也后悔用Mina,因为缺乏持续性的维护,这方面显然不如netty和grizzly。
前阶段开发中存在的问题, 及改进建议(下面提到的问题在任何软件公司都会碰到,所以出现也是很正常,在今天讨论后,建议大家在今后的团队运作中尽量避免)
1、前期需求不明,造成设计时目的不明确,开发时时常会因需求问题而困惑,测试人员也会提出一些需求建议,而由于已经开发完成,所以改动起来比较困难。
改进办法:需求要完全明确是很难做到,但在局部相对独立功能上应该要尽量明确。如:尽量能明确注册需要哪些信息、每个表单是用什么控件、处于什么范围、列表显示哪些字段、查询需要什么条件有明确的说明,这样可以在后期测试时少掉一半的需求建议或bug。
2、原系统有规范但没有较好的执行,由于团队初成立时,无人严格把控各人的代码规范、文件存放、命名等等都存在着很大的问题,而这造成的结果就是后改代码的时间比前面写代码的时间还要长。
改进办法:项目组长需要每天都check成员代码,保证每天的代码都是相对规范。
3、设计要慎重,应该要足够的考虑,以及和团队的商议,原系统中有一些数据库表的结构和字段值得商榷,如果前期可以大家讨论一下,也许很多问题可以在后来重构中避免。
改进办法:没有人能一次就设计出完美的东西,需要及时的沟通,包括与客户的反馈,与其他项目组成员的讨论,这样有助于降低开发时偏离需求的风险。也就是说,在开发之前题,是建立在设计者的想法有客户的确认和开发人员的理解的基础之上。
4、开发时因分工不明确,每个页面可能团队所有的人都有修改,这其实出问题的风险是非常大。事实证明,由于数据库存储过程是专人负责,所以不必要的
Bug相对较少的,而UI层的不少问题其实都是后者根本不清楚前者的代码意途所致(必要的注释是起码的习惯,松耦合的code是更好的代码风格)。
改进办法:数据层、逻辑层、UI层,以及UI的各个功能分工,都需要责任到人。
5、代码中重复代码较多,维护时时常会改了一处Bug,却在另一处出现同样的问题,这显然是重复带来的灾难。
改进办法:开发时,只要是重复代码,就需要考虑是否可以提炼成为函数,并考虑存放到合适的类中(也包括页面html的重复),严禁简单的Ctrl+C到Ctrl+V,这种避免重复代码的做法看似相对麻烦,其实是可以大大减少维护风险。
6、计划不能按期完成,大致三种原因,1、计划不合理;2、人员没有抓紧;3、因其它计划外的原因造成延误
改进办法:制订计划项目组长需与相关成员讨论以决定计划完成日期,制订时间需要科学合理,如果明确后,相关成员需要尽量按时完成,若有特殊原因,比如技术难题,计划外的事情耽误等等,需要给出理由。再由组长和成员共同商议解决时间,以保证全局的进度不受影响。
7、早期没有存储过程测试,单元测试,页面测试因需求不明,造成测试人员既是测试者又是需求提出和建议者。
改进办法:需求制订过程需要测试人员全面参与,达到了解足够充分。测试时针对需求做测试用例,以需求为标准,判断开发是否完成或有否错误。
8、前期页面比较混乱,页面布局、样式比较混乱,到处都有如居中、加粗等html语句、列表显示有5种样式等等,造成后期重构非常麻烦。
改
进办法:美工应该在需求制订完成后就介入,进行页面设计,然后.net的aspx页面需要有专人处理,所有的样式必须全部用css统一完成,表单验证、页
面跳转需要在开发前完成(甚至最好可以经过测试),这需要界面设计人员(可能是美工也可能是架构师或界面专人)对需求充分了解。
9、项目计划和管理主要以Email和口头传达,过后无法跟踪,造成时间表不明确,人员工作效率不够高,有时很紧张,有时很轻松。
改进办法:需有项目管理工具,比如VS 2005 Team System或其它项目管理系统。每个人的工作任务需在其中体现,计划安排和调整,相关负责人,延误备注都需要记录。让开发人员保持一个长期的、恒定的开发速度。
总之,由于早期开发时团队人员不整、需求不明、规范实施不利、计划有误等等原因,造成系统开发出现些了问题,但之后有了一定的时间,所以重构已经取
得了不少成效,但所谓磨刀不误砍柴工,前期的准备如果充分一些,对后期的维护就会好很多很多。由于时间关系,前期不可能做非常详细的设计,事实上,即使做
了详细设计也可能因需求的变更而效用不大,所以更多的是需要大家写出可维护性、可扩展性和可复用性较好的代码,以便更好的适应变化。
最后,以软件大师Robert C.Martin的名言与大家共勉
个体和交互
胜过 过程和工具
可以工作的软件
胜过 面面俱到的文档
客户合作
胜过 合同谈判
响应变化
胜过 遵循计划
虽然右项也具有价值,但我们认为左项具有更大的价值。
分享到:
相关推荐
### Web开发人员工作心得:成长与挑战 #### 核心知识点提炼 1. **学习与适应:**在Web开发领域,技术更新迅速,持续学习至关重要。对于初入行业的开发者而言,掌握新技能、理解现有技术框架是成长的关键。 2. **...
- **瀑布模型** 是一种线性的开发方法,每个阶段有严格的顺序,前一阶段完成后才能进入下一阶段,缺乏灵活性。瀑布模型注重文档,但这种文档驱动的方式可能导致开发过程过于僵化,无法及时响应变化。 - **敏捷开发...
一、团队开发会议 * 每周一晚8:00召开小组成员讨论会,地点在紫荆公寓XXXX。 * 小组成员讨论会的主要内容包括总结上周的课程内容和开发进展、商讨本周软件工程项目的开发情况。 * 每位组员需要表达个人的学习心得,...
Java项目开发心得分享 在Java项目开发过程中,我们往往能够积累丰富的经验和技能,尤其是在一个团队环境中,协同工作、解决问题和持续学习是提升的关键。在这个特定的项目中,我们的部门成功地组建了一支高效的JAVA...
这种方式强调团队协作,通过频繁的沟通和回顾会议来调整方向,确保团队始终专注于最有价值的工作。 在我们的研发团队中,我们采用了敏捷开发的方法来管理项目。首先,我们明确了团队开发目标,将大项目分解为多个可...
通常,实习生会在实习结束后撰写心得体会,总结实习期间的学习经历和成长,为自己的职业生涯打下基础。在实际工作中,实习生应该学会如何快速适应环境,如何在实践中学习并提升自己的技术能力,以及如何建立良好的...
《OpenMeeting开发心得及相关文档》 在开源世界中,OpenMeeting是一款强大的在线会议软件,它提供了视频会议、即时消息、白板、文件共享等多种协作功能。这篇文章将基于开发者角度,探讨OpenMeeting的开发心得,并...
软件开发实习总结篇一对软件开发的经验心得 在软件开发实习过程中,我深深体会到了作为一个合格的程序员应该具备的基本素质。团队精神和协作能力是程序员应该具备的基本素质,这一点在最近的工作中让我深深休会到了...
每个团队通常包括产品经理(PL)、软件工程师(SE)、系统工程师(SWE)、测试工程师(TE)和技术支持工程师(TSE),他们共同协作完成项目。团队成员需要明确角色,建立共同的目标,并创建一个支持敏捷工作的办公...
通过上述内容的梳理与总结,我们可以看出软件开发不仅仅是一项技术活动,更是一个涉及多方面考量和团队协作的过程。无论是从个人技能的提升还是团队整体的合作角度来看,每一个环节都需要精心准备和执行,以确保最终...
每个Sprint结束后,团队回顾工作,调整下一步的计划,确保满足客户需求。 总的来说,Scrum通过灵活的流程、密切的团队协作和持续的反馈机制,提高了软件开发的效率和质量。它不仅适用于大型复杂项目,也可以很好地...
通过定期的会议和经验交流,销售人员能够相互学习,取长补短,从而推动整个团队的进步。这种文化的建立能够促进知识的积累和技能的传承,提升团队整体水平。 客户关系管理是现代销售工作中的核心环节。重视客户分类...
因此,尽管文件标题和描述指向了数学老师的工作心得总结,其背后所蕴含的深层次原则和方法却在技术行业同样适用。下面,我将从团队协作、个体差异的关注、持续学习以及实践与反馈四个角度,将数学教育领域中的经验与...
以下是我对这一年来工作的一些总结和心得。 首先,面对【门禁系统】与旧的打卡系统的共存问题,我建议剥离门禁系统的考勤功能,以避免不必要的系统移植和额外开发成本。通过仔细记录和调试,最终确保两个系统能够...
【描述】:本文汇总了多个程序项目的心得体会,强调了在IT行业中,技术知识固然重要,但处理问题的方法、心态和团队协作能力同样不可或缺。通过实例,讨论了项目经理的角色、会议效率的重要性以及尊重程序员的价值。...
通过实训,作者体验到了从项目启动到完成的全过程,并分享了关于高效会议管理、团队合作、员工尊重及项目管理工具应用等方面的见解。 【标签】:互联网 【内容解析】: 1. **团队协作与领导力**:在项目中担任...