心得体会

SVN为什么比git更好

首先我表明一个根本的立场,我个人更喜欢用git,但是,这仅仅是一个个人偏好。当我们需要将一种技术方案带给整个团队的时候,并不是由我们的个人偏好作为主要决定因素,而应该充分去权衡利弊,选择对团队,对公司更有效率的方案。抛开个人立场,理性评估利弊,可能才是我认可的一个资深程序员,或者一个架构师的本分。

我所在的团队,现在选用的技术方案是git作为全公司的版本控制系统,我们一共有差不多20个程序员,使用五种以上的程序设计语言,研发维护四个左右的项目,属于小型创业公司中,研发规模中等偏上的企业。使用git作为版本控制系统,在我加入公司之前,已经是既成事实了,在我听说这一点的时候,我非常高兴,因为我说过,我喜欢git。

Keep Reading — 2641 words totally

甚至早在踏上程序员的工作岗位的第一天之前,我就开始使用版本控制系统了,那时候,使用的是SVN。而现在工作五年多了,我使用的版本控制系统,换成了Git。现在,我试图通过一个分享,将我的同事,或者一般的小伙伴,带入到Git的世界,这时候,我就必须搞清楚很多基本的问题,比如,这个问题,为什么我们需要使用版本控制系统呢?

上周五,我们公司新加入的工程师,给大伙分享了Git的一点经验心得,谈及这一类的问题的时候,表达了类似非常理所当然的态度,甚至我都不记得他有提及过任何相关的词句。但是,假如我现在必须给一个从来没有用过版本控制,甚至不知道版本控制的人,讲解版本控制系统的必要性的时候,这个问题真的有那么理所当然么?

Keep Reading — 1571 words totally

fan-out/fan-in

我承认,判断一段代码的好坏,有很多主观的因素,你大可以来批评我,『你看不惯别人的代码,别人还看不惯你的代码呢,既然如此,何不和和气气,多包容包容』。我的回答是『No,不好就是不好,我在批评的时候,除了主观因素,确实还有一些客观标准的,不信拉倒』。

今天,就来说说标题的这个,不知道哪个货翻译的,我故意这么写的,看不懂实属正常,一下子看懂的人,我才觉得莫名其妙。英文的原文是high fan in,low fan out。讲的是类(Class)的一个设计原则。具体是什么意思呢?就是说,一个类,尽可能不要去依赖别的类,就是所谓的low fan out,你写一个类,应该尽可能多地被别的类所依赖,这就是所谓的high fan in。

Keep Reading — 888 words totally

经常,你可能会觉得,原来代码写得不好,想要重构,但是重构的时候,是先把原来的代码拷贝过来,确保不影响老的功能。然后新功能做好后,逐步修改老功能。最终实现完成重构,代码得到优化。

上面的故事和计划很美好,所以,它们十有八九不能被完整执行,后果往往就是,拷贝了一堆代码,老代码大摇大摆继续运行,新功能不断压来,系统里多了一堆代码的拷贝。这时候,只要祈祷不要出bug就好,不然就是双倍的工作量,恶劣的,还会造成数据不一致,新老代码操作数据有细微差别就会有这种情况,一般差别很细微,还特别不易发现。

如果相信我,一个一线写了五年代码的人,那就请相信,任何时候,都不是你拷贝代码的借口,哪怕是打着『重构』、『优化』这种冠冕堂皇的借口,也不可以,哪怕有 deadline,也不可以,哪怕时间紧也不可以,刀架脖子上了,那也不可以,那时候还写个屁代码啊?还不快跑。

Keep Reading — 537 words totally

Git——以及所有一切的版本库——的核心目标,就是保证代码不会丢失。我所熟知的两个版本控制工具——SVN和Git——都是通过提交代码(commit)来实现这个目标的。

虽然我反对使用SVN来类比Git,但是,如果仅是为了强调它们的“不同”,而进行比较,我觉得还是有助于理解的。

SVN使用过程中,版本仓库是在云端的,程序员的个人电脑上,只是一个工作副本,或者叫代码暂存,如果写好的代码,没有被送到云端的版本库,就意味着有潜在丢失的风险。所以,SVN的提交(commit),其本质,就是将代码从本地电脑传送到云端服务器,这个过程,我们称之为“入库”。

Keep Reading — 1861 words totally

说实在的,Git我已经学习了很久很久,从最开始的,零星的学习,然后偶尔使用,到现在成为公司的唯一版本控制方式,断断续续没有两年,也有三年。Git官网上写着,简单易用(easy to learn),我就是被这四个字骗了,开始用上了Git。现如今,它已经成为一种避无可避的工具了,必须学会。

要开始上手使用Git,可能真的是很简单的事情,如果你翻开一些成体系的文档或者书籍,可能上来会教你使用git init命令。这个命令的目的是创建一个新的git版本库。但是,就我个人的经验来看,一个新人,接触版本控制系统,可能第一件事情,往往是融入一个开发团队,接手一块业务,然后开始贡献代码,不太会是上来先建立一个版本库。

Keep Reading — 1264 words totally

Git是目前世界上最为炙手可热的版本控制系统。它是如此的流行和重要,以至于全世界程序员的工作和生活,都可能因之而改变。

Git是一个版本控制系统,帮助程序员管理自己的源代码的版本变化,保证它们不会丢失。它只是开发工作中的一个工具。但是,一个“工具”,为什么可以重要到足以改变这个“工作”本身?我们可以以政治经济学范畴的概念,来理解一下这个问题,Git就相当于是生产工具,生产工具的发展,可以进一步解放生产力,从而推动了社会的进步。Git不是历史上第一个版本控制工具,显然也不会是最后一个,为什么到了Git出现的时候,就产生了近乎变革般的变化?

Keep Reading — 1138 words totally

如果数据库只有一份,那就是数据存储的单点,对于要求可靠性的服务来说,就存在一个单点故障的可能性,这个时候,我们就要通过复制镜像,来解决单点故障。复制还有一个额外的好处,就是可以根据主从,做读写分离,这样,就不会在写入的时候,因为锁表,而降低MySQL的并发性能,所以MySQL复制是MySQL中非常基础的一种操作。

怎么配置

配置Master

Keep Reading — 860 words totally

这是一个交互案例,很多时候,我们可能就是需要一种交互来完成一个操作,但是我们就是没法想出来很好的解决方案,这种的案例,我遇到不胜枚举,但是每次,我都没有把这种奇葩交互给记录下来,今次,我就想到了要记录下来这个事情,以便今后查倒的时候,可以有据可凭。

为什么

不知道多少人,看了我的标题,能理解出来我要做的是个什么交互?其实场景是这样的,我写了一个WordPress的插件,功能是显示博客的文章归档,名字叫 Better Extended Live Archive,这个插件目前能提供三个 tab,每个 tab 一种归档的纬度,来展示用户博客的文章列表,比如按照时间纬度,按照分类纬度,按照 tag 的纬度。

Keep Reading — 1396 words totally

好吧,我必须要承认,我是一个标题党来的。本文英文名称意思比较准确。什么?你没看到英文名称在哪?不是写给你看的,你当然看不到。

在Web开发过程中,你总是因为各种理由,需要跟服务器打交道,因为各种理由需要承担一点点运维工作,哪怕你需要运维自己的blog,比如用Linode这种东西。那么服务器运行,就少不了log,log不少,就不得不翻滚,就是rotate,不知道中文是啥……

为什么要rotate呢,理由是比较简单的,比如在32位系统里,默认文件写到2G大小的时候,就会导致进程core掉,引发很多神奇的问题和bug,你也可以用一些补丁和编程技巧突破2G这个限制,但是你真的需要一个超过2G的log么?回溯总归不方便吧,按日期检索总归不方便吧,反正理由很多了,就是一定要rotate的。

Keep Reading — 1236 words totally