邵珠庆の日记 生命只有一次,你可以用它来做很多伟大的事情–Make the world a little better and easier


174月/13

git 分支管理 branch

发布在 邵珠庆

Git的分支管理是Git的神器。拥有了它就会使我么管理代码更加游刃有余。那么什么是Git的分支管理?为什么要使用Git的分支管理?Git分支管理怎么用?
     在集中式版本控制中,冲突的合并是可怕的,是令人恶心的。所以很多版本控制软件通过加锁来拒绝多个人同时访问一个文件;而有的版本管理软件,则不是通过加锁的方式,第一个提交的人会很顺畅,但是如果第二个人提交,那么面临它的将是恶心的冲突解决。
    而在分布式管理软件中,冲突解决、合并、衍合,则是一种容易的事情,它是版本管理中的常态。
     而合并、衍合的主体就是分支。
    分支其实就是指向某种代码状态的一个指针。而合并其实就是将两种代码状态合并到另一种代码状态中。
     在Git中,正确的使用方法中,无处不在使用分支。比如,提交实际上就是本地分支合并到远程分支,更新实际上就是将远程分支合并到本地分支,在开发过程中,每加入一个功能或特性,都加入一个分支,当实验成功后合并到主分支...
    为什么要使用分支管理?
     我们来设想下面几种情况:1、我们在基于一个稳定的版本在进行开发,突然在稳定版本上有一个紧急的bug需要我们解决。2、我们在软件中加入了一个小的特性,但是开发到一半的时候,发现开发组的另一个的想法更有创意,所以我们想废弃自己的更改。3、自己想在软件中同时加入多个特性,但是希望并行开发开发,而不是依次开发。
     如果采用单分支形式的话,以上可能也可以实现,但是实现的复杂度可能就会加大。而应用多分支管理时情况就变的简单了。
     如果我们开发新功能时是基于一个新的分支的话,如果稳定版本有一个紧急bug需要处理,那么我们就可以切换到稳定版本的分支,然后修改bug,修改之后,我们再次切换到原先的分支继续工作,最后我们将该分支合并到稳定分支即可。如果我们想废弃正在开发的某个特性,如果该特性在一个单独的分支上,只需要简单的删除该分支即可。如果我们想并行开发多个特性,我们可以创建多个分支,分别开发,然后将每个分支都合并到稳定分支上即可。
     多分支管理,我们可以维护一个稳定的分支,然后某些特性或实验性的开发可以单独作为一个分支,这样开发过程就不会影响到稳定的版本。而且Git中分支的创建和切换基本上没有多少消耗。
    Git如何进行分支管理?
     1、创建分支
     创建分支很简单:git branch <分支名>
     2、切换分支
     git checkout <分支名>
     该语句和上一个语句可以和起来用一个语句表示:git checkout -b <分支名>
     3、分支合并
     比如,如果要将开发中的分支(develop),合并到稳定分支(master),
     首先切换的master分支:git checkout master。
     然后执行合并操作:git merge develop。
     如果有冲突,会提示你,调用git status查看冲突文件。
     解决冲突,然后调用git add或git rm将解决后的文件暂存。
     所有冲突解决后,git commit 提交更改。
     4、分支衍合
     分支衍合和分支合并的差别在于,分支衍合不会保留合并的日志,不留痕迹,而 分支合并则会保留合并的日志。
     要将开发中的分支(develop),衍合到稳定分支(master)。
     首先切换的master分支:git checkout master。
     然后执行衍和操作:git rebase develop。
     如果有冲突,会提示你,调用git status查看冲突文件。
     解决冲突,然后调用git add或git rm将解决后的文件暂存。
     所有冲突解决后,git rebase --continue 提交更改。
     5、删除分支
     执行git branch -d <分支名>
     如果该分支没有合并到主分支会报错,可以用以下命令强制删除git branch -D <分支名>

174月/13

数据分析这点事

发布在 邵珠庆

 

 先声明一下,按照传统的定义,我还真不是数据分析高手,各种关联算法,只会最简单的一种(话说不少场合还算管用);各种挖掘技术,基本上一窍不通;各种牛逼的数据分析工具,除了最简单的几个免费统计平台之外,基本上一个都不会用。所以,各种高手高高手请随意BS,或自行忽略。这里说点高手不说的。

       从微博段子说起,微博上关于数据分析有两个段子,我经常当作案例讲,第一个段子,说某投资商对某企业所属行业有兴趣,要做背景调查,甲是技术流,一周分析各种网上数据,四处寻找行业材料,天天熬夜,终于写出一份报告;乙是人脉流,和对方高管喝了次酒,请对方核心人员吃了顿饭,所有内幕数据全搞定,问谁的方法是对的;第二个段子,某电商发现竞争对手淘宝店,周收入突然下降了30%,但是隔周后又自然恢复,中间毫无其他异常现象,于是老板让分析师分析,苦逼的分析师辛苦数日,做各种数学模型,总算找到勉强的理由自圆其说,老板读毕,虽说不能让人信服,却也没有更合理的解释,某日,见对手老板,闲聊此事,“你们某段时间怎么突然收入下降?”“嗨,别提了,丈母娘去世了,回家奔丧,公司放羊了。”老板恍然大悟。

       两个段子,第一个段子,微博上一边倒的说,苦逼分析没有人脉有用;第二个段子类似,一边倒的认为,人脉的消息比苦逼分析管用多了。但是我想说的是,这个解读绝对是错的!

       先说第一个段子,其实网络不乏这种“人脉达人”,特别是媒体圈,一些所谓的“IT名记”或者“著名评论家、分析师”和各种互联网大佬称兄道弟,天天秘闻不断,但是呢?他们从不研究产品,不分析用户,所以,他们知道了数据,却不懂数据背后是什么,更不知道什么是重要的,什么是次要的,我有时会批评身边这样的朋友,别天天觉得自己知道几个互联网大佬的花边新闻,就当自己是资深业内人士了,正因为掌握这些东西又觉得炫耀,才反而忽视了真正有价值的信息和有价值的数据。这就是为什么混网络媒体的,见过市面的各种达人,在互联网创业浪潮里,几乎没有成功几率的真实原因,自以为人脉广泛,无所不知,其实正因为缺乏最基本的数据背景分析,所以才是看上去什么都懂,细究下其实什么都不懂。请记住一点,除非你是富二代,官二代,衔着金钥匙出生,那不在我的讨论范围里,否则,没有苦逼的经历,就没有牛逼的成就。

      我常订阅一些著名分析师的微博,他们透露的数据往往是很有价值的(这是我订阅的原因),但是他们的解读通常是惨不忍睹的,这就是只看表象的恶果,而且随便翻看一下他们的数据解读,可以说他们的数据感和数据认知贫乏到可笑,甚至缺乏最基本的数据校核和考证的能力,他们拿到了某公司核心数据又怎样?没经历过苦逼的分析,他们其实什么都看不到。

      第二个段子同理,如果不是持续有效的数据跟踪,怎么能得出下降30%的结论,这一数据结论与人脉得到的消息相互验证,才会得到完整真实的结果,否则仅仅是闲聊,你怎能知道对方企业管理对业绩影响的范畴,苦逼的分析也许一时没有人脉的消息管用,但是你所得到的对数据的认知和积累,是人脉永远不会给你的。

      所以,再次强调,基本的数据跟踪和日常的数据感养成,绝不是可以忽略和无视的。人脉情报可以成为数据解读重要的信息来源,但是绝不能喧宾夺主,替代基本的数据分析工作。

 

     下面说一下数据感,什么是数据感?就是别人说一个数据出来,你会琢磨一下这个是否符合常理,与你日常的数据观测经验是否一致,如果不一致,那么可能的理由是哪些? 比如12306号称一天几十亿次点击,如果你有数据感,第一眼就会质疑这个“点击”定义的合理性;比如曾经有人说某国内图片分享网站一天多少亿访问量,第一眼就知道这个“访问量”定义是有歧义的,(事后官方解释是图片加载量,这个和访问量差异几十倍。) 数据感需要不断的培养,和基本的逻辑(比如你应该知道中国有多少网民,每天有多少人上网,一个大概什么类型,什么排名的网站会覆盖网民的比例是多少),以及善于利用各种工具,我以前在巨头公司,得益于公司巨大的数据资源,可以看到很多互联网的核心数据;但是离开后,才发现,其实互联网上公开可获取的数据途径是非常多的,而且善于利用的话非常有效。每天去查询一些感兴趣的数据,经过一段时间积累,想没有数据感都难。

      作为公司或团队负责人,怎么培养员工的数据感,我其实也有一个建议,平时可以搞一些小的竞猜,比如团队集体竞猜新产品或产品改版上线后的日活跃用户,或者pv数字,或者收入数据,等等;然后看谁的最准,一种是惩罚制,最不准的请最准的喝奶茶,吃冰淇淋;另一种不惩罚,最准的累计积分后公司可以发一些奖品鼓励,这样下去大家的数据感就会在日常培养起来,而且对团队的气氛培养也有帮助。

       数据感之后,谈数据分析的方法,我的建议是,不炫技,不苛求技术复杂度,最简单的数据,所包含的信息往往是最有价值的,而很多人恰恰这一步都没做好,就总想着弄一堆挖掘算法;数据的价值在于正确的解读,而不是处理算法的复杂度,切不可喧宾夺主。 大公司的kpi制度,往往会产生偏差,比如技术工程师的评定,要讲究“技术复杂度”、“技术领先性”,直接导致简单的事情没人肯做,最基本的工作不认真做!所以往往是大公司的分析工程师,为了评高级工程师,非要简单问题复杂化,四则运算就搞定的事情一定要弄一套诡异的算法,最终非但浪费了资源,消耗了时间,而且往往由于工程师对业务理解的漠视,对应的产品人员又对算法的陌生,导致了严重的理解歧义,从而出现各种误读。

 

       下面说关键,数据解读,正确的数据解读,是所有数据分析工作最关键的一步,这一步错了,前面的所有努力都是白搭,然后,往往很多人简单的以为“数据会说话”,他们认为把数据处理完一摆就ok了,所以我看到很多知名分析师拿着正确的数据信口胡诌;而更有甚者,显然是故意的行为,一个非常非常著名的、口碑极佳的跨国企业,曾经就同一份很酷的数据,在不同的场合下,为了市场公关的需求,做出不同的解读;这简直就是道德问题了。

      数据解读,不能是为了迎合谁,要遵循数据的本质,要遵循科学的逻辑,要有想象力(配合求证),可能有时候也需要依赖人脉关系所获得的情报,(这个也有很多典型范例),这个具体再怎么说可能我也说不清楚,说几个反面例子也许更容易理解。

      1、因果关联错误,或忽略关键因素,A和B的数据高度相关,有人就片面认为A影响了B,或者B影响了A;但是,有时候真实原因是C同时影响了A和B,有时候C被忽略掉了。

      2、忽略沉默的大多数,特别是网上投票,调查,极易产生这种偏差,参与者往往有一定的共同诉求,而未参与者往往才是主流用户。

      3、数据定义错误,或理解歧义,在技术与市场、产品人员沟通中产生信息歧义,直接导致所处理的数据和所需求的数据有偏差,结果显著不正确。

      4、强行匹配;不同公司,不同领域的数据定义可能不一致,在同一个公司内或领域内做对比,往往没有问题,大家对此都很习惯,却有评论家不懂装懂,强行将不同定义的数据放在一起对比做结论,显著失真