admin 发布的文章

Unlocker - 帮你删除你删不掉的文件

当你重命名或删除一个文件/文件夹时,Windows 弹出对话框提示你“无法删除 xxx:它正在被其它用户/程序使用!”,怎么办?
使用 Unlocker ,你就可以轻松、方便、有效地解决这个虽小但很烦人的问题! 同类的工具中,综合易用性、功能强度,此款是目前最好的!

请根据你的系统架构安装对应版本,安装完成以后会自动在你的右键菜单添加功能项Unlocker,单击它就能轻松解锁文件并且进行删除,移动,重命名等操作!

下载地址:http://kuai.xunlei.com/d/PNUYUFDPVLEV

高效代码审查的十个经验

代码审查(Code Review)是软件开发中常用的手段,和QA测试相比,它更容易发现和架构以及时序相关等较难发现的问题,还可以帮助团队成员提高编程技能,统一编程风格等。

1. 代码审查要求团队有良好的文化

团队需要认识到代码审查是为了提高整个团队的能力,而不是针对个体设置的检查“关卡”。

“A的代码有个bug被B发现,所以A能力不行,B能力更好”,这一类的陷阱很容易被扩散从而影响团队内部的协作,因此需要避免。

另外,代码审查本身可以提高开发者的能力,让其从自身犯过的错误中学习,从他人的思路中学习。如果开发者对这个流程有抵触或者反感,这个目的就达不到。

2. 谨慎的使用审查中问题的发现率作为考评标准

在代码审查中如果发现问题,对于问题的发现者来说这是好事,应该予以鼓励。但对于被发现者,我们不主张使用这个方式予以惩罚。软件开发中bug在所难免,过度苛求本身有悖常理。更糟的是,如果造成参与者怕承担责任,不愿意在审查中指出问题,代码审查就没有任何的价值和意义。

3. 控制每次审查的代码数量

根据smartbear在思科所作的调查,每次审查200行-400行的代码效果最好。每次试图审查的代码过多,发现问题的能力就会下降,具体的比例关系如下图所示:

我们在实践中发现,随着开发平台和开发语言的不同,最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要,因为这个过程是高强度的脑力密集型活动。时间一长,代码在审查者眼里只是字母,无任何逻辑联系,自然不会有太多的产出。

4. 带着问题去进行审查

我们在每次代码审查中,要求审查者利用自身的经验先思考可能会碰到的问题,然后通过审查工作验证这些问题是否已经解决。一个窍门是,从用户可见的功能出发,假设一个比较复杂的使用场景,在代码阅读中验证这个使用场景是否能够正确工作。

使用这个技巧,可以让审查者有代入感,真正的沉浸入代码中,提高效率。大家都知道看武侠小说不容易瞌睡,而看专业书容易瞌睡,原因就是武侠小说更容易产生代入感。

有的研究建议每次树立目标,控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化,不如上面的方法效果好。

5. 所有的问题和修改,必须由原作者进行确认

如果在审查中发现问题,务必由原作者进行确认。

这样做有两个目的:

(1)确认问题确实存在,保证问题被解决

(2)让原作者了解问题和不足,帮助其成长

有些时候为了追求效率,有经验的审查者更倾向于直接修改代码乃至重构所有代码,但这样不利于提高团队效率,并且会增加因为重构引入新bug的几率,通常情况下我们不予鼓励。

6.利用代码审查激活个体“能动性"

即使项目进度比较紧张,无法完全的进行代码审查,至少也要进行部分代码的审查,此时随即抽取一些关键部分是个不错的办法。

背后的逻辑是,软件开发是非常有创造性的工作,开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察,可以促使开发者集中注意力,尤其是避免将质量糟糕,乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。

7.在非正式,轻松的环境下进行代码审查

如前所述,代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此,我们认为像某些实践中建议的那样,以会议的形式进行代码审查效果并不好,不仅因为长时间的会议容易让效率低下,更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。

8.提交代码前自我审查,添加对代码的说明

所有团队成员在提交代码给其他成员审查前,必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外,还可以完成如下的工作:

(1)对代码添加注释,说明本次修改背后的原因,方便其他人进行审查。

(2)修正编码风格,尤其是一些关键数据结构和方法的命名,提高代码的可读性。

(3)从全局审视设计,是否完整的考虑了所有情景。在实现之前做的设计如果存在考虑不周的情况,这个阶段可以很好的进行补救。

我们在实践中发现,即使只有原作者进行代码审查,仍然可以很好的提高代码质量。

9.实现中记录笔记可以很好的提高问题发现率

成员在编码的时候应做随手记录,包括在代码中用注释的方式表示,或者记录简单的个人文档,这样做有几个好处:

(1)避免遗漏。在编码时将考虑到的任何问题都记录下来,在审查阶段再次检查这些问题都确认解决。

(2)根据研究,每个人都习惯犯一些重复性的错误。这类问题在编码是记录下来,可以在审查的时候用作检查的依据。

(3)在反复记录笔记并在审查中发现类似的问题后,该类问题出现率会显著下降

10. 使用好的工具进行轻量级的代码审查

“工欲善其事,必先利其器”。我们使用的是bitbucket提供的代码托管服务。

每个团队成员独立开发功能,然后利用Pull Request的形式将代码提交给审查者。复审者可以很方便在网页上阅读代码,添加评论等,然后原作者会自动收到邮件提醒,对审阅的意见进行讨论。

即使团队成员分布在天南海北,利用bitbucket提供的工具也能很好的进行代码审查。

再见,高三!

2012年6月8日17:00 那一刻,“考试结束,请考生立即停笔…….”,心中弥漫的是一种不知名的情绪,高中生活就这样结束了,就像做了一场很长很长的梦。再见了,这些年盛放的青春。一本又一本的参考书,练习册,我们曾经恨不得撕毁,却又掏钱买了一本又一本。感叹,题太多,又感叹,它们寿命太短,不知不觉就到了最后一页。毕业后,整理着以斤计算的书本,忽然发现每一本都成为了独一无二,承载着无法复制的青春。白天,长了又短,短了又长。花,开了又落,落了又开,从此后只开在记忆中。你不会了,你再也不会在每一个醒来的清晨,抱怨睡眠太少,日子太长。你再也不会,常常恳请别人帮忙带早餐;你也不会背着书包在铃声响起之前冲进教室,凌乱了自己。你再也不会,上课忽然走神,想到好玩的事偷笑,或者幻想成功后的自己….然后忽然醒来,问同桌老师讲到哪里了。你再也不会,忽然找不到橡皮擦;你再也不会,在老师要听写的时候找不到听写本,中午放学铃声响起找同学借碗票,到了食堂才发现忘了带饭卡;你再也不会,上课忘了关手机铃声,偏偏有人在关键时刻给你打电话.你再也不会,在上课时看窗外的树,看树的颜色随四季变化,从脆弱的嫩绿到随风飘扬,那是光阴的翅膀。你再也不会,在上课时闭上双眼,告诉同桌“老师来了叫我”。你同桌也不会,用手肘碰睡着的你,露出比你还紧张的表情。你再也不会,在被老师抽起来回答问题时,小声问你的同桌“老师问的是什么”你再也不会,在考试之后知道了语文选择答案,为错了N个选项愁肠百转.你再也不会,恶意编纂传播他人八卦,让无聊的生活有了不同的色彩。你再也不会,在食堂排起长长的队,感叹肉太少,价太贵。你再也不会,和你的兄弟在篮球框下挥汗如雨;你不会和你的死党,在晚饭后绕着足球场漫步,天南地北地有说不完的话。你再也不会,和你的朋友,细细数着毕业后要做的事,说兴奋地要去某地旅游,想考什么大学,要买某件衣服..你再也不会,忽然想吃学校门口的鸡丁面,然后让别人去带你再也不会,因为老师一次口误,笑得天翻地覆。你再也不会,偷拍下别人睡觉的样子,拍下偶尔晴朗的天空,拍下你想要留住的瞬间…你再也不会,只记住了别人外号,常常想不起那个人的名字你再也不会,在玩真心话时有窥探别人秘密的好心情;在玩大冒险的,幸灾乐祸开怀大笑你再也不会,在堆得比自己还高的书旁挑灯夜战,心中无数次痛骂中国的教育体制,又按捺不住澎湃的梦想你再也不会,望着那些也毕业学长学姐的照片,想象明年今日自己会在哪里你再也不会,抬头仰望夜空,忽然发现人生太过茫然,美好的青春在被摧残你再也不会,看着高考倒计时的数字变魔术般减少,想象它变成1的样子你再也不会,定下许多计划,下决心明天要重新开始,却从来没有实现过你再也不会,心中单纯地放着某个人。看到某个字,某个场景,在心中拐千百个弯也要想起他(她)你再也不会,喜欢一个人,却不靠近,却又在每个空下来的时间里想起。只求在最美丽的年华,遇见他(她)……(转)

输入输出__int64与long long int

在C中,整型默认为int,浮点型默认为double。所以用scanf读入short和long需要分别用%hd和%ld,而浮点数又有些特别,%f 对应的是float,而不是%hf,相反double对应的%lf,而long double对应的是%Lf。

在做ACM题时,经常都会遇到一些比较大的整数。而常用的内置整数类型常常显得太小了:其中long 和 int 范围是[-2^31,2^31),即-2147483648~2147483647。而unsigned范围是[0,2^32),即0~4294967295。也就是说,常规的32位整数只能够处理40亿以下的数。
那遇到比40亿要大的数怎么办呢?这时就要用到C++的64位扩展了。不同的编译器对64位整数的扩展有所不同。基于ACM的需要,下面仅介绍VC6.0与g++编译器的扩展。
VC6.0的64位整数分别叫做__int64与unsigned __int64,其范围分别是[-2^63, 2^63)与[0,2^64),即-9223372036854775808~9223372036854775807与0~18446744073709551615(约1800亿亿)。对64位整数的运算与32位整数基本相同,都支持四则运算与位运算等。当进行64位与32位的混合运算时,32位整数会被隐式转换成64位整数。但是,VC的输入输出与__int64的兼容就不是很好了,如果你写下这样一段代码:

__int64 a;
cin >> a;
cout << a;

那么,在第2行会收到“error C2679: binary '>>' : no operator defined which takes a right-hand operand of type '__int64' (or there is no acceptable conversion)”的错误;在第3行会收到“error C2593: 'operator <<' is ambiguous”的错误。那是不是就不能进行输入输出呢?当然不是,你可以使用C的写法:

scanf("%I64d",&a);
printf("%I64d",a);

就可以正确输入输出了。当使用unsigned __int64时,把"I64d"改为"I64u"就可以了。
OJ通常使用g++编译器。其64位扩展方式与VC有所不同,它们分别叫做long long 与 unsigned long long。处理规模与除输入输出外的使用方法同上。对于输入输出,它的扩展比VC好。既可以使用

long long a;
cin>>a;
cout<<a;

也可以使用

scanf("%lld",&a);
printf("%lld",a);

使用无符号数时,将"%lld"改成"%llu"即可。
最后我补充一点:作为一个特例,如果你使用的是Dev-C++的g++编译器,它使用的是"%I64d"而非"%lld"