pkcs12的专栏

原创 建议大家都用一下vi的taglist插件

在vi.org上，是下载最多的插件，可以赶上sourceinsight的功能了。 

原创 做事之前先有标准。

自己做每一件事情之前，都给出一个ｃｋｌｉｓｔ，作为标准，用来保证每件事情的质量．也算是一个质量控制体系了．这个和在编程前就有测试代码的效果是一样的． 

原创 强烈推荐《代码大全》

《代码大全》早先看到这本书的名字，还以为是某个语言的教程。后来看了《程序员》杂志的鼎力推荐，才知道这是一本什么书。那么厚的书，看起来还是比较轻松的，这样的书对于我这样的人是最合适的了。从毕业后，从来没有系统的研究过这些问题。都是听周围的兄弟口传心授一点，自己体会一点。看了几章，立刻就应用到实践中去了。有效果。其中的一些观点，也是公司目前正在推行的政策，还是比较好的。比如在测试之前先进行代码评审。

原创 vi的一个牛牛的功能

在编辑状态下使用 ctrl＋n（或者p） 可以进行自动补全，甚至对于 c 的语法也能进行一些处理。赶快实践一下，收获多多。 

原创 半年简单总结

一转眼到这里也半年多了。得：    ）跟随一个固执的老大实践了一些软件工程的过程。老大比较固执也是一个好事情，比较坚持原则。    ）学会了怎样使用状态机来帮助实现处理复杂事务。    ）这里的管理还是比较严格的，所有的过程都有标准需要遵循，因此在编码方面也养成了好的习惯，至少从编码风格和标准上是这样的。    ）学会了简单使用ClearCase，对于版本管理又有了一些新的认识。    ）在项

转载 快速编辑 Shell 命令行

快速编辑 Shell 命令行   作 者：skybird　　摘 自： linuxsir.org发布时间：2006-05-16

原创 态度决定一切

说态度不能决定一切，这是抬杠“态度决定一切”是一种积极的思维

原创 发现VI的一个新特性

VI可以直接打开试用gzip压缩过的txt文本。以前比较土，都是先解压缩以后再编辑的。 

原创 今天早晨参加了一次 code inspection

今天早晨参加了一次 code inspection，这个code应该是经过单元测试以后的。 即便如此，还是检查出了很多问题。其中的一些问题是隐形问题，不好在单元测试中测试到的。也可能是单元测试的用例组织有问题。 其中的若干问题还是很致命的。在以前的我经历的开发中，如果这样的问题，肯定发现不了，甚至要在产品发布后，某些特殊的情况下才产生。 8个人一起inspection，当然水平高低不同，如果这8个

原创 质量控制

总体来讲，软件的质量控制是一件令人头痛的事情，尤其是把质量控制细化了以后，具体到每个人的质量控制，更是令人挠头，领导觉得程序员的设计质量不好，但是程序员却觉得这是自己苦心思考的独到之处，到底谁对呢？处理的不好，程序员还认为是领导故意为难自己。从这几个月的工作经历看，这里的质量控制主要有这么两个方面。硬性控制：    1. 有需要严格遵守的软件开发过程    2. 在设计中以方面引入更为优良

原创 为什么要先有测试程序，后有产品代码

早先的时候，不理解为什么要先有测试程序，后有产品代码，看了下面这个比喻，一下子明白了很多。工匠一:先拉上一根水平线，砌每一块砖时，都与这根水平线进行比较，使得每一块砖都保持水平。工匠二:先将一排砖都砌完，然后拉上一根水平线，看看哪些砖有问题，再进行调整。 现在已经有针对Java、Pyhton、C++、PHP等各种常用语言的测试框架。这足以搪塞住那些以"编写测试代码太麻烦"为理由的开发人员，让他

原创 “欺负”一下上市公司

王志东：有一部分内容QQ还没有放开做，而且QQ的很多业务还是收费的。 记者：您想用免费把QQ的用户吸引过来？王志东：我的优势是可以尽情尝试，“欺负”一下上市公司嘛。我做过上市公司CEO，面对那么多投资人，他们不可能随便改变盈利模式，这个风险他们承担不起，但是我就可以。 

原创 国人当自强

原创 在这里工作的目标

在这里工作的目标从最差目标到最好目标 最差  把英语练好，达到与外籍员工沟通无障碍，书写/阅读英文文档流畅  学习这里的软件工程的组织和管理方法。学习这里近千人/全球化的软件开发中，软件质量/开发周期的控制技术。  学习这里的管理技巧，细心体会，总是有所收获。  学习心得技术知识体系。争取成为这方面的专家。 最好实现的过程和步骤 第一年，至少把英语学好，达到最差目标 第二年，能够深刻理

原创 书写文档的一个注意事项

在书写文档的时候，如果遇到图表，尤其是表示关系，（调用关系，依赖关系，数据流关系）的时候，一定要使用不同颜色/粗细/方向 的线条来表示不同的关系。 例如 数据通道，命令通道，异步消息通道，同步消息通道 等等，另外不同的模块之间也可以使用不同的颜色，以示区别。

原创 年度考评

这里的年度考评，是以年度所有项目中的表现作为考评的结论的。这里体现出了立项的重要性，项目是整个考核体系的一个线索，以前是没有立项的，所以做起事情来就稀里糊涂的，对员工的考评也没有一个线索。想起来好像也是稀里糊涂的。 上级领导对我们部门的考评是以是否完成任务作为考评结论的。每个项目有完成的周期和时间。完成了就是100分。没有完成就扣分。这样对于公司来讲，最终的目的就是看项目完成的情况，也就是

原创 过程控制小组

这里有专门的过程控制小组。来负责和软件工程相关的过程控制，这将是一件非常重要，责任也非常重大的工作。后面工作的效率完全决绝于这个团队。他们可能在争吵和抱怨声中努力的完成这个工作。 他们也应当有极高的权利，防止部门领导或者一些leader的施加的压力。这将是一件非常辛苦的工作。 从直观的角度看，他们是不产生任何效益的，对于一些小的公司未必愿意或者必要维持这样一个队伍。可是这里

原创 演讲时候的一些注意事项

昨天的时候，公司的流程控制部门的员工给我们进行软件开发过程的培训。 其中的一位女士进行培训的时候，其演讲风格让人很不舒服。 首先是语速控制得不是很好，过快了一些，不知道是不是时间安排的缘故。 另外，我觉得最大的一个问题是她在演讲的时候，习惯性的加入了很多的语气词，例如“其实”“可能”“我觉得”“吧” 说“其实”，例如“这句话其实是说。。。。”，这个时候，你告诉听众，

原创 review & inspection

这里的文档，要经过一遍又一遍的review 。听取了多方面的意见，而且经常对一个文档的review，要开一个全球的电话会议。对于代码，也要经过一个Inspection的过程。Inspection的时候，至少要4个人参加，一个是代码的auther，还有代码的reader, 还有一个是recorder，还有一个moderator。其中，moderator负责主持，监督代码检查会议的质量和效率，确认

原创 Greate Job 一种激励的方法

    到这里以后，自己提交的两份工作报告，都被team leader评价为greate job，其实但凡有人的一份工作完成了，也大多被评价为greate。不管是不是真的 greate，看到这样的评价心里还是美滋滋的，想想以前自己做部门经理的时候，没有几个人的工作能让我看上眼。其实自己的工作也未必那么出色。随便找找，就找出一大堆的问题，那时可怜的兄弟们真是深受打击。    一种是发现优点的工作评价

原创 在这里学习到的点点滴滴

日子总是过的很快的，有很多东西值得记录下来，就用这里的地方吧。文章就不分类了，总体上讲，不会记录太多的技术细节的东西。

原创 今天在这里注册了。

以前在blogbus注册了。但是blogbus太慢了。msn space也太慢了。注册blog主要是想记录一些技术上的东西。免得用的时候找不到。希望csdn不要太快的关门了。但愿他长久一点。另外，不知那位仁兄注册了pkcs11的帐号。我就只好用pkcs12了。不过意思差太多了。