Becomin' Charles

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

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

上周五，我们公司新来的工程师，在周会上分享git，有个同事挑战道，为什么git比svn更好？这个问题，如果是问我个人的话，我可能会有很多的理由，但是，就像我一贯的思维模式，说服别人的时候，必须给出足够令人信服的原因，不能使用主观因素去说服别人，那样只能引起争论。

对于，“为什么git比svn更好”这个问题，我真的很想给出一个肯定的答案，但是，我在探寻答案的过程中，遇到了困难。于是，我来尝试一下站在反面的立场来给出一份答卷，然后，我们再反过来辩论，于是就有了本文的题目。

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

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

我想，答案是否定的。（谈及这个东西的时候，我忍不住又想啰嗦了，我在跟人沟通的时候，常常发现，很多人无法分清楚，什么是主观的，什么是客观的，更别提要求他们分清楚，什么是自己已经知道的事实，而这里面哪些东西，站在你对面的人其实并不清楚，也即信息的不对称程度到底达到什么级别？所有这些归结为三个字，就是“想当然”。所以，当你想当然地觉得，这还用说嘛，或者觉得，显然这是个正确的理由的时候，其实，对别人来说，确实没有那么的理所当然）

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

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

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

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

拷贝代码，只会增加你自己的工作量，或者增加别人的工作量。不想越做越多的话，别那么干。

重构是一种艺术，如果你真想完全不破坏老的功能，正确的做法，是为老功能编写测试用例，然后直接改代码，抽取也好，剥离也好，就是不能拷贝，然后通过测试用例来判定，老功能是否受到破坏，而不是不敢动，通过拷贝来给自己做个沙盒，这一开始就是没有自信的表现，不能凭感觉，要靠科学。

2015年上半年，是牛市的半年。其实从去年开始，就陆续在牛市了，会玩的人，已经赚得很开心了。不能免俗的，我也进去了。现在来写这个文章的时候，我已经持续交易一两个月了。这时候出来写点感受，算是对自己心态的一个记录。

无论是在以前的团队，还是在现在的团队，都有人主张抽象出所谓的Service层，他们认为Model只负责跟数据库沟通，不应该混杂过多的东西，而同样也不赞成在Controller的Action里面，做太多事情，那样不利于复用。而他们赞成的方案，就是『抽象』出一层所谓的Service层，从而实现代码的复用。

而我通过观察他们具体的实现的代码，发现，这是一个很糟糕的想法。因为很少有人能忍住诱惑不去滥用。

在PHP里面，public static function其实就是最最原始的函数式编程模式的全局函数而已。任何一个软件里，如果全局函数满天飞，肯定不是一个『抽象』优秀的系统。如果不是绝对克制，那程序员会忍不住在任何地方，调用全局函数，甚至，只要一能复用代码，就忍不住去调用一下全局函数，得到好处后，就会进一步把更多的东西变成全局函数，而最后发现，所有的业务逻辑都在全局函数里了。

这种做法，其实就是饮鸩止渴而已，在单人工作模式下，绝对自我控制的人，你还能采用这种方式，但是一旦到了团队合作的时候，你很难阻止同伴滥用，哪怕滥用了一次，这种做法就会无休止蔓延，就好像破窗户理论说的，整个大楼一破再破，直到崩塌。

我举个简单例子，因为在全局函数里，你可以调用任何全局作用域的对象，当你那么做了以后，任何地方哪怕能复用到一部分这个方法，你就会忍不住去调用，因为是全局函数，总是可以被调用的，所以调用点的作用域，也全局化了。最后，整个系统就遍布着全局函数了。

可能说得比较绕吧，但是有个大原则我是信奉的，也希望读者你能看懂：全局函数和全局变量是邪恶的，我们应该拼尽全力去减少全局变量和全局函数，而不是增加他们。如果你想实现一个所谓的Service层的时候，请不要使用public static function，因为那根本就是全局函数。

另外，重申一下，不是说抽象Service层有多错误，我真正反对的是，使用public static function去进行所谓的抽象，那对抽象毫无帮助，说明你的抽象能力还停留在抽象一个函数的能力。

在我最新任职的团队里，我们采用Git正式作为我们团队开发管理的工具。我们使用Git来做版本控制，研发管理，和线上部署。我们将Git的版本库直接作为代码目录，来存放线上代码，发布的方法，就简化成了，将线上环境的代码目录，checkout 到指定的 tag，简单，快捷。

这个方法执行了一段时间后，发现一个新的烦恼，就是中央版本库的tag数量会变得非常多，多的时候，达到300多个，这其实也没什么了不起，但是我们自己采用gitlab来搭建自己的中央版本库，这个gitlab，还是很多bug的，当tag多了以后，整个网站都呈现出不是特别正常的样子，所以，就需要保持较少的tag列表，让网站保持比较高的性能。然后我就有了一个动机，就是删除远端的tag列表。

我用Google 搜了 how to delete git tags batch，发现老外的说法大概是，bulk delete，哈哈，英语不行啊。

无非就是shell下的一些做法，感觉实际使用上也够了。

首先就是找到远端要删除的tags列表，关键是用对指令。

1
2
3

git show-ref --tag

这个指令可以列出所有的远端的tag列表，然后就是shell下的一般处理手段了。

1
2
3

git push origin :

如上指令，会致使远程的tag被删除。用管道一连接，万事大吉。

1
2
3

git show-ref --tag  awk '/(.*)(\s+)(.*)$/ {print ":" $2}'  xargs git push origin

上面的指令就是拼接完整的指令了，不过这个指令，会删除远端所有的tag，慎用，如果希望删除符合条件的，应该修改awk指令的正则表达式。

删除完了远端的tag，本地的tag，删法还不是太一样，不过原理相同。

1
2
3

git tag  grep "v1.1.0.\d$"  xargs git tag -d

举个例子，上述命令删除本地所有 v1.1.0.x 的tag，这个指令，会最多删除10个tag。

在安装有些vim插件的时候，需要Vim支持Python，比如YouCompleteMe，但是，最近升级到Jessie后，发现，默认的vim，是不支持Python的，于是在网上搜索了一下，如果需要vim的二进制版本带有Python支持的话，应该安装一个叫 vim-nox 的包，其介绍为：

Vi IMproved - enhanced vi editor - with scripting languages support

就这样。

以前，我使用 Windows 作为自己的工作系统，后来，改用 Mac 作为自己的主要工作系统了。

在 Windows 下，快速搭建*AMP 环境，使用 xampp 或者 WAMP 之类的集成包，会一口气装好所有需要的软件，而在 Mac 下，相应的，做得比较好的是 MAMP，我选用的是与之对应的收费版本 MAMP Pro，总体差别不大。

前言

程序员圈子里流传着一个段子，说编程只有两个难题：缓存失效和变量命名。而我们中国有句古话，说：名不正则言不顺。这里面都提到了一个至关重要的问题，就是“取名字”。我认为，名字问题之所以如此重要，是因为，“名字”其实是对客观世界中实体的符号化表示。而这些符号，成为人类语言描述和思维的主要原料。如果名字有问题，就会严重干扰人类的思维。