2008年4月16日

摘要: 反序列化xml配置文件到一个实体类,和直接读取xml到实体类相比,效率对比相当大,我简单测试了一下,各自占用的时间: 反序列化需要的时间是直接读取xml的几十倍。由此可见,反序列化的性能很差,占用时间非常大。在简洁代码的背后是效率的代价。应该根据需要按需选择。尤其是在系统启动的时候尽量避免Deserialization。最后分析了使用XSD装载XML,并反序列化到实体类的例子。 阅读全文
posted @ 2008-04-16 11:24 Mainz 阅读(1468) 评论(0) 推荐(0) 编辑

2008年4月13日

摘要: 现在多处理器计算机正在普及,很快,非多线程程序将处于劣势,因为它们无法利用可用计算资源中很大的一部分。 不幸的是,编写正确的多线程程序并不容易。这主要是因为程序员们还没有习惯“其他线程可能正在改变不属于它们下面的内存”这种思维方式。更糟糕的是,出现错误时,程序在绝大多数时候会继续运行下去。只有在有压力(正式运行)条件下,Bug 才会显示出来;发生故障时,极少有足够的信息可供有效地调试应用程序。本文讨论多线程和共享内存线程模型,争用及并发访问如何能够打破不变量,作为争用标准解决方案的锁定,何时需要锁定,如何使用锁定;理解开销,锁定如何能够各行其道。 阅读全文
posted @ 2008-04-13 21:11 Mainz 阅读(5270) 评论(0) 推荐(1) 编辑
摘要: 最好的性格是热爱生活、热爱同学、热爱一切事物,那么所有人也都会热爱你!机会是主动争取来的,而不是等来的。热爱手头的工作并投入热情,有时候要保持耐心。问问自己最适合做什么和最想做什么,那是否就是自己未来想走的路,不要看别人。 阅读全文
posted @ 2008-04-13 19:12 Mainz 阅读(585) 评论(0) 推荐(0) 编辑
摘要: 随着各种新技术的兴起和流行,如Web 2.0、社会计算、面向服务的架构(SOA)、3D因特网和虚拟世界,新的业务模式和规则也发生着变化,例如,苹果公司(itunes)革命性地改变了消费者购买音乐的方式,而与它类似的公司也通过富有创新精神的业务模式打破了行业的价值链。面对这些新技术和新商业创新的挑战,只有不断自我创新和变革,才能保持业绩的可持续增长。而随着市场竞争的加剧促使企业进行更大规模的变革。基于创新的成长使企业具有核心竞争力,有可能实现可持续发展。企业必须创新,而不只是改进。 阅读全文
posted @ 2008-04-13 17:25 Mainz 阅读(1138) 评论(0) 推荐(0) 编辑

2008年4月12日

摘要: WindowsXP常用命令, 例如,开始,运行,control userpasswords2 可以出现和2000一样的用户管理界面; regsvr32 *.dll,注册dll;services.msc,本地服务设置;compmgmt.msc,计算机管理。 阅读全文
posted @ 2008-04-12 11:43 Mainz 阅读(1227) 评论(0) 推荐(0) 编辑

2008年4月11日

摘要: 写通信程序常常需要把发出和收到的包记录到log文件,而最常用的记录方式就是16进制和ASCII码左右对照的方式 阅读全文
posted @ 2008-04-11 12:32 Mainz 阅读(1454) 评论(0) 推荐(0) 编辑

2008年4月8日

摘要: 我们很多时候可能不是那么幸运的被叫来做软件开发工作,而是做现有软件的维护。很多时候改了一个小地方,结果会触动其他的隐藏的很多神经,任何修改你都要小心翼翼。除了原来的程序员,没有人确切的知道某某功能点需要修改几个地方,哪儿和哪儿是相互关联的,这个功能会影响那个功能。有的时候甚至连需求功能点列表都没有留下。这简直就是软件维护的噩梦。 阅读全文
posted @ 2008-04-08 21:53 Mainz 阅读(1872) 评论(0) 推荐(0) 编辑

2008年4月7日

摘要: 我以前做的上百人一年多一个的大项目,完全按照CMMI Level3规范来控制需求变更的。起初有双方签字的经过评审的需求基线,以后需求变更的时候有需求变更委员会(CCB)或专门负责的角色(通常由客户方需求人员来收集和评估最初需求并提交给QA,QA牵头需求变更流程)来处理需求变更;现在公司做的项目规范较小,完全按照CMMI的规范来有点多余,所以我们基本上类似于敏捷开发的模式。敏捷编程是拥抱变化,持续重构和改进,迭代开发,频繁交付。在需求变更管理上我们还没有一套完整的合适的流程。 阅读全文
posted @ 2008-04-07 22:03 Mainz 阅读(1472) 评论(5) 推荐(0) 编辑

2008年4月6日

摘要: 通常的做法是通过更多的单元测试 (Unit test) 和code review,使得我们在开发阶段发现更多的问题,从而减少bug数。的确,开发人员经常单元测试,具有良好的测试和编程习惯,在每次check-in之前,或每次打baseline之前,项目组都有代码cross review,同级或跨级评审,自己代码每日评审能大大保证代码质量,在提交给测试组之前就消除大量的bug。但往往发现更大多数的bug是我们通过 Unit test和code review所不能发现的。为什么? 阅读全文
posted @ 2008-04-06 16:43 Mainz 阅读(1712) 评论(1) 推荐(0) 编辑
摘要: 做好一个软件,只靠技术好是很不够的,必须要有一套好的研发流程和配套的支持工具。微软所有产品的研发都遵循同样的研发模式、使用同样的研发工具来进行管理。在所有的工具中,我最佩服的就是其Bug管理系统Raid(现在叫Product Studio)。可以说,遍布全球的微软研发人员能够保持统一的思维模式、做事及语言习惯,与整个研发流程的配套工具密不可分,其中最重要的就是通过Raid把整个产品的研发有机的联系起来。阅读每个 Bug,你可以详细的看到大家讨论解决该问题的完整思路。 阅读全文
posted @ 2008-04-06 14:16 Mainz 阅读(3680) 评论(1) 推荐(0) 编辑

导航