软件开发专业实习心得Word格式文档下载.docx
- 文档编号:17163734
- 上传时间:2022-11-28
- 格式:DOCX
- 页数:4
- 大小:18.67KB
软件开发专业实习心得Word格式文档下载.docx
《软件开发专业实习心得Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《软件开发专业实习心得Word格式文档下载.docx(4页珍藏版)》请在冰豆网上搜索。
作为一个程序员,对需求的理解能力也是很重要的,只有真正理解了一个模块的作用,才会写出高效率的代码,才能使整个软件项目作出来更加优秀,具备更好的安全性和稳定性,我在写代码的过程中就遇到了需求理解上的问题,使得写出来的代码功能不全,幸好不是给客户发现在,要不,这个软件的商业价值可能就会打折扣了。
单元测试对于一个程序员来说是不可不做的一项工作,不做好测试就会给后期的集成工作带来麻烦,往往为了一个小问题会让我们查找好多模块,给后期工作带来很大麻烦。
这一段时间的工作也让我明白了一点:
一个优秀的程序员必须不断的学习,随时总结,找到自己的不足,这样逐步提高,才能让自己很快的成长起来。
建站侠客发表于2008-4-2810:
19
对软件开发的一点心得体会
一、前期规划:
我理解的前期规划是:
在市场人员们汇总一个需求提交给产品专家带领的产品经理团队,然后经过这个团队根据公司具体情况再次分析和规划出一个最终需求文档。
这个需求文档应当首先提交给技术研发部门的负责人以及核心开发人员。
由开发团队对其进行技术和风险分析。
如果对此需求统一有异议的地方,需要返回给产品团队,重新修正需求。
反复如此,直至需求完善准确,细致,清晰。
前期规划就像高楼的地基,如果马马虎虎,就算是一块砖块没摆好都可能导致整个高楼建设的失败。
在规划中我认为,交流永远是需要双方积极主动,能认真听取每个人的建议。
前期工作思维不慎重,不细致,不认真,不够完善,将产生连锁效应直接导致整个工程和项目的失败。
这种失败可能表现为:
第一种,软件按需求实现但是功能根本不能满足用户需要。
第二种,功能都有了,软件没有达到可用性、易用性。
对于第一种,当然是因为前期规划疏漏了某些细小功能,没能把需求文档做完善。
应该是规划工作做的还不够认真和细致。
对于第二种情况,我认为更多是在产品设计规划方面经验还不够成熟。
这种问题应该是很难避免的。
因为每种新产品对产品团队来说都很陌生。
即使以前做过类似的东西,也难免面面俱到。
这只能通过不断努力和认真的态度来弥补。
前期规划的交流涉及了市场、产品和技术研发等多个团队之间。
需要的不仅是团队内部的交流,更多需要协调好团队之间的交流。
可能有时候需要公司高层和中层参与协调。
目前,很多开发人员深感项目的需求文档写的都很单薄。
大家可以想一想,如果没有好的开始,怎么会有好的结束呢?
需求文档单薄,不够细致,由谁来继续完善呢?
难道让程序员们自己去完善。
我想程序员也可能没有这种能力。
对于程序员能把代码写的很健壮很稳定就已经是很不容易的事情了。
二、概要设计:
我理解的概要设计步骤:
(以项目为中心的开发流程)
1〉项目经理仔细阅读项目需求文档。
2〉项目经理召集项目开发成员,开项目启动会议。
具体商议项目的开发任务和责任分配。
3〉核心开发人员开发确定,以及各模块开发人员确定。
4〉由系统分析员和核心开发人员仔细阅读需求文档,对系统整个架构分析和做技术规划。
5〉系统分析员整理和书写最终的系统架构和概要设计文档。
6〉系统分析员在文档提交日,提交给项目经理。
项目经理确认文档并审批。
7〉项目经理召集项目开发成员,开一个概要设计以及系统架构确定的会议。
向每个成员分发文档,并讨论确定最终概要设计文档。
8〉开始详细设计文档的工作
三、详细设计:
1〉项目经理组织成立各个模块的开发小组,并确定开发小组组长(程序经理)。
2〉各开发组长书写各自模块的详细设计文档,开发成员需要协助,配合。
3〉在指定提交日,开发组长提交文档给系统分析员。
由系统分析员审批。
4〉系统分析员组织召开一个详细设计文档确认的会议。
5〉然后开发组长分发各自模块的详细设计文档给程序员,程序员在指定时间内完成。
6〉程序员做内部测试。
开发组长协调并配合。
7〉确认无bug提交给开发组组长。
8〉所有模块整合工作,由整个开发组成员参与完成。
由所有开发组长和系统分析员负责主要部分工作。
程序员协助和配合。
9〉对整合后工程做详细测试。
10〉确认测试通过后,开发组长根据开发成员表现以及提交成果填写绩效考核表。
然后提交给项目经理。
11〉项目经理会召开项目总结会,同时向优秀成员颁奖。
同时鼓励所有成员继续努力。
对不能按时完成导致项目能按时提交,以及对导致失败的关键人员给与惩罚处理。
当然,以上只是一个简单的开发流程,一定是有很多不足的地方。
希望能起到抛砖引玉的作用。
大家都明白,流程和制度是死的,但人是活的,所以如何按流程做得好,关键还是在人本身了。
没有一个流程和制度,一个团队也必将是一盘散沙。
正所谓“无规矩无以成方圆”。
这句话说得很有道理。
四、具体编码:
开发几个项目之后,对编写程序有了更进一步的了解。
好的程序应该具有:
易读性,易扩展性,容错性。
易读性:
所有变量和函数以及类名用简单易懂易记忆的命名方式。
所有类和函数甚至变量都有关键的注释说明。
这点很重要,也是最基础的。
如果代码书写不够美观和易懂,我想自己以后也不想再看。
就更别谈功能的扩展和新版本开发了。
易扩展性:
整体系统架构逻辑简单清晰。
模块与模块之间尽量做到互不影响,也就是尽可能的独立。
这部分工作主要体现在前期设计工作中,需要掌握好的设计经验和方法才能够做得比较好。
容错性:
对数据流和指针以及数组都做数据有效性检查;
对第三方接口的调用失败的容错性。
对所有代码都做调用失败后的错误处理。
以及在大的工程中加入trace文件输出,把关键的数据流和关键处理部分的操作信息输出。
以便对工程异常情况产生条件的定位,及时解决问题。
我觉得程序员能在这三方面做得很好就算一个优秀的programmer了。
五、调试、跟踪与测试:
1测试需要注意的:
对每个模块的接口做测试,数据边界的检查。
在对整个模块做测试。
主要测试稳定性,效率以及功能是否正常。
确认单个模块完全正常后,再加入工程。
在系统架构设计的时候,可能会引入原型参考。
要对原型做完成测试后,确认没有问题后,才可使用。
2可以采用VC自带Trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息,以便定位程序异常的原因。
3对于通信模块的测试,特别注意服务端和客户端的数据流。
可以针对性的写一个客户端或服务端的测试程序,检验通讯过程是否正常。
4在用VC做开发中,一定先要让Debug版本正常运行,保证没有任何异常,内存泄漏和Assert等调试警告信息。
如果用到其他Lib,一定要保证Lib本身不存在问题。
这里只是提到一些自己容易忽略的东西,希望能对大家有所帮助,欢迎指正!
谢谢。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 专业 实习 心得