P9手机连不上电脑，论版本管理的重要性

                                                                                                    听说华为出了一款带电话功能的莱卡相机，于是买了一个。


为了手机后面的莱卡牌子，买了一个华为P9。拍照功能确实不错。


不过，今天在这个手机上发现一个问题：
第一步、发现手机无法连接到电脑（已经打开USB调试）：


第二步、华为手机助手无法连接手机


所有设置都已经按照操作步骤执行了（这点我就不赘述了）
（手机连不上电脑，不是我说的重点。）
第三步、发现wifi连接，要求《华为应用市场》版本为7.1.1。


第四步，我看了一下手机上的版本号：





点击检查更新：




第五步，通过官网希望下载V7.1.1以上的版本


此时，我只想说：








如此大厂，版本管理尚且有问题，强大的IT支撑平台，众多工程师保障，都不可避免这么低级的版本管理问题。
何况我们这些小公司的，很可能面对更多的版本问题：

1、板子改版投板了，发现板子版本是旧的，贴片的时候，发现钢网和板子对不上
2、软件调试的时候，好容易功能实现了，为了增加功能，越加越乱，最后稳定版本再也找不到了。
3、第一版的BUG在第二版修复了，第三版又复现了。。。。
4、版本更新没有增加说明，本地版本没有明确的含义，如下：




以上情况，各位开发过程中有没有 经历过。当遇见这些操蛋的事情的时候，是不是一万只草泥马在内心奔腾？

尤其，现在还要推广敏捷开发，版本多得乱得比草泥马还多。



版本控制透过文档控制（documentation control）记录程序各个模组的改动，并为每次改动编上序号。这种方法是工程图（engineering drawings）维护（maintenance）的标准做法， 它伴随着工程图从图的诞生一直到图的定型。 一种简单的版本控制形式，例如，赋给图的初版一个版本等级“A”。当做了第一次改变后，版本等级改为“B”，以此类推等等。



通过百度文库，我们可以看下《华为的版本号说明》

华为版本号说明外部版本号的完整的产品版本名称规则为：
商标+[子商标]+型号+中(英)文名称+VxxxRxxx[LLL]CxxBxxy[SPxx]

1）[ ]表示可选。
2）"V"、"R"、"C"、"B"、"SP"为分隔符；V后面三位数字；R后面三位数字；LLL可选；C后面两位数字；B后面三位数字；SP后面两位数字，只在热补丁时使用。
3）   商标、子商标、型号、中(英)文名称根据产品命名相关规范、指导及规则制定。


1 对"Vxxx"的说明"Vxxx"(version)代表某一产品或其系列产品，根据市场定位或开发平台的不同，一个产品分为若干个V 级版本。每个V级版本根据市场竞争需要、技术、功能特性与成本因素等，有一个总体开发规划，按计划开发若干个R(Release)级版本。V 版本可以包含若干个Release版本。
如果满足下列任何一种情况，则必须产生新的Version 版本，即产品的大版本：
产品市场定位发生变化，引起产品特性的重大变化；
产品平台发生变化，与原有平台不能兼容。
V版本以三位数字表示，数字间不准许有任何其它字母、符号出现，从100开始，不同平台或技术的同类产品尽量采用大数标示，即V后面第一位，如V100、V800。


2. 对"Rxxx"的说明"Rxxx"(Release) 版本表示产品特性版本，可以包含若干个特性，形成一个具体的系列产品，一个Release版本纳入什么特性，需要综合考虑市场竞争、技术与成本方面的因素，系列产品也可有自己的特性版本，系列产品可以在特性版本号上用特别的字母或数字表示。产品路标规划确定了该产品所有的大版本(Version)，以及每个大版本(Version)包含的特性版本(Release)、系列产品的发布时间和所包含的特性。特性版本需要按照产品开发流程所规定的各个评审决策点进行评审。
如果满足下列情况，则必须产生新的Release 版本：
Ÿ     产品市场定位和产品平台没有发生变化，但是，衍生新的系列产品；
Ÿ     综合考虑市场竞争、技术与成本方面的因素，产品特性发生变化，有计划地向市场发布的版本。
R版本以三位数字表示，数字间不准许有任何其它字母、符号出现，从001开始，在同一个V下面以1为单位连续递增，例如：R001、R002。


3. 对"LLL"的说明"LLL"为海外版本标识符，以三个字母表示，可选。对于国内版本，此项可以省略。具体的对应关系请见附表1( 海外版本标识符和相应的语言(国家)对照表)；如果某个版本可以用于某一个地区，可以在附录中选择本地区的主要国家的标识符作为版本的海外标识。

4. 对"Cxx"的说明
"Cxx"(Customer)表示计划提供给客户的版本，以两位数字表示，数字间不准许有任何其它字母，从01开始，以1为单位连续递增。实现该C版本特性集内特性的各个B版本前应标识出Cxx。Cxx与某些Bxx对应，同一Bxx为Cxx版本时，Cxx不以Bxxy的y位及 SPxx而变化，即同一个Cxx可能对应一个Bxxy或同一Build的多个改错版本或热补丁版本。


5. 对"Bxxy"的说明"Bxxy"(Build)表示开发与IBT过程中的Build版本。B后面的三位中的前两位xx表示规划的Build划，最后一位y表示每一个Build的过程改错版本，包含了网上问题修改版本和转测试回归版本。其中，
xx从01开始，以1为单位连续递增；RXX变化时，Bxxy版本复位到B010。
y从0开始，以1为单位连续递增。Bxx变化时，y复位到0开始。


6. 对"SPxx"的说明
SP是为了解决问题，对网上运行版本的热补丁版本，以两位数字表示，数字之间不允许有任何其它符号，如空格、"."、"-"等。从01开始，以1为单位连续递增。如果版本不是补丁，SPxx要省略。 例如：SP01、SP02。 SP为某一发布版本的补丁版本，只有对于已经发布的版本需要做补丁版本时才会有此项。做SP时，前面的所有版本序号不变。
举例说明：
A. V100R001B010 表示V100R001的第1个Build的首个转测试版本，不发给客户。
B. V100R001B011 表示V100R001的第1个Build的第1个转测试改错版本。
C. V100R001C01B023  表示V100R001的第2个Build为第1个客户版本，一般用于试验局或ESS局。实际交付件为第2个Build的第3个改错版本。
D. V100R001C01B023SP01  表示对V100R001C01B023的第一个热补丁版本。
E. V100R001B030 表示V100R001的第3个Build的首个转测试版本，不发给客户。
F. V100R001C02B053   表示V100R001的第5个Build为第2个客户版本，可用于试验局、ESS局、或ESP局。实际交付件为第5个Build的第3个改错版本。

对于小公司，其实，用Github和SVN都可以。互联网公司一般选用Github。硬件公司其实偏好于SVN。其实用任意一种工具都可以，但是如何运用好这些工具，与项目开发相结合，非常重要。


Git 、CVS、SVN比较

项目源代码的版本管理工具中，比较常用的主要有：CVS、SVN、Git 和 Mercurial  


Git与CVS 的区别

• 分支更快、更容易。
  
• 支持离线工作；本地提交可以稍后提交到服务器上。
  
• Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
  
• Git 中的每个工作树都包含一个具有完整项目历史的仓库。
  
• 没有哪一个 Git 仓库会天生比其他仓库更重要。
  
  

Git与SVN 的区别（此处不得不再次感慨一下Linus的牛逼。）
【Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！】

Git是分布式的，SVN不是

Git 把内容按元数据方式存储，而SVN是按文件

Git 分支和SVN的分支不同

首先：核心功能充分测试。
作为一个产品经理，应该是自上而下的去看待需求问题。从公司做这个产品或者这个功能要达到什么目的，解决哪方面的用户需求，要实现什么样的商业目的等方面着手。弄清楚我们这次到底是要干什么的。
我们本次发布版本需要解决的问题做测试之外，还需要对核心功能进行充分的测试。
例如某款手机，升级系统之后，竟然连短信都无法发送，只好恢复出产设置。这样的版本发布会让客户骂娘的。

其次：构思需求的完整解决方案，建立版本需求列表。
当你了解清楚需求背后的真实目的的时候，实现这个需求可能有很多种方法。有的需要开发进行实现，有的不需要开发进行实现，这里讲的是需要开发来实现的需求。
对于硬件工程师，需要在改版之前，收集本次改版的所有需求，生产的、客户的、研发内部的、维护的、修理的……

第三：根据公司情况量体裁衣，做好需求版本规划。
经过前2个步骤，可能你的需求表上密密麻麻的列出了几十上百，几百上千的功能点和要解决的问题。这个时候不要着急，根据团队的情况，公司的实力、公司给予的资源，来对产品的版本进行划分。也就是说1.0做什么、1.1做什么、1.2做什么，切忌不要想着一股老的全给做了。
有些PM看着竞品或是对手公司做了很多领先于自己功能，一下子就急了，恨不得下一个版本当中全部赶上。实际上这样做的结果反而适得其反，一个是弄的开发团队不堪重负，做出来的东西没质量，不稳定，bug一大堆；另一个是一上线之后用户骂声一片，打击整个团队的士气，影响公司对此项目前途的看法。
另外，就算是产品1.0如果功能较多也可以分成几个小版本进行开发，注意把握好开发进度以及节奏。
曾经看到过一个故事用在此处可能有一定的启发意义：这个故事讲的是有一个人连续吃了7个包子吃饱了，于是乎大家纷纷去研究这第7个包子到底如何神奇，用的什么材料什么秘方啊。而忽视了前面6个包子的重要性。反映到互联网产品当中，那就是任何伟大或者好的产品都是一点一点积累起来的，没有捷径可走。一定要重视好版本迭代的重要性，真正做到跟用户一起小步快跑。
一般而言，做产品版本规划应该是根据团队情况分配的工作量适中，一个版本解决1-3个需求即可，保证整个团队能够在一周之内迭代出一个版本。这样的好处就是一月下来，一年下来，整个团队效率处于良性运转状态，并且产品体检相比较一月或者一年前也有较大的改观，用户也能感受到产品在慢慢的成长，增加对产品的信任感。

第四：上线之后的版本勿随意修改
很多时候在某个版本上线之后，还是会出现一些问题以及用户的反馈。这个时候我建议不要在当前的版本中去修复这些问题（重大bug除外）。因为如果这样做了，肯定是会影响产品的迭代周期的。所以我建议把这些问题或者建议又放入需求列表中，下一个版本中再根据具体的情况决定改进哪些，其余的留着后面去改进，不要想着一次把所有的事情做完。


第五：不要在产品快上线的时候，临时加没有卵用的需求
我们之前一个物联网产品，我们在调整射频功率之后，需要CPU复位，然后才可以进行工作。然而，客户的领导要求，不复位也支持修改射频的功率。理由是：之前别的供应商可以的，你为什么不行。
虽然我们解释：这个需求没有什么卵用。但是还是被强上了。
临近上线，做需求变更，容易导致测试不完备。结果上线后，发现，有些BUG是由于这个需求变更导致的匆忙修改和测试，引起的。

第六：硬件产品没有版本回退的机会
有个同学在华为做网站，夜里面版本升级是他的噩梦。每次升级，都需要在用户最少的时间段，也就是夜里面1点到3点，都在公司的行军床上睡觉。
一旦升级失败，夜里面做版本回退，第二天夜里继续。

虽然这个很痛苦，但是如果是硬件产品，已经发货后，发现BUG，且用远程升级不能搞定的时候。你就跑现场吧。
记得，有个产品维护的时候，产品发货到山西所有的监狱之后，发现有个硬件BUG，无法用软件规避。只好项目组分工去现场进行硬件替换。
于是一个小伙子在山西各个监狱门口拍照留念。


所以我们硬件发布之前，都做大量的测试和试制。避免出现发布版本之后，不能正常工作的情况。

------------------------   广告   ------------------------