How to review others' code?

最近在思考如何才能高效地完成review，让review不要变成形式化的空架子。

programming4scientists 上看到一个how to review code 的一篇博文。

关于review，有以下六点：

1. 首先需要对要review的东西有一个全局的认识。如果代码已经差不多完成，则对于架构层面、设计层面的改动则很少会发生因为这样代价很高；反之如果是设计阶段，则指出的问题便多多益善。

2. 必须提有建设性的意见。不只要指出问题，还有提出问题的解决办法。如果有bug，提出解决方案；如果代码风格方面意见，给出更好的风格以及why。

3. 问。会碰到很混乱或者含糊不清的代码，通常这种情况下，作者对这一块也会没有很清晰的认识，问他们，使他们思考，从而建立清晰的认识。

4. 代码风格是非常私人化的，除非非常不协调或者晦涩难懂，不要吹毛求疵。给出建议和解释为什么更好。

5. 跟随你的直觉，如果你有非常多的经验，你会“嗅到”坏代码，当然这种能力或者说本能是随着经验的不断丰富而形成的。

6. 不要将自己的意见强加给作者。你只是给建议，而不是接管编码权。

anything else ？

-----------------------------------------------
usernet上得到一些反馈，再补上以下四条：

7. Review meeting最好安排有专门的Moderator，控制整个Review过程：比如会议室的预定；会议时间的掌控等。

8. Reviewer的指定必须有针对性：他必须对你的代码流程比较熟悉,最好是一个项目组的同事。

9. 如果有测试报告,最好把测试报告也作为Review的对象。

10. 必须有一个书面性的东西追踪你的review和work after review。

Blueprint

未来IT四大技术：浏览器；并行计算；存储；虚拟。

淡化操作系统，以浏览器作为用户接口，通过Cloud computing来对用户的需求作业进行处理。

并行计算应用于Cloud中，实现多核多线程同步。

对存储的要求便更高，既要保证实时性，又要保证可靠性、安全性等。

通过虚拟，对用户平台进行透明化。

对于浏览器而言，复杂到操作系统级的话，对于目前各大系统来讲，都差得太多。仅靠现存技术，很难再有大的提升，稳定性损失量/功能增量 越来越大。

并行计算，如何确保多处理器多线程处理的高效性，因为多核状况下，现有的多线程方法，并不一定有效，相反，很可能还会低于不使用多线程同步。

Keywords: browser; parallel computing; storage, virtualization

反向索引-Inverted Index

以下来自维基百科：

倒排索引（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，被用来存储在全文搜索下某个单词在一个文档或者一组文档中的存储位置的映射。它是文档检索系统中最常用的数据结构。

有两种不同的反向索引形式：

• 一条记录的水平反向索引（或者反向档案索引）包含每个引用单词的文档的列表。
• 一个单词的水平反向索引（或者完全反向索引）又包含每个单词在一个文档中的位置。

后者的形式提供了更多的兼容性（比如短语搜索），但是需要更多的时间和空间来创建。 以英文为例，下面是要被索引的文本：

• T₀ = "it is what it is"
• T₁ = "what is it"
• T₂ = "it is a banana"

我们就能得到下面的反向文件索引：

 "a":      {2}
"banana": {2}
"is":     {0, 1, 2}
"it":     {0, 1, 2}
"what":   {0, 1}

检索的条件"what", "is" 和 "it" 将对应这个集合：

对相同的文字，我们得到后面这些完全反向索引，有文档数量和当前查询的单词结果组成的的成对数据。 同样，文档数量和当前查询的单词结果都从零开始。所以，"banana": {(2, 3)} 就是说 "banana"在第三个文档里 (T2)，而且在第三个文档的位置是第四个单词(地址为 3)。

"a":      {(2, 2)}
"banana": {(2, 3)}
"is":     {(0, 1), (0, 4), (1, 1), (2, 1)}
"it":     {(0, 0), (0, 3), (1, 2), (2, 0)}
"what":   {(0, 2), (1, 0)}

如果我们执行短语搜索"what is it" 我们得到这个短语的全部单词各自的结果所在文档为文档0和文档1。但是这个短语检索的连续的条件仅仅在文档1得到。

-------------------------------------------------------

为什么要提出这样一种索引方式呢？

举个例子，如果有两个文档，doc1 & doc2 内容分别如下：
Doc1: it is what it is.
Doc2: what is it.

正向索引建立：
文档名 关键字 次数
Doc1 it 2
Doc1 is 2
Doc1 what 1
Doc2 what 1
Doc2 is 1
Doc2 it 1

不难发现，对于单文档内部检索，正向索引的建立，可以保证快速的进行检索。但对于全文检索，却很难有很好的性能，甚至由于实际资源的限制，而不可行。

“正向索引的查询往往满足每个文档有序频繁的全文查询和每个单词在校验文档中的验证这样的查询。”

题外话：
在设计某个问题的解决方案时，可能自身由于一直深入于整个工作，对问题的理解越来越深，不断有新的思路出来，继续不断有些方案出来，从来最终形成了整个解决方案。但或许，在整个过程中的某个时刻，跳出来，可能会有更高效的方法。比方说，可以参照算法方法论，如动态规划、贪心算法等来进行具体方案的求解。

Keywords: Inverted index; full-text search

关于版本控制的思考

1. 对于一个公共的配置文件，可能一个产品的很多模块都在使用，经常会出现并行修改。我们需要将这个配置文件按照各个模块进行分拆吗？

驳斥：这本身就是版本控制工具的优点之一。对于公共配置文件而言，使用版本控制的并行修改再diff-merge 很好的解决了将文件按照功能进行分布造成的文件的繁多和复杂。

但是，如果该文件不是文本格式。比如对于开源的自动测试框架 Robot Framework，Test case 全是html的，内部都是表格，diff 不能很好的分辨出文件更改的部分，于是，就变成了最原始的手动diff，然后手动merge，当文件越来越大，带来的后果也许是灾难性的。按照功能对公共文件进行切割未必是个坏的、完全做无用功的方案。

2. 在对代码进行更改后，还需要在后面加上 // Modified by Chris, 2009.02.16. 类似字样吗？

驳斥：那干脆别用版本控制工具了。

的确，这个问题的争论在很多bbs上都看过了。使用任何一个版本控制工具，完全可以通过历史记录查到某某时间某某人修改过哪几行代码。但对遗留代码的更新时，加上自己的签名未必是个坏事儿。我们可以迅速地知道曾经改过那几行，以及在出现错误时，迅速去定位是否是自己更改的代码跟原先的代码冲突或者矛盾。

3. 在更改过bug时，是否需要在更改的语句后面，加上 // Bug fixed : why, how, pay attention. 等来描绘出现bug的条件，如何解决的，以及未来需要注意的。

驳斥：版本控制工具在提交时是可以添加comments的，添加上提交所更改的东西就可以了。或者可以使用其他的 bug trace 工具。

这样做当然是可以的。但比如后来，有人需要去进行代码的更改，刚好改了这一行，也许以前辛辛苦苦更改掉的bug，又出现了。但如果有这句注释在后面，在别人进行更改的时候，看到这行话，他就会知道，奥，这个地方可能会出现这样一个bug，需要注意这些东西。。。，也许代码质量会因此更高。

也许，上述的几个问题，对于某些人来讲可能嗤之以鼻，他会拿出一系列的解决方案来完美的解决这些问题。OK，那是好事儿。我在这儿想说的是，版本控制只是一个工具，不需要教条的为了遵守而遵守，有时候，一些不规范，不是末日。

Keywords: version control;