一直以来我们对项目代码的提交管理都是粗放型的，即对大家提交代码的时间、频率和提交日志的形式都没有严格的要求，可谓比较随意。主要发现的问题包括： - 某些提交没有规划，甚至随意增加一些并无太大意义的注释都作一次提交。 - 提交的代码甚至没有经过REVIEW和UT，这样的代码即使内部发布，也会带来后续工作量的严重浪费（测试、发现问题、定位问题、重新fix、重新验证等）； - 提交日志无实际意义，如commit log为空、commit log没能真实反映出这次提交的真实目的和意义、多次提交却采用同一条提交日志等等； … … ...
昨天一位同事发了一篇小文档，文档中介绍了一种开源格式化代码的工具，名为Artistic Style(astyle)，功能看起来还是很不错的。之前我写代码时比较注意代码的风格，一直按照自己的思路来美化自己的代码，用的最多的辅助工具就是Vim自带的indent功能，对这之外的格式化工具少有涉猎。记得几年前部门曾推广一款名为checkstyle的Java代码格式规范检查工具，由于当时基本不接触Java，也没有用过。 ...
昨天，也就是23号是我的信用卡还款日，由于新本子还没来得及安装招行个人网上银行专业版，我就计划回家后用家里的本子还款。到家后也没急着上网还款，待吃完晚饭后发现联通的网络居然上不去了。打客服电话报故障，但等到今天早晨起来也不见网络恢复，只好到公司再还了。 ...
这里卖了个小关子，所谓工作装备就是指我的笔记本。 本周三伴随了我三年多的R系Thinkpad终于因显卡故障再也无法正常启动了，至于它是否就此光荣退役，那还要看设备修理部门同事是否能修好它。 ...
对于我个人来说，将工作环境切换到Ubuntu上来有几个“坎儿”要迈过，其中最为迫切的一个就是Mail如何在Windows和Linux下共享的问题，今天我找到了解决方法。 Thunderbird和Firefox一样，都来自Mozilla组织。和Outlook等软件不同的是，Thunderbird是可以跨平台的，更有甚者，Thunderbird可以帮助我们在Windows和Linux共享邮件，当然需要作简单设置。 我的机器上安装了三系统：WinXP、Ubuntu 9.10和Slax，其中常用的是WinXP和Ubuntu。在Windows上最常用的Mail Client端软件为Outlook 2003，但Outlook是收费软件，不支持夸平台，更谈不上Mail跨平台共享。而这些恰恰是Thunderbird吸引眼球之所在。 ...
Ubuntu 9.10版本在10月29日发布，虽然没有太多吸引我的地方，但是看了网上很多关于Ubuntu 9.10的文章后，心里面还是痒痒的，终于在上周五我用午间休息时间完成了Ubuntu 9.10版本的安装。 ...
Review Board安装成功至今已半月有余，这期间我一直在试用它，虽欣喜于其提供的强大的功能，但还是有若干使用中的问题一直让我头痛不已，同时也阻碍了在部门推广该工具的进程。 ...
安装完中文语言包支持后，Ubuntu的默认locale是zh_CN.UTF-8(即简体中文语言环境，字符集内码UTF-8)。这与我们日常开发环境中Unix设定的环境有所区别，我们日常使用的环境一般为zh_CN.GBK或zh。我们的源代码文件的字符编码也都是GBK的编码，直接在Ubuntu下用默认设置的VIM打开后，中文的注释会显示乱码。如果你直接编辑这个文件并提交，那么其他在Unix下开发的同事Checkout这份源码后打开也将显示乱码（你新增的中文内容会是乱码）。 解决这个问题至少有两种方法：一种是为Ubuntu新增加一个zh_CN.GBK的locale的支持，内码使用GBK；另外一种就是通过设置VIM，在不变换Ubuntu所支持的locale(内码依旧是UTF-8)的情况下支持对GBK内码文件的读写。 ...
目前部门还没有采用Pair Programming那种时时刻刻都在review代码的工作方式，代码Review多采用走查方式，即代码写完后召开一个Code Review的Meeting，集中时间和经验丰富的人力对重点代码进行筛查，这种方式的代码Review有利，但也有弊。其弊端在于低效和覆盖面小。做一次走查需要N多人参与若干个小时，而在这段时间里不是每个参与者都能极其高效的参与到走查中的，实践证明只有少数几个人能真正在一次代码走查会议上起到关键的作用。另外走查一次能覆盖的代码范围又较小，一些看似不重要却很可能带来BUG的代码在走查会上很容易被遗漏。 ...
六十年之国庆日即将到来，对我们来说也算是个“利好消息”，因为这段时间里来自客户方面压力会减小不少，我们可以更多的做回自己-静下来做一些想做的、该做的事情。 ...