软件开发心得总结

2022-07-27

叹岁月流逝太快,转眼间便到了年底,一年的辛苦工作中,我们留下了太多的难忘时刻,也在不断的工作积累中,成长为更好的自己。为了记录这一年的工作成长,我们需要写一份总结,以下是小编收集整理的《软件开发心得总结》,欢迎阅读,希望大家能够喜欢。

第一篇:软件开发心得总结

软件开发心得总结

有感于网盘开发过程

有感于网盘开发过程 .............................................................................................................................. 1

一、软件开发个人体会: ................................................................................................................. 2

二、做软件开发我觉得要明白: ..................................................................................................... 2

三、在开发中遇到问题应该怎么去解决? ...................................................................................... 2

四、怎么样才能提高自身的能力?.................................................................................................. 2

五、怎么样才能做好软件开发? ..................................................................................................... 2

六、文档的重要性 ............................................................................................................................. 3

七、我的收获 ..................................................................................................................................... 3

八、网盘项目开发的最大体会 ......................................................................................................... 4

九、软件测试(单体测试和连接测试) .......................................................................................... 4

常熟理工学院SIG小组

3/28/2013

一、软件开发个人体会:

1. 软件领域中的知识在于积累。

2. 做软件开发,就类似算数学题和世界杯足球赛一样:重在结果,而不在乎过程。 3. 软件服务于人类,软件是在解决一些生活中的问题和错误,问题决定解决方案。

二、做软件开发我觉得要明白:

1. 职业的乐趣:

(A) 用自己的智慧去创建新事物的快乐 (B) 开发对别人有用的东西 (C) 不断学习来充实自己 2. 职业的苦恼: (A) 总是追求完美

(B) 所有要实现的功能由他人而定

(C) 概念设计计是有趣的,但找Bug总是很苦恼的

三、在开发中遇到问题应该怎么去解决?

1. 2. 3. 4. 不明白就多问,不要自已一直去琢磨。

一个问题如果30分钟还没有解决就应该考虑是不是问问别人。 一个问题在没有用过3种以上的方法解决过就不要去问别人。 解决问题思路是关键:

相信问题总归有解决的办法,就算连技术上都没法实现的问题,相信通过良好的沟通终究也会有解决的方法。

5. 解决问题的前提是:理解别人的意思,理解别人的需求,多沟通,及时给客户反馈信息。

四、怎么样才能提高自身的能力?

1. 程序员怎么样进步最快? - 理论结合实践

2. 不要怕出错,不怕遇到错误,有错误就有挑战,这样才可以进步,但不要让同一个石头把你绊倒2次。

五、怎么样才能做好软件开发?

1. 首先要明白解决的问题是什么,理解问题,其次再决定怎么解决这个问题 2. 碰到很复杂的问题,我们就简单想,把问题简单化,细化到能够实现为止

常熟理工学院SIG小组

3/28/2013

3. 出了问题,我们要先分析问题,然后知道引起问题的原因,最后并想出问题的解决办法 4. 我们应该从2个方面去把握一个项目:从业务角度和项目的关键问题上去把握一个项目

(A) 从不同的系统场景

(B) 从不同的用户角色(充当什么角色) (C) 从不同的系统使用角度(拥有那些权限)

5. 其实我觉得开发人员说实在应该要比使用系统的人更了解系统需求,只有真正彻底的了解了项目的业务需求,我们才能做真的做好这个项目

六、文档的重要性

记得我当初刚开发项目的时候都是写个大致的需求说明书,做一个E-R图,画几个大致的数据流程图,然后建立数据字典和表结构关系。 再接着搭建一个开发环境,配置几台服务器,划分一下模块,分工,我们就可以Coding了,一直到项目结束了,也没有完整的设计文档,更没有完整的测试文档,虽然这样的确是很快的完成了Coding工作,感觉上好像节省了好多成本和开发时间,但后期的维护和Bug 就是经常出现的事。

小项目没有文档关系不大,但如果遇到一个大项目的时候,那这样的开发方式就很有问题很危险的。

大项目没有文档: 首先维护就很麻烦,也很乱,写的代码,过几天都不知道它是完成什么功能的了,其次系统的稳定性和可靠性也让人怀疑,扩展性就不用说了。

七、我的收获

A.程序员大多都不喜欢写文档,我们以前也是特讨厌,记得以前都是系统开发完了,为了应付项目验收,就匆匆忙忙的一组人在那里补文档。在我们的思想里,所谓的文档就是一些废话,一句话硬是用十句话来代替的无聊透顶。 B.代码风格要规范

以前做项目,我们都是不怎么去注意代码风格和写代码的规范,都是稍微想一下就直接开始写代码了。注释也很少用,总感觉我们自己写的代码,我们怎么会不知道它做了些什么事呢 ?总觉得我们自己写的代码我们怎么会不知道它是用来做什么的呢。一直都不相信这是个事实,但事实上,项目验收后,系统刚开始使用的人少,也就不会出现潜在的错误,随着时间的增加,久而久之,当大量用户并发访问的时候,系统的Bug 就暴漏出来了,那时你再用熟悉的Eclipse打开整个项目的源码时,再去看自己写的代码的时候,真的发现,我们定义的这个变量名是什么意思啊 ? 我们的这个Flag 是用来判断什么的啊 ?我们的if()中条件不知道是判断什么? Function () 也忘记是什么功能了? 想想好可怕啊。 难道真的都忘记了吗 ?回答是肯定的: 真的忘了。 C.心得体会: 通过做该网盘项目,在这2年的锻炼中,我们才真的体会到,良好的文档是正规研发流程中非常重要的环节,一个好的程序是先写好设计文档再进行编程的,在设计文档的指导下,才能写出安全的代码。如果你不写文档,一开始就写程序,这样你就不会按已设计好的路线走,而是想到哪写到哪。小功能还好说,要是大功能,就容易混乱.

常熟理工学院SIG小组

3/28/2013

刚开始我们还很不习惯这一系列的编程风格,很多的规范,尤其是命名,方法和注释,都有这着很多限制,让我们觉得真罗唆,写个程序完成功能不就可以了吗,明明1小时做完的事情非得让人用

3、4个小时去做,我们现在真的明白这样做的好处了,我们已经习惯这样的编程风格了,这也养成了我们的一个编程习惯了,深有体会啊。

最忙的时候就是我们成长和收获最多的时候。

八、网盘项目开发的最大体会

我们觉得项目开发的开始时候,应该由项目负责人很好的对项目是什么项目,具体大概做什么事情,是谁提出来的,目的是解决什么问题,以及里面用到的很多专有名词做个细致的说明,而不是从一开始就分几本式样书,给个静态Html 的Demo看看,然后搭建好开发环境就按照式样设计书来开发。

九、软件测试(单体测试和连接测试)

我们首先认为,编写程序的时候不要想出了问题再解决,而是要想如何不会出现问题,要根据经验来预测可能出现的问题,然后避免出现。

测试,说的直接点就是给软件找错误。

很多人认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上我们不这么认为。

我们觉得对开发人员来说,我们要把测试出来的Bug都应该做个分析,知道错的原因之后,我们就应该在下个项目中防止类似的错误发生,而真正来提高我们开发的效率。

常熟理工学院SIG小组

3/28/2013

第二篇:《ASP.NET程序开发》心得总结

短短的四个月很快过去了,在这短短的四个月里,我学到了很多,了解了很多。经过一个学期的简单学习和上课听讲,初步掌握了ASP.NET动态网页制作的一些简单的知识和基本常识,也能从老师讲的基本知识中简单的应用一下上课所学到的知识。

开始学习后也并非是想象中那样顺利,开始的学习让我异常感到学习任务的艰巨,因为学习中我们遇到了很多以前未曾遇到的难点,有时难免冥思苦想也无济于事。曾经看到网上有这么一句话,一个优秀的网络程序员不但要了解自己领域的一些专业技术,而且很多时候还要充当半个网络工程师,半个美术设计师和半个数据库管理员。照这么说来,我单单学习ASP.NET是远远不够的,还要学习计算机网络、美术设计、数据库,我很喜欢有关计算机方面的东西,认为我们当代的生活越来越离不开计算机,并且我也很痴迷计算机所带来的强大功能。

首先感谢老师的教诲,经过这门课程的学习,我的收获如下: (1)进一步巩固和加深“ASP动态网页设计”课程的基本知识,了解ASP动态网页设计知识在实际中的应用。

(2)综合运用“ASP动态网页设计”课程和先修课程的理论及生产实际知识去分析和解决问题,进行的相关训练。

(3)学习ASP动态网页设计的一般方法,了解和掌握通用数据库的连接、数据的相关操作或网站的设计过程和进行方式,培养正确的设计思想和分析问题、解决问题的能力,特别是网站功能规划的能力和实现相关功能的能力。

(4)通过本程序的开发,并对电子商务系统的系统的分析、系统设计、数据库设计和功能的实现等,培养ASP动态网页设计的基本技能。

在本次课程设计过程中,我学到了好多东西。在此特别感谢老师教诲。老师不仅上课生动、幽默,平时上机时又悉心的指导。同时感谢学校给我们提供了非常优越的设计环境,对于我顺利完成这次课程设计起到了关键性的作用。通过开发本系统,我较全面的掌握了ASPT及SQL的基本知识和编程技巧,并在开发过程中我的ASP.NET开发能力得到了进一步的提高。如: SQL语言的使用;以前学过的软件工程知识、数据库原理及操作也得到了充分的应用。

在开发过程中我学到了一些经验:系统分析的好坏将决定着的系统开发成功与否,一份好分析设计将是成功开发主要因素。我们在着手开发之前不要急于编程,先应有较长的时间去把分析做好,做好数据库设计工作,写出相关的开发文档等。然后再开始编写程序代码,这样做到每写一步代码心底有数,有条不絮。当然也有些还需待继续深入地方如:COM技术等。

在这短短的几个月中,我知道在程序设计的时候,不要太在意程序是否最简洁灵活,对于一般开发者而言,程序规范化和可读性可能比追求程序的灵活性更加重要。在互联网资源越来越丰富的情况下,我们可以参考一些规范的程序源代码来学习。同时我也知道,想要学好这门课程,所要具备很多条件,首先打代码要规范,要做注释,这样回头来看程序时可以很快的看懂,一方面可以练习自己的逻辑表达能力,对以后遇到难以实现的功能也可以很好的表达出来向别人请教,而且出去从事编程工作的话,代码的规范是相当重要的。还有一点要学会总结,把自己做的程序用到的知识点列出来就可以很好的总结自己的知识点。当形成知识体系,对知识的理解就会更上一层楼。

13级软件班

***

2015年7月1日

第三篇:金蝶财务软件的操作流程-高手总结心得

金蝶财务软件的操作流程

有外币:录入凭证→审核凭证→凭证过账→期末调汇→凭证审核→凭证过账→结转损益→凭证审核→凭证过账→期末结账,

没有外币:录入凭证→审核凭证→凭证过账→结转损益→凭证审核→ 凭证过账→期末结账,在金蝶软件里面凭证审核是可选的。 具体

一、凭证处理

1、摘要栏两种快速复制摘要的功能,在下一行中按“..”可复制上一条摘要,按“//”可复制第一条摘要。同时,系统还设计了摘要库,在录入凭证过程中,当光标定位于摘要栏时,按F7或单击「获取」按钮,即可调出凭证摘要库。选择所需的摘要即可,在这个窗口中,您还可以新增、删除或引入摘要;

2、会计科目栏会计科目获取——F7或用鼠标单击窗口中的「获取」按钮,可调出会计科目代码;

3、金额栏已录入的金额转换方向,按“空格”键即可;若要输入负金额,在录入数字后再输入“-”号即可;

4、金额借贷自动平衡——“CTR+F7”

5、凭证保存——F8

二、凭证审核

1、成批审核——先在凭证查询中,“凭证查询”→“全部、全部”,选文件菜单中的“成批审核”功能或按“CTR+H”即可;

2、成批销章——先在凭证查询中,“凭证查询”→“全部、全部”,选文件菜单中的“成批销章”功能或按“CTR+V”即可;

三、凭证过帐

1、凭证过帐→向导

2、凭证反过帐——“CTR+F11”

四、期末结帐

1、期末结帐:期末处理→期末结帐→向导

2、期末反结帐:CTR+F12

五、出纳扎帐与反扎帐

1、出纳扎帐:出纳→出纳扎帐→向导

2、出纳反扎帐:CTR+F9

六、备份(磁盘或硬盘)

1、初始化完、月末或年末,用磁盘备份,插入A盘→文件→备份;

2、初始化完、月末或年末,用硬盘备份,文件→备份→选择路径(C盘、D盘、E盘)

七、帐套恢复

想用备份的账套数据(即相应的.AIB 文件),先将备份的账套恢复到硬盘中(恢复为AIS账套文件),再打开它。利用此功能可将备份到软盘上的账套资料恢复到硬盘中。具体操作:文件菜单→恢复→恢复账套→选择备份文件点击后<打开>→恢复为“AIS”帐套;

七、工具菜单

1、用户管理(用户增加、删除、授权);

2、用户登录密码(用户密码增加、修改、删除);

3、计算器—F11 帐务处理流程:

1、凭证录入:点击“主窗口”中“凭证录入”,弹出一张凭证的窗口,先修改凭证日期,修改凭证字,输入附件张数,鼠标点到摘要拦,输入摘要内容,此时也可以按F7或者凭证菜单栏里的“获取”按纽,弹出常用摘要窗口,此窗口左下方“增加”按纽增加常用摘要类别(如:收入,支出等)类别名称自编,点右边“增加”按纽增加常用摘要内容,如:提取现金、销售某某商品等等。输入完摘要后,回车,光标跳到会计科目栏,点击“获取”或F7弹出会计科目窗口,在此窗口中选择相应会计科目,也可直接输入科目代码,回车,如果选取的科目关联了核算项目,则光标跳入会计科目左下方的空格,再按F7选择相应的核算项目,然后回车输入金额,继续输入第二条分录,此时输入摘要时可使用快截方式“..”(两个英文状态下的小数点)可复制上条摘要内容→会计科目→金额,此时可使用自动计算平衡“CTRL”+“F7”快捷键功能,系统自动计算出对方金额。

→点击“保存”按纽,凭证输入完毕,保存后系统会自动弹出一张空白凭证,继续凭证输入工作。

模式凭证:制作完一张常用凭证,如每月都必须做的计提折旧、计提福利费、计提工资等凭证后,点击凭证菜单栏“编辑”,点击“保存为模式凭证”→“常用模式凭证”前打勾,“借方”、“贷方”前打勾→“确定”即可。

使用时只要在凭证录入界面,点击凭证上的“编辑”菜单→“调入模式凭证”→选择一张需要的模式凭证→“确定”即可,修改相应的凭证附件张数,凭证日期和相关内容等信息。 注意!

手工输入所有的凭证,但“期末调汇”和“结转损益”凭证除外,此两张凭证需要使用系统提供的自动期末调汇和结转损益功能,否则会导致利润表取不到数。

2、凭证查询

点击主界面“凭证查询”→弹出凭证过滤窗口,内容中选择“会计期间”“=”“当前会计期间”,窗口下面左边和右面都选“全部”→确定以后显示出本期所有的已保存的凭证,可以在此界面中对凭证进行修改,删除操作,也可直接在此界面中增加新的凭证

修改:双击那张需要修改的凭证,直接修改删除:在会计分录序时簿中,选中那张需要删除的凭证,然后点击菜单拦里红色的“×”,该凭证既被删除,如果前面出现“X”标记,则说明该凭证作废,没有被删除,可点击菜单栏“恢复”按纽恢复该凭证,或者再重复刚才操作既可完全删除该凭证。

注意:以上修改删除操作必须是在凭证未审核未过帐状态下方可实现,如该凭证已审核并已过帐,则参照快捷方式及日常操作“反过帐”,“反审核”,恢复凭证到未审核状态!

3、凭证审核凭证输入完成后,更换操作员登陆金碟,点击主界面“凭证审核”→弹出凭证过滤窗口,内容中选择“会计期间”“=”“当前会计期间”,窗口下面左边和右面都选“全部”→确定以后显示出本期所有的凭证→点击菜单栏上“批审”将对序时簿中的凭证批量审核,如选种某张凭证,再点击菜单里的“审核”→弹出该凭证的窗口,再点击凭证菜单上的“审核”是对这张凭证进行单独审核。

单独取消审核只需再点击一下凭证菜单栏中的“审核”即可。 批量取消审核:

用前面审核的操作员登陆,进入“凭证审核”显示出本题的会计分录序时簿,(不要点开任何凭证),单击“编辑”菜单→“成批销章”即可。

注意,只可销章本人审核的凭证,其他操作员无权取消他人审核的凭证。

4、凭证检查:检查本期是否还有未过帐的凭证,如本题所有凭证均已过帐,点击该按纽,将出现“没有需要检查的凭证”否则,说明本期还有未过帐的凭证,需要补做未完工作。

5、凭证过帐:凭证审核完成以后,需要进行过帐,点击该项,将出现凭证过帐向导,按照提示操作。

注意:每期至少需要做两次过帐,第一次:结转损益前,对手工制作的所有凭证进行审核过帐,第二次:点击“结转损益”,根据提示操作将自动生成一张结转损益的凭证,再对它进行审核过帐,有外币业务的企业还必须在结转损益之前使用系统提供的“期末调汇”功能制作一张期末调汇凭证,审核以后再做结转损益工作。此项操作可根据需要适时更换操作员。

6、本期所有的凭证均过帐以后,必须先查看报表和帐簿,才可做结帐工作点击金碟主界面左边蓝色导航栏上的“报表”→查看资产负债表/利润表/自定义报表→菜单栏内“!重算”将自动计算出本期报表,如发现报表错误,(如资产负债表不平衡)可退出报表进入帐务处理界面,打印一张本期“科目余额表”,再进入报表系统进行核对,对相应错误科目进行报表公式验证,发现错误,进入菜单栏“”进行报表公式修改,修改完毕后,必须回车以后修改有效。 查询明细帐:

主界面左边“帐务处理”→点击右边“明细帐”→弹出明细帐过滤窗口→选定会计期间→币别→明细科目代码(点击输入框右边的黄色按纽,弹出会计科目窗口选择)如有核算项目勾选“包括核算项目”并选择项目类别→包括未过帐凭证(此项功能可在凭证未过帐状态查看即时明细帐帐目情况)→确定! 系统显示出所需查看科目的明细帐,如无发生额和余额,此明细科目帐簿不显示。其他帐簿,表格等均参照此方法进行过滤查看。 查询多栏式明细帐:

“帐务处理”→“多栏式明细帐”→“多栏账”标签页→“增加”→“多栏账科目”选择需要设置多栏账的科目如“管理费用”等,如果此科目未设置下级明细科目而是设置的核算项目,则在“核算项目类别”选择下设的核算项目,如“往来单位”等,(如此科目既未下设明细科目也无核算项目,不能设置成多栏账)→在此窗口左下方点击“自动编排”→“确定”弹出保存为“(所选科目)明细胀”→“确定”→到“查询条件”标签页选择相应的会计期间等条件信息,→“确定”即可显示出所设置的科目的多栏式明细账。 注意!如已经设置过多栏账(如管理费用),之后又增加过此科目的下级明细科目(新费用项目)或核算项目,则再次查询多栏式明细时,必须对此科目进行“修改”,重新“自动编排”一次才能把新增加的明细项目增加到多栏式名细帐中,否则会缺少一部分数据。 查询总帐,总帐以及报表均须所有凭证都过帐以后才可显示打印总帐时必须勾选上“按科目分页显示”选项。 ,其他各帐务处理过程报表,如科目余额表试算平衡表等和各明细帐均可以在凭证未过帐状态即可查询即时帐簿情况。 操作小技巧: 一,凭证处理

1,摘要栏两种快速复制摘要的功能,在下一行中按“..”可复制上一条摘要,按“//”可复制第一条摘要。同时,系统还设计了摘要库,在录入凭证过程中,当光标定位于摘要栏时,按F7或单击「获取」按钮,即可调出凭证摘要库。选择所需的摘要即可,在这个窗口中,您还可以新增,删除或引入摘要;

2,金额栏已录入的金额转换方向,按“空格”键即可;若要输入负金额,在录入数字后再输入“-”号即可;

3,会计科目栏会计科目获取——F7或用鼠标单击窗口中的「获取」按钮,可调出会计科目代码;

4,金额借贷自动平衡——“CTR+F7” 5,凭证保存——F8 二,凭证审核

1,成批审核——先在凭证查询中,“凭证查询”→“全部,全部”,选文件菜单中的“成批审核”功能或按“CTR+H”即可; 2,成批销章——先在凭证查询中,“凭证查询”→“全部,全部”,选文件菜单中的“成批销章”功能或按“CTR+V”即可; 三,凭证过帐

1,凭证过帐→向导

2,凭证反过帐——“CTR+F11” 四,期末结帐

1,期末结帐:期末处理→期末结帐→向导 2,期末反结帐:CTR+F12 (慎用) 五,出纳扎帐与反扎帐

1,出纳扎帐:出纳→出纳扎帐→向导 2,出纳反扎帐:CTR+F9 六,备份(磁盘或硬盘)

1,初始化完,月末或年末,用磁盘备份,插入A盘→文件→备份;

2,初始化完,月末或年末,用硬盘备份,文件→备份→选择路径(C盘,D盘,E盘) 七,帐套恢复想用备份的账套数据(即相应的.AIB 文件),先将备份的账套恢复到硬盘中(恢复为AIS账套文件),再打开它。利用此功能可将备份到软盘上的账套资料恢复到硬盘中。具体操作:文件菜单→恢复→恢复账套→选择备份文件点击后→恢复为“AIS”帐套; 八,工具

1,用户管理(用户增加,删除,授权);

2,用户登录密码(用户密码增加,修改,删除); 3,计算器—F11

4,F12回填计算器金额

九.在录入凭证时,为何小数点输不进去?

答:这是因为您的输入法状态是全角,解决此问题的方法有两个: (1)您在中文输入法状态下,将全角改为半角即可; (2)您把输入法切换成英文状态即可。 十.当凭证录入完毕后,在何处查询? 答:在凭证查询中查找。

十一.当发现凭证输入有错时,该如何处理?

答:如果这张凭证是在输入过程中,只需将不正确的地方修改成正确的,保存即可,如果这张凭证已经保存了,首先要在凭证查询中,查到这张凭证,然后用鼠标双击此凭证或直接用工具条中的凭证修改,此时金蝶软件会自动调出这张凭证,您就可进行修改,修改完后保存。 注:在修改凭证时以何人的名字进入,保存时制单人即为此人。

十二.若财务上有两个操作员为A、B,A录入10张凭证,由B审核,但B进行审核时却没看见1张凭证,这是为何?

答:在金蝶软件中“用户授权”下有权限适用范围分别为:所有用户、本组用户、本人。 现假设C有查询凭证的权限,用他来解释上面三个权限的含义:所有用户:即C可查询到所有财务人员录入的凭证

本组用户:即C可查询到本组财务人员录入的凭证本人:即C只可查询到本人录入的凭证 十三.凭证审核过后,发现凭证有错,该如何处理?

答:要先进行凭证销章,然后才可修改凭证。首先将此凭证在凭证查询处查出,在文件菜单下(标准版7.0是在编辑菜单下)点成批销章,然后再进行修改 十四.如何在有帐务发生的情况下增加明细科目?

答:先在原科目下增加一个过渡科目,系统会将原科目数据转入这个 过渡科目。再将该过渡科目的发生额及余额通过自动转帐或制作记帐凭证结转到其他新增科目。

十五.查询科目余额表等报表时,如何查看明细帐? 金蝶财务软件提供了证帐表一体化查询功能。

科目余额表(双击)——明细分类帐(双击)——记帐凭证核算项目明细表(双击)——明细分类帐(双击)——记帐凭证总分类帐(双击)——明细分类帐(双击)——记帐凭证往来对帐单(双击)——记帐凭证单位对帐单(银行对帐)(双击)——记帐凭证 十六.在金蝶软件中是否只要录入凭证,就可看见帐簿和报表?

答:只要录入凭证,就可看见明细帐,但要看总帐和报表,则必须过帐。

第四篇:软件开发心得

软件开发心得体会

08软件(1)班 陈会敏 24号

岁月流转,时光匆匆,转眼间我的大学生活已经接近了尾声。回首往昔,有太多美好的,也有太多艰辛。我的大学生活的主旋律还是学习,我所选学的专业是软件技术,在这条道路上走了那么久,也有一些小小的感悟与体会。

还记得上初中时,英语课本上有一篇关于比尔盖茨的文章,当时真的很佩服比尔盖茨,也就是那时我才第一次接触到软件一词,学过那篇文章后我有个想法,就是也要做个比尔盖茨,可是由于家庭条件的限制,那也只能是个美好的梦想。后来上了高中,再报考时我就选择了软件技术这个专业,这样我想就向那个遥远而又美好的梦想迈进了一点点吧。

然而当我真正上了大学,学了这个专业,我才知道要做个比尔盖茨是多么的难,要想学好我的专业要花费很大的精力。第一学期我们开设了C语言这门课程,当时我学着真的是云里雾里、一窍不通,很是失落,学了不久之后我开始觉得自己可能并不喜欢这个专业,只是一时昏了头,错以为喜欢了。现实的打击让我有点不知所措,然而我已经选择了它,有句话说:既然选择了远方便只顾风雨兼程。我既然选择了这个专业,我便也只有硬着头皮也要走下去了。有了这样的想法之后,在之后的一段时间里,只要是没课的时候我就抱起了C语言课本,努力的看,记语法知识,语法规则,学语句、小算法等等。经过一段时间的研究学习,我发现C语言并没有我想象中的那么难

了,还是很有意思的。就这样在学与玩中我的大学第一个星期就过完了。

后来又开设了很多课程,有VB、网络、数据库、操作系统、数据结构等。在这些课程中最令我头疼的就是数据库了,老师讲的时候老是划重点,讲的很少,当时学的时候真的好难受,一学期下来啥也不会,后来看书上的操作,一步一步的操作,才终于学会了建个数据库,做下备份还原等操作。开设的那么多课程也有我很喜欢的课程,比如数据结构,这门课程理论的比较多,上机操作的很少,这门课程是很需要理解的,当然有的还是要死记的。学习这门课的时候,我觉得并不像其它课程那么吃力,可能高中是学理科的缘故吧,理解起来并不太费劲。所以当时就很喜欢这门课,然而这门课表皮的好学,但要深学起来还是很有难度的,所以期末考试的时候我的成绩并不太理想,但这些打击不了我对它的兴趣,至少我知道我所学的这个专业还是有很多我是很喜欢的。

这样走着走着就到了大二的下学期了,那个学期,我们有一门课是C++,这门课的老师很和蔼,能力也很高,从他那里我学到了很多东西。老师教给了我们很多算法,也很系统的讲解了语法知识,还教我们做小系统,有的时候他会给我门们一些小系统的代码,让我们去改写,刚开始的时候我也是不会,后来经过学习请教改写成功了,这个时候我就会很开心,很有成就感。就这样在学与玩中,在快乐和忧愁中我们迎来了我们的大三时光。

大三刚一开学,老师们就告诉我们这学期就上十二周的课,然后

就考试,就毕业了。这让我很有紧迫感,一想到毕业在即,心头就有种不舍,这儿有我美好的时光,然而我就要对这里说再见了。大三了我们的课全变成了专业课,也几乎全成了上机课,老师还给我们布置了一个程序,就是一个小组要交一个系统来算作成绩。我们这小组所选的课题是图书管理系统,针对这个系统,我们上机的时候,利用网络资源在网上查找了相关的资料,因为说实话,我们对此并不太理解,也只有通过网络来查找信息,做好需求分析,功能模块设计等工作。在这同时我们还去了学校的图书馆理解了相关的信息,这个系统并不要求功能有多么强大,关键在与一种锻炼,思维的锻炼,对所学东西的总结等。建立数据库时我们就根据需要建立几个表,里面的数据也是从我们学校图书馆里找来的。后来的界面设计,为了追求美观,我们又在网上搜了很多美丽的图片来美化界面。具体到功能的时候,有很多东西都不会,后来老师在课堂在做了讲解,我们就把它用到了我们的系统中,真的就是学一步做一步的。整个的系统做下来,我学到了很多东西,也对那么知识有了很好的应用能力。

现在这个星期也就到了期末,这短暂的校园时光也在飞速的流逝着。回首过去学习的经历,真是苦中有乐,乐中亦多苦,然而无论如何这些都已经走过去了,未来的路还要我们好好的走下去。人生本就是一个不断的学习的过程,也是一个不断完善的过程,在未来的道路上我会更加努力地学习,走出一个美好的人生。

第五篇:大型软件开发心得

最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。

立项前

1、统一元素设计需考虑周全

也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。

哪些元素应该做到统一?

a、提示方面:统一的操作成功/失败提示;统一的弹窗形式;提示语言采用较统一的句型;为空情况的友好提醒;溢出情况的友好提醒;表单实时验证的提醒形式等。

b、文字方面:是否有统一的段落前“·”号;统一的链接状态;统一的字体、间距、行高等。

c、图片方面:调取图片的统一尺寸;如果是上传图片类的操作,需要考虑周全全站的调取情况,以及考虑是否统一预览图的尺寸等。

d、细节交互:未激活功能的按钮做“灰色”处理(例如用户没有勾选信息时批量删除按钮不可使用);按钮点击的状态统一(例如增加“提交中”的按钮状态,以防止网速慢用户狂点某一按钮的情况);特殊控件的统一等。

也许会有朋友说,上面有些是交互设计师需要做的事,但我一直认为作为一个产品经理考虑周全一些,没坏处。这些“统一”同样可以用在验收阶段,要知道,即使一个像素也可以改变整个产品的感觉。

2、原有功能的去留

我一直觉得升级已有产品比开发新产品难一些。这就像栽培植物一样,新种下一棵果树无非需要选对了土地,然后刨个坑种下去,然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。

改进已有产品常常需要面对一个最棘手的问题:原有功能是去是留?

原功能去掉的话是不是会影响部分用户使用?是否需要通过公告、站内信、界面引导等方式友好地告知用户?怎样把对用户的伤害降至最低?

原功能留下的话是不是可以优化完善?听到了什么用户群怎样的声音?是否要在这次升级中做调整?

这些问题当接到项目的时候,产品经理就应该考虑周全了。特别需要注意的是,如果这个产品之前不是自己设计的,那么最好找到prd说明文档细细研究一遍,对把握不准的功能点找到原负责人确认,毕竟树苗是ta摘的,别把将来最能结果的枝干给砍了。

3、产品线上下游的对接

昨天有跟朋友聊起淘宝强势之处,就是产品与产品紧密捏合,线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基,无可撼动。

所以把握产品线上下游和产品周边很重要,即使一个看似简单的新闻展示页面修改也会牵扯到编辑后台、广告位管理、帮助中心,甚至是访问统计、数据需求的变更。

这要求在产品设计开始前,需要把该产品“连根拔起”,仔细梳理相关脉络,如果产品线够长,一个清晰的产品线结构图很有必要。

项目中

1、项目期间来自相关产品线调整的影响

项目期间相关产品线的调整是我最不愿意遇到的情况,这就像你在通往目的地的道路上高速行驶,就快要到达终点了,突然一个人告诉你:你走错路了。

项目里有一个通用模块,产品设计到一半,这个通用模块改了;项目里有一个流程,产品做到一半,这个流程废弃了;最要命的是已经立项开发了,你不得不硬着头皮跟程序员说:“因为一些不可抗拒原因,这个需求咱不做了。”

对于一个耗时较长的项目来说,这种情况难以避免,事出原因私自总结有三:

a、严重体验性问题:例如某个流程遭到大量用户的不满,为防止用户流失,不得不做临时调整,而倒霉的是,你也在用这个流程。

b、相关项目的影响:包括并行项目和新项目。例如你的同事在设计另一个产品,你们的产品相互牵扯较多,所以需求分析时做过很多沟通,但有一天,同事告诉你,ta的一个需求做临时调整了会影响到你,怎么办?

c、老板的突然决定:不举例。

最终的解决方法不外乎三种:立即调整、延期调整、不调整。个人的处理原则一般是对a种情况进行立即调整,对b、c情况讨论并选择性延期。

为什么这么做呢?a情况是必须要改的,时间早晚问题,长痛不如短痛,b、c两种情况必须坐下来细细讨论。需了解这个需求为什么要改?是长期对策还是临时决定?能否延期,记录需求等下一版本再开发?如果b、c情况提出来的需求没过两天又有改变,那与你配合的前端和程序员也太没有安全感了。

这个时代能耐心阅读完XX枚汉字的人越来越少,较大型项目的产品工作心得[下]未完待续,欢迎交流……

2、需求变更

承上,需求变更是每个程序员、产品经理、设计师等都会遇到的情况。产品经理不是神,项目组也不可能是开了无敌状态抵挡任何外界的影响。

当遇到不得不变更需求的时候,产品经理应该怎样处理呢?下面是个人的四条建议:

a、积极处理。往往,当一个设计愈是趋于完成,人们愈是倾向于局部调整,而不是做重新设计。当一个需求因为众所周知的原因不得不调整的时候,作为产品经理需要做的第一件事便是积极面对问题,积极处理。

项目开发往往是一个紧张的过程,每半天甚至每几个小时就有若干个功能点开发完成,当一个需求变更传达出现“延迟”,这个变更对项目的正常进程的“破坏力”就会更大一些。

b、保持沟通。“说话容易,沟通很难。很多事除非对方自己想明白,劝是没有用的。所以,很多时候,沟通是个自己挣扎的过程”这话没错。需求变更直接会影响到下一道工序,产品经理需要将需求变更的细节和原因传达给相关人员,包括视觉、前端、程序、测试等。

这是很多产品经理表示非常痛苦的过程,因为可能会遭到数落和冷眼,日本有一个礼仪原则是“不要给别人添麻烦”,但是在项目中,这不可避免。

个人认为所有沟通的障碍都源于思想的不统一,如果让大家觉得这个需求修改是在浪费时间,那么沟通上的不畅快在所难免。项目不是这样算的,需求既然更改一定有所目的,产品经理需要将这个原因讲明白,不做修改或节约沟通时间导致的返工,后果往往更严重。

本文来自 99学术网(www.99xueshu.com),转载请保留网址和出处

上一篇:软件开发学习心得下一篇:如何做房地产大佬