Becomin' Charles

你手下有一群很棒的工程师，并且，他们想要在自己的职业生涯中更进一步。由于他们付出的努力，他们的团队在成长，而你，想要对他们的工作成果有所表示，最显而易见的一个方式，就是让他们负责管理他们自己创建的团队，尤其，他们已经是团队的事实上的 Leader 了。但是，这真的是他们想要的么？或者只是他们所相信的“自己应该想要的”？

当我在使用git的时候，有三个东西的出现，一度让我非常困扰，就如题所述，staging，index，和cache。

之前，我写了一篇文章《SVN为什么比git更好》，主要是从非常朴实和现实的角度，从一个为全团队选型的角度，分析了为什么SVN比git更好。但是公私分明，作为我个人来说，我想我还是更喜欢git的。

下载了《生活大爆炸》打算重温，但是文件名实在是太过长了啊，受不了啊！

首先我表明一个根本的立场，我个人更喜欢用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去进行所谓的抽象，那对抽象毫无帮助，说明你的抽象能力还停留在抽象一个函数的能力。