发布时间：2013-03-17 22:45:43

     最近线上的一模块报Too many open files错误，引起这个错误的原因是进程打开文件超过了限制。    先不着急修改限制，看了下模块逻辑是否正常，是否有忘记关闭的文件描述符，逻辑没有问题。好开始修改系统限制，首先确认系统能打开的最大句柄数，一般来说这个数字比较大不用修改，如果要修改.........【阅读全文】

发布时间：2013-02-03 18:19:35

一、简介    性能分析的目的是为了找出“热点”，进而消除热点提高整体效率。只有找到那些最常被执行的20%代码，才能做到有的放矢。本文结合自己的使用经验介绍几个分析工具，并浅谈自己对程序优化的看法。二、分析工具    Opcontrol系列工具在Linux下普遍存在，支.........【阅读全文】

发布时间：2013-01-20 20:50:38

最近在测试一个模块的稳定性，测试过程中发现该模块时不时的报rename失败。首先通过日志找到报错的代码，没有记录参数信息、具体出错码，没什么有用的信息。只好修改代码记录下参数信息及errno值，再拿去跑，还好能顺利的重现该现象，得到的errno是2，即ENOENT，再根据参数信息确认下oldpath所指的文件是不是真的不存.........【阅读全文】

发布时间：2013-01-12 11:43:56

去年6月份接到开发模块A的任务，整理完需求后开始详细设计、开发，约7月中旬构建完毕，开始上线测试。7月下旬，由于需求变更，开始考虑重构模块，8月初完成。12月份客户验收，对该功能极为不满，开始考虑如何重新设计该模块及修改后续数据流中的其它模块，目前已构建完毕。本该1.5月完成的模块，前后经历了3.5月，有以下几点教训。1、重视客户的每一个需求，仔细分析需求形成正规的需求文档，后续的构建活动中严格遵循该文档，妥善管理需求变更。第二次重构的原因是需求分析不到位，没有吃透需求就开始架构设计，模块设计与开发，等开发都进行了一半了才突然发现不满足其中的一个需求。第三次重构的原因是轻视客户需求，认为这个需......【阅读全文】

发布时间：2012-12-17 21:07:17

提高可维护性不仅要靠良好的编码风格，而且还要在设计架构和模块时就充分考虑可维护性。有些模块代码风格太差，程序表达不甚清楚明了，后续维护的人阅读这样的代码简直是折磨，想去查文档了解代码也不太现实，因而在实现时一定要注意保持良好的编码风格，对一些特殊的做法，添上实际例子或者写下如此做的原因。也要注重单元测试代码的风格，对复杂的测试尽量写注释，否则单元测试在后期维护中可能起不到应有的作用。设计时注重提高可维护性我认为有几个方面。第一个方面是在设计架构时，合理划分功能，别给某个模块压过多的职责，注意设计职责良好、相互协作的模块群。第二个方面是考虑模块能方便应对后续的变化，当然正确识别变化需要一定的领域......【阅读全文】