代码评审

事实证明：有效的代码评审(Code Review，也有叫代码审查的），对保证代码质量具有十分重要的作用。因此这两年来我一直尝试着在这块不断改进和完善，以期望能形成一套合理、规范、有 效且高效的代码评审流程，这包括引入在线代码评审系统、走查和在线评审结合、规范评审Request的规模与有效性、设立评审专员等，用心不可谓不良苦 ^_^。大家也的确形成了及时提交Code Review Request或组织进行代码走查的良好习惯。不过我还是发现了一些问题。 ...

今天一位网上的朋友在使用reviewboard时遇到了问题，我们在评论中探讨了一下。他的问题目前已经定位，大致是这样的：他在Windows上用svn diff生成的patch文件在提交给reviewboard时出错，但在linux上生成的patch文件是没有问题的。后来他发现这两个patch文件内容稍有区别：Windows上的patch文件中的diff结果包含中文，比如“版本 10”；而在linux下生成的那份patch文件中，“版本 10"变成了"revision 10”。reviewboard拒绝了带中文的那份patch，估计是reviewboard的字符编码设置让其无法识别windows下的那个字符集。 ...

一直对Google这个牛X公司的内部开发过程很是感兴趣，毕竟像Google Search Engine、Google云计算平台这些伟大产品都是在这个开发过程下缔造出来的。但也许是Google保密工作做的很好，或许人家不是刻意保密，只是 因为工作太忙或人员太低调，没空派人出来宣讲罢了。外界对Google内部的开发流程知之甚少；知道一些，诸如20%项目，也只是皮毛。 ...

本文翻译自"The Boy Scout Rule"，来自于《程序员应该知道的97件事》一书中的某个章节。 童子军有一条规则：“永远保持离开时的露营地比你发现它时更整洁”。如果你在地面上发现了脏东西，那么无论是否是你留下的，你都要将它清理干净。你有意地为下一组露营者改善环境。（实际上，由童子军之父罗伯特·斯蒂芬森·史密斯·贝登堡编写的原版规则是这样的：“尝试让这个世界在你离开时比你发现它时变得更美好。”） ...

代码风格（style）一直是一个见仁见智的问题，但是对于一个团队而言，如果能在代码风格上达成一致，显然无论对团队还是对个人来讲都是大有裨益的。 ...

本文翻译自"Fulfill Your Ambitions with Open Source"，来自于《程序员应该知道的97件事》一书中的某个章节。 如果你在工作中没能开发那些可以实现你雄心壮志的软件，那你将有很不错的机会。也许你正在为一家庞大的保险公司开发软件，然而你实际上却宁愿供职于Google、Apple、Microsoft或是你自己初创的公司去开发下一个对世界影响巨大的软件。如果你去为你根本不关心的系统开发软件，那你永远也实现不了你心中的抱负。 ...

本文翻译自”You Gotta Care about the Code“，来自于《程序员应该知道的97件事》一书中的某个章节。 即使不用大侦探福尔摩斯，我们也能知道优秀的程序员能写出好代码。糟糕的程序员…则不能。他们生产出代码巨兽，而其他人则不得不去清理。你想写出好代码，对不对？你渴望成为一名优秀的程序员。 ...

本文翻译自"Improve Code by Removing It"，来自于《程序员应该知道的97件事》一书中的某个章节。 少即是多。这是一句有些陈腐的短小格言，但有时它确实是正确的。 在过去的几周里我对代码库所作的改善工作之一就是删除了其中的几大块代码。 ...

本文翻译自”Know How to Use Command-line Tool“，来自于《程序员应该知道的97件事》一书中的某个章节。 现今，很多软件开发工具被打包成集成开发环境（Integrated Development Environments，IDE）提供给开发者。微软的Visual Studio和开源的Eclipse就是两个颇受欢迎的IDE，当然还有很多其他类似的工具。很多程序员喜欢使用IDE，这不仅是因为IDE容易使用，而且IDE还可以让程序员无需过多考虑一些过程中的微小细节，特别是构建过程。 ...

近期产品线研发体系正式将Review Board这款优秀的基于Web的代码评审开源工具引入到开发过程中，作为产品线内各项目组进行代码评审的辅助工具。我对Review Board近两年多的关注总算没有白费，算是有了一个还算不错的结果。不过Review Board的正式使用并不代表一种结束，反而恰恰是一个新的开始。我们下一步要关注的是如何用好Review Board，让它真真正正地为改善产品质量和开发效率出力。 ...