《软件工程工作总结与建议》由会员分享，可在线阅读，更多相关《软件工程工作总结与建议（3页珍藏版）》请在装配图网上搜索。
1、软件工程工作总结与建议姓名：xIkUgBCGDFCGOCNDCMCZG部门：行业开发部 超市项目组出生日期：1980-11-25个人简介：没什么爱好，唯软件开发技术情有独钟，常自娱自乐，自小热爱编程，从小学6年级开始正式学习程序设计，至今已有12年有余，18岁中专毕业，参加工作，至今已有5年，近6年的软件开发工作经验，工作期间也不断学习，完善自己的职业技能，理解软件开发的思想，熟悉Delphi、C/C+/VC+、ASP、SQL Server、Html、脚本语言（如：VBScript、JavaScript），汇编，熟悉Win32SDK编程，经过多年的学习和实践相结合对面象对象的设计与开发也有深刻
2、的理解和自己独特的见解。列宁曾说“实践高于（理论的）认识，因为它不仅具有普遍性的品格，而且还具有直接现实性的品格。”，我始终相信。对软件逆向工程也比较熟悉,熟悉汇编/反汇编，熟悉各种静态反编译（反汇编）工具如DD、W32DASM、C32ASM等，熟悉各种动态跟踪调试工具如SoftICE、OllyDBG等工具，熟悉加密与解密，能够利用这些工具和我的知识对软件进行加密，防止盗版，能够对软件进行解密和逆向工程，研究软件的底层机理，属于中国破解组织BCG/DFCG/OCN/DCM/CZG正式成员(注:这些组织都是以技术研究为主的,跟盗版是两回事)。同时熟悉多层系统的设计开发，熟悉各种软件工具的使用，对
3、Windows系列操作系统较为熟悉，对Linux操作系统有所了解。掌握面向对象的分析与设计和相关工具的使用，对软件工程化也比较熟悉,由其感兴趣的是敏捷软件开发。曾任技术研发组组长，带领技术研发组完成技术攻关，管理软件项目。有极强的自学能力和归纳总结能力。对一项技术有强烈的钻研欲望.转入正题了，首先谈谈，我认为我所在的项目组做得好的地方在我们项目组中使用了CVS做软件的版本控制，用RoboHelp写文档，用TestTrack做Bug跟踪做得不好的地方就是需求描述不清晰，而我们过早的进入设计阶段，过迟的进入测试阶段看看我们的需求描述吧：多数量同一商品的录入习惯：商品条码数量快捷键数量 某种商品在销
4、售过程中退货的操作习惯：商品条码负数快捷键数量我们需要的需求描述是这样的：只说做什么，不说怎么做，并描述出希望得到的结果，至于操作习惯这些东西可以在得到了正确的软件功能后再作调整例如：零售：一个商品的条码6910000000001，零售单价为15.00元，输入一个商品条码，卖出该商品个，零售金额为15.00元，卖个，零售金额为30.00元再来看看我们的代码：我们目前的代码根本不具备可测试性，当改动一个地方的时候我们不可能自己把所有代码功能都跑遍，以保证程序的正确性，保证程序的质量，有可能我们改动的这一个地方会牵扯到另一个地方或N个地方，而我们有可能没有考虑到这个关联性或没有考虑完，于是个地方的
5、改动造成了N个地方的错误这样的问题在我们公司开发人员中基本是天天都在上演重复的一幕，造成开发成本维护成本不断的上升，产品迟迟不能稳定还有一个比较严重的问题是过早的进行设计，把程序的结构过早的定下来，这样导致的后果是要当需求发生变化，目前的系统结构无法满足需求时，可想而知后果的什么样的再来说说测试：我们的测试人员可说是做得比较好了的，这点我没什么好说的我只是想说让我们开发产品应该尽早的提交给测试人员和用户进行测试，这样我们可以更早的得到反馈，对产品作出改进和修改我想重点对我们开发谈谈，提出一些自己的建议：为了保证我们的程序具有可靠性，可维护性，可阅读性，让我们产品达到一个高质量的标准，我想唯一的
6、方法就是让我们代码具有可测试性，可测试性的代码是具有良好结构的，优美的，高质量的并且也是简单的其中以测试来驱动开发(TDD)的方法是我较为推崇的，我在家自己写的程序基本都有Unit TestUnit Test又叫单元测试，是针对程序最基本结构单元所进行的测试。而TDD的过程是这样的，写一个测试程序，使其可以运行，重构。在写这个测试程序的时候你考虑的不应该是基于什么结构单元，而是要考虑需要完成的什么功能。实现和重构的时候，具体是不是这个单元完成了这个功能依然不是你应该去考虑的，你考虑的还是是不是完成了这个功能、是不是代码真的清晰和可工作。你考虑的问题永远是围绕着具体的功能进行的，而不是围绕某种结
7、构进行的。你写这个测试程序的时候，这个结构并不存在，并且今后也可能不存在（由于重构，你在别的结构部分实现了这个功能）。 明白这个道理就可以明白TDD实际还是基于需求驱动的，还是一种前瞻性的设计手段。只不过TDD让这个需求更加具体，让其前瞻性也更可以预测，并且在多种方法中给了你进行多种尝试的机会。而当你认为这个测试只是单元测试的时候，无疑你就把程序的结构早早的做了一个固定，其是基于结构的而不是基于需求的，并且由于其基于结构的一面则设计的前瞻性很难得到保证，而就根本性的断绝了你进行多种尝试的可能。设计的前瞻性是指你的设计可以带来可以预测的结果。而软件的结构是动态的，并且随着你必须进行的重构活动这样的结构变更会日常性的存在。如果你的一个测试高度的依靠某种特殊的结构，在这样的经常性重构的环境下，其被经常性修改的几率会大大增加。而由于其结构的不确定性是根本不可能逆转的，所以针对结构进行的测试根本不可能带来结构上的可预测性，而谈不上什么前瞻性了。软件开发是一个不断跌代的过程，我们应该小步前进，不应该一开始就固定的程序的结构，一开始就使用复杂的设计模式，这些程序结构和设计模式都应该是我们通过了N次跌代后得到的结果应该切忌为了显示自己的水平而在一开始使用这些复杂的东西时间有限，就谈到这里，附上两篇我以前写的关于开发的文章，作为参考，详见附件 简单设计 挑战极限测试驱动开发 3 / 3
软件工程工作总结与建议
