姓名：xIkUg[BCG][DFCG][OCN][DCM][CZG]
部门：行业开发部 – 超市项目组
出生日期：1980-11-25
个人简介：
没什么爱好，唯软件开发技术情有独钟，常自娱自乐，自小热爱编程，从小学6年级开始正式学习程序设计，至今已有xx年有余，18岁中专毕业，参加工作，至今已有5年，近6年的软件开发工作经验，工作期间也不断学习，完善自己的职业技能，理解软件开发的思想，熟悉Delphi、C/C++/VC++、ASP、SQL Server、Html、脚本语言（如：VBScript、JavaScript），汇编，熟悉Win32SDK编程，经过多年的学习和实践相结合对面象对象的设计与开发也有深刻的理解和自己独特的见解。列宁曾说“实践高于（理论的）认识，因为它不仅具有普遍性的品格，而且还具有直接现实性的品格。”，我始终相信。
对软件逆向工程也比较熟悉,熟悉汇编/反汇编，熟悉各种静态反编译（反汇编）工具如DD、W32DASM、C32ASM等，熟悉各种动态跟踪调试工具如SoftICE、OllyDBG等工具，熟悉加密与解密，能够利用这些工具和我的知识对软件进行加密，防止盗版，能够对软件进行解密和逆向工程，研究软件的底层机理，属于中国破解组织BCG/DFCG/OCN/DCM/CZG正式成员(注:这些组织都是以技术研究为主的,跟盗版是两回事)。
同时熟悉多层系统的设计开发，熟悉各种软件工具的使用，对Windows系列操作系统较为熟悉，对Linux操作系统有所了解。掌握面向对象的分析与设计和相关工具的使用，对软件工程化也比较熟悉,由其感兴趣的是敏捷软件开发。曾任技术研发组组长，带领技术研发组完成技术攻关，管理软件项目。有极强的自学能力和归纳总结能力。对一项技术有强烈的钻研欲望.
转入正题了，首先谈谈，我认为我所在的项目组做得好的地方．在我们项目组中使用了CVS做软件的版本控制，用RoboHelp写文档，用TestTrack做Bug跟踪．
做得不好的地方就是需求描述不清晰，而我们过早的进入＂设计＂阶段，过迟的进入测试阶段．
我们需要的需求描述是这样的：只说做什么，不说怎么做，并描述出希望得到的结果，至于操作习惯这些东西可以在得到了正确的软件功能后再作调整．
例如：
再来看看我们的代码：
我们目前的代码根本不具备可测试性，当改动一个地方的时候我们不可能自己把所有代码功能都跑１遍，以保证程序的正确性，保证程序的质量，有可能我们改动的这一个地方会牵扯到另一个地方或N个地方，而我们有可能没有考虑到这个关联性或没有考虑完，于是１个地方的改动造成了N个地方的错误．这样的问题在我们公司开发人员中基本是天天都在上演重复的一幕，造成开发成本／维护成本不断的上升，产品迟迟不能稳定．
还有一个比较严重的问题是过早的进行设计，把程序的结构过早的定下来，这样导致的后果是要当需求发生变化，目前的系统结构无法满足需求时，可想而知后果的什么样的．
再来说说测试：
我们的测试人员可说是做得比较好了的，这点我没什么好说的．我只是想说让我们开发产品应该尽早的提交给测试人员和用户进行测试，这样我们可以更早的得到反馈，对产品作出改进和修改．
我想重点对我们开发谈谈，提出一些自己的建议：
为了保证我们的程序具有可靠性，可维护性，可阅读性，让我们产品达到一个高质量的标准，我想唯一的方法就是让我们代码具有可测试性，可测试性的代码是具有良好结构的，优美的，高质量的并且也是简单的．其中以测试来驱动开发(TDD)的方法是我较为推崇的，我在家自己写的程序基本都有Unit Test．
Unit Test又叫单元测试，是针对程序最基本结构单元所进行的测试。而TDD的过程是这样的，写一个测试程序，使其可以运行，重构。在写这个测试程序的时候你考虑的不应该是基于什么结构单元，而是要考虑需要完成的什么功能。实现和重构的时候，具体是不是这个单元完成了这个功能依然不是你应该去考虑的，你考虑的还是——是不是完成了这个功能、是不是代码真的清晰和可工作。你考虑的问题永远是围绕着具体的功能进行的，而不是围绕某种结构进行的。你写这个测试程序的时候，这个结构并不存在，并且今后也可能不存在（由于重构，你在别的结构部分实现了这个功能）。
明白这个道理就可以明白TDD实际还是基于需求驱动的，还是一种前瞻性的设计手段。只不过TDD让这个需求更加具体，让其前瞻性也更可以预测，并且在多种方法中给了你进行多种尝试的机会。而当你认为这个测试只是单元测试的时候，无疑你就把程序的结构早早的做了一个固定，其是基于结构的而不是基于需求的，并且由于其基于结构的一面则设计的前瞻性很难得到保证，而就根本性的断绝了你进行多种尝试的可能。设计的前瞻性是指你的设计可以带来可以预测的结果。而软件的结构是动态的，并且随着你必须进行的重构活动这样的结构变更会日常性的存在。如果你的一个测试高度的依靠某种特殊的结构，在这样的经常性重构的环境下，其被经常性修改的几率会大大增加。而由于其结构的不确定性是根本不可能逆转的，所以针对结构进行的测试根本不可能带来结构上的可预测性，而谈不上什么前瞻性了。
软件开发是一个不断跌代的过程，我们应该小步前进，不应该一开始就固定的程序的结构，
一开始就使用复杂的设计模式，这些程序结构和设计模式都应该是我们通过了N次跌代后得到的结果．应该切忌为了显示自己的水平而在一开始使用这些复杂的东西．
时间有限，就谈到这里，附上两篇我以前写的关于开发的文章，作为参考，详见附件 １．简单设计
２．挑战极限－测试驱动开发
第二篇：粤语社工作总结与建议
于上周星期六中午11点到12点这段时间，身为粤语社A组的我、吴嘉俊、陆华文、鈡雯为了在北化宣传岭南粤语文化，举行了“声声粤尔”粤语歌唱比赛活动。
虽然第一次脱离大二学长靠我们自己搞，在这场活动中，我们先自己内部临时分配工作，一人负责播放音乐兼看电脑，两人人负责宣传拉人来唱歌，还有一人负责评审并颁发奖品——卡贴。
但人算不如天算，在外界温度相当低的情况下，当天的场景并没有我们想象的那般热火，路上的人稀稀拉拉的，并未见太多人，我们摊位也就理所当然地特别冷清。于是，我们做出临时决定，将今天的奖品——卡贴作为宣传单，为明天同样时间举行的“声声粤尔”粤语歌唱大赛活动做一下宣传，积点人气。说干就干，于是我们没人分站一个路口，见路人经过就说：“‘声声粤尔’粤语歌唱大赛，期待你明天的参见。”当然，我们依旧没有忘记我们的最初目的——叫人来唱几句，但很可惜，来到的人看到设备比较简陋，例如说没有麦克风，就过来看看就走了。
最后，到了12点多，我们的卡贴发完了，任务也算完成了，于是就收拾好东西，活动结束。
根据以上的工作状况，下面说说我的工作建议。
首先，我们摆摊是遇到的第一个问题就是有人来问我们为什么不联系她。对于这个问题，我感觉登记的时候，不仅要求写下手机号，最好当场加飞信，确保信息传达无误。还有，顺便登记一下Q号，拉进Q群，方便信息传达。
其次，活动物品过于简陋。我个人感觉，我们的摊位上没有说明我们是干嘛的，于是没人了解我们的工作，就这样没多少人前来搭理我们。接着，没有麦克风，例子前面已经列举了。最后，就是奖品过于简单，与其说是奖品，感觉更像宣传单。
接着，说说我对教学方面的看法。
对于教学，我们可以与外校的粤语社进行一些经验交流，然后取其精华，弃其糟粕，提升自己的实力。
对于改进，通过短信或Q群交流，让成员说出自己心中的想法，改善教学方案。
最后，我要说的是给他们提供一个粤语环境，出去唱K或吃宵夜的时候，不仅单一地叫干事或老乡会，还可以叫上学员们，让他们与粤语零距离接触。
新闻培训
经过这次培训，我感觉它对我的新闻报道能力的提升有一定的帮助。
首先，它让我了解了新闻的一般特性——时效性、真实性等等，让我不再对它感到陌生。 最后，这次培训还让我掌握了捕捉新闻的基本能力——对外界事物的敏感度。正如著名雕塑家罗丹所说的：“生活不缺乏美，知识缺乏发现美的眼睛”，发现新闻也需要发现美眼睛。 总之，这次的培训让我受益匪浅！