Behind the Code

bzr有很多种使用方法，我们首先介绍集中式的使用方法，你可以假装他就是svn。 bzr的基本语法是 bzr 命令 [参数] 首先创建一个代码仓库#bzr init-repo –no-tree ftp://user@host/repo-name这里使用了ftp作为代码仓库的中心服务器，bzr支持的协议有很多ftp，sftp,http,bzr等等，我这里使用了ftp为了方便。 命令init-repo是创建代码仓库的命令，–no-tree是说明这个代码仓库本身的物理位置是不参与开发的。 然后创建项目，更精确的说是创建一个分支#bzr init ftp://user@host/repo-name/proj1-trunk 然后checkout代码#bzr checkout ftp://user@host/repo-name/proj1-trunk proj1然后就是熟悉的场景了，可以随意的使用，折腾，捣乱，然后commit到中心代码库。其他的使用者也可以随时update获取最新的代码。怎么样，跟svn一样吧，甚至连基本的命令都一样，比如commit/ci，update/up，revert，info，state/st。 这里面要注意一个问题，就是使用init命令创建的是一个分支，一个branch。branch在bzr当中是非常重要的，如果你了解一些svn详细的东西，你会发现被管理的每一个目录都有一个叫做.svn的目录，也就是我们可以认为从任何的子目录开始都是一个完整的可以被单独checkout的小项目。而bzr则不然，他只是在每一个branch的目录下才有一个.bzr目录，也就是从这一点开始，才是branch的根，下层的任何目录都不能成为一个单独的独立结构。而这个branch是需要用init命令搞定的，不能想svn里面一样随随便便的就创建一个目录就完了。 所以从这里我们看出，bzr是完全可以按照svn的思想来使用bzr。不过，这不就没意义了，我为什么不直接用svn呢，所以我们在使用bzr的时候，还是有一些区别的，下篇再说。

我们在开发过程中一般都使用VCS工具，最普遍的工具就是svn，但是在使用过程中还是会存在一些问题的。 假设一个场景一个项目要进行开发， A是底层核心功能开发人员，他要对底层进行开发，并且在第一时间所有的人都要获取他的代码 B是功能开发人员，进行一个feature1的开发 C，D是功能开发人员，进行另外一个feature2的开发 feature1和feature2要公用部分代码，比如同一个接口文件，并对他进行修改 假如我们用svn进行开发，这里面是有一个问题的，因为A的存在，feature1和feature2的开发并不能完全分开，而在开发阶段B，C，D三个人都不能随意的提交代码，否则feature1和feature2都会相互影响。如果他们真的都是分开的功能也没问题，但是因为C，D是一个feature的负责人，他们之间必须要进行代码交换，而因为svn是集中式开发，那么他们应该，必须，也只能通过svn进行代码交换。如果 C提交代码，要求D更新代码 A提交代码，要求所有人更新代码 D获取代码，A和C的，是正确的代码 B获取代码，死菜了，因为C的代码是他不需要的，会影响他的工作，甚至都无法编译通过 这个是一个很普遍的场景，尤其是对人数多一些的小组。那么我们应该如何避免这种情况的发生呢？答案是使用DVCS系统，也就是分布式代码管理系统，例如bzr，hg等。 DVCS的出现可以方便的解决这类问题。与svn等传统VCS系统不同，DVCS并不需要一个中心服务器，每个人的开发工作区都可以认为是中心服务器。DVCS的基础是分支，每需要一个开发工作区，都是基于已有的某个开发工作区创建一个分支，然后开发，然后进行分支的代码merge。因为这种特性，DVCS的分支操作代价非常小。当然对于管理，发布等等我们还是需要一个中心服务器的，那么我们只要一个放在中心服务器的分支就足够了，使用完全相同的技术和下面的各个开发工作区进行代码交换。从技术上，他们的地位是完全等同的。根据这些，我们再使用DVCS假设一下上述的开发场景 在中心服务器创建技术开发版本 A，B，C，D分别根据中心服务器创建自己的开发分支 A进行开发，每个阶段，B，C，D基于A提供的代码进行merge，比如A自己架设一个（临时的）ftp C进行开发，每一阶段，D基于C提供的代码进行merge，相对D的开发来说，情况一样。他们的开发完全不影响B的开发 最终都开发完成，一并merge回中心服务器 这就非常顺利的避免了上面遇到的问题。而且，DVCS因为是把自己的工作区认为是代码仓库（repository），所以可以随时的提交代码，随时记录自己的开发变更。而这个在svn当中有时就比较头疼，如果一个feature要开发时间比较长，那么中间的每一个小阶段的代码就很难记录了。 当然了，你可以说，我在svn当中采用给每个人开分支的方法解决这个问题。bingo，没错，但是，这已经就是DVCS的思想了，不是么？那么为什么不用一个现成的DVCS工具呢？

SCM—-Software Configuration Management，软件配置管理VCS—-Version Control System，版本控制系统 其实这是两个八竿子打不着的两个东西，但是在这里我只想从某一个侧面来阐述一下从代码的角度看这两个东西。VCS，这是一个最常见的东西，cvs，svn，bzr等等都是VCS，这类的工具更加关注的是如何管理好代码的版本之间的关系，各个分支之间的关系。而SCM呢？功能上，除了这些，他更加注重的是管理和控制。相应的产品有Rational ClearCase，Hansky Firefly等。因为我只用过Firefly，所以我只好用这个举例子。在Firefly中，你Checkout一个项目是有一些限制的，比如，你只能Checkout到你的C:\等，而且从管理的界面上，管理员可以很方便的看到现在有几个开发工作区。这里面要注意一个问题，如果你是svn的使用者，你会发现，你checkout的工作区，你换了地方以后还可以继续使用，比如你执行了mv proj1 proj2这样的命令行，并不妨碍你使用。但是在Firefly这类的产品中，你这样的操作就会使得你的工作区无法工作。你根本无法提交你的代码。这里面体现的是一种集中管理的思想。企业级的开发，更多的采用是SCM这种管理方法，而社区的开发更多的是使用VCS这种工具。这里面我们可以看到一些理念上的不同，企业关注的是稳定性和管理性，而社区关注的是修改后的结果。其实，更多的还是一种对待开放的心态的问题。 从发展的角度，SCM我不清楚，而VCS的一个分支DVCS（分布式VCS）的出现更加的加剧了这种区别。DVCS出现的根本就是为了更加的开放，更加的自由，那么从理念上和那种要管道细枝末节的企业思想更加的背离。这里面的一个突出的矛盾就是企业的心态了，如果你关注的是成果，你不是好像面对一群小偷一样看着你的开发者，VCS对很多企业是足够用的。要知道，我们是程序员，我们是有职业操守的。 SCM的发展和VCS的发展也能从一个侧面反映了现在软件开发的情况，社区的软件，一般都是很活跃的。SCM主要是公司来做，而VCS则是社区的最火。从这些管理的角度来看，我还没有发现基于社区VCS做的SCM了，也许是我孤陋寡闻吧。 如果我自己管理开发团队，我会选择VCS/DVCS，工具可以是svn和bzr。为什么要使用DVCS，我会在以后解释的:)当然了，广义上SCM还有一些变更管理，缺陷跟踪等等，在此我们便不再考虑了。

现在很流行的RoR是一个有Coding By Convention讲究的框架，尤其是从我道听途说来的ActiveRecord机制。简单说一下，就是我有一个类叫做User，有id，name等属性，那么我就可以直接使用一个叫做findByName的方法从数据库里面获得这个user。而findByName是不需要提前定义的，因为RoR会帮你处理，他发现没有这个方法，那么就去一个地方同意处理，看到你要find，而且是byName，那么她就去帮你搞定。但是这里面我有一个问题，就是如果我写了findByName1这样的方法会如何？结果估计很简单，死翘翘。其实写错的可能性是不小的，那么为什么ActiveRecord的作者会这样写呢？我觉得这是一个程序员的信任感的问题，也就是他相信我们这些使用者不会写错。当然了，写错了倒霉的是我们自己。而还有一种场景，就是很多时候，库作者是不信任使用者的。比如java里面就经常遇到encoding转码时候输入一个encoding的名字，然后外面必须try catch一个UnSupportedEncodingException。我觉得这就是库开发者的一种不信任，或者跟进一步，他是对程序运行的正确性的一种自我保护。更多的存在于需要编译的语言中。而且有人说过，一些比较下层的代码是不需要这种检查的，为什么，还不是因为是自己写的，自己相信自己。 那么，我提出一个问题，就是这种检查的尺度是什么？都检查，开发者累死，开发效率必然不高。都不检查，那么一些尽早，尽快发现问题的可能性就没有了。这个权衡很难，我们也应该看看别人的优秀的API是如何设计的。