第五十九章 大卫捡起了石头(1/2)

前往南太平洋的舰队还有两周才会出发，除了搜救以外，这也是一次舰艇的远洋演练加上无人机的大练兵，当然由于水下搜索的设备还是有些欠缺，所以这次搜索的目标区域还是以海面和浅水为主。

116所的祥龙全状态试飞也在紧锣密鼓的进行，从目前试飞的进度来看，承担远洋接力通讯的任务还是没有问题的，唯一需要担心的，可能是复杂海况和天气情况下在舰艇上的降落了。

当然，为了稳妥起见，116所也带够了配件和维护人员，大不了摔坏了立刻修呗。

王一男也正好把自己的主要精力都放在《来嗨》上，除了隔三差五去帝都大学讲讲课，在雕刻时光跟周慧待在一起，放松一下心情以外，他基本上都呆在关村科技园的梦想科技大厦，跟大卫小组一起雕琢第一个版本的客户端app。

服务器开发团队已经使用r德尔系统的帮助开发了一整套完整的基础信息传输设施，ru的语法进行一定的简化加上哥德尔系统的自动推断和纠错机制，很好的解决了不仅仅是写程序，而且是正确的写程序的问题。

对于开发一个庞大的系统来说，最开始做的事情是什么，王一男看过一本经典的著作，叫做《技术内幕》，书写的怎么样王一男差不多已经忘了，但是里面有一些之父dave访谈性的片段文字，上面介绍了的前世今生，王一男至今记得清清楚楚，dave对于大系统，复杂系统开发的一些经典论点，字字珠玑啊。

要知道，可是整个微软历史上所开发最成功的一个系统了。

要开发任何一个系统，要做的第一件事情就是确定需求，这没什么好说的，最差的项目主管都知道这个，要是你手下的项目主管连需求分析都不懂，赶紧把他开了吧。

需求分析之后，下一步是什么呢？如果系统比较简单，而且开发人员很有经验，那么解决了做什么的问题之后，可以立刻进入怎么做的环节，也就是说，可以开始系统设计，甚至直接开始编码。

但对于涉及到较大规模团队的复杂系统来说，就不能这么干了，dave童鞋的回忆里面，讲述了他组建开发团队以及启动项目时候的真知灼见。

那就是，要为整个项目选择一致的，明确的策略。

策略是什么呢，策略就是评价的标准，优先级的选择，在碰到问题时候判断优劣的准则。

比如说这样的系统，整个生命周期可能会持续十年、二十年甚至更长时间，那么可扩展性就为成为设计的核心策略。

这样面临选择的时候，如果a方案性能更好，但是扩展性差，b方案性能略差但是扩展性好，那么根据一致的核心策略，整个团队就会没有争议的选择方案b。

而对于王一男他们开发的这个大型信息传输基础结构来说，可靠性是核心策略，这就要求在设计的时候选择容错性最好，对网络环境依赖最小的方案。

有了一致的策略，团队在选择的时候才能有参考的依据，而不是简单的拍脑袋或者根据主管的喜好，要知道，技术方案的分歧，往往是造成研发团队分裂的最主要因素。

跟服务端开发团队讨论完了需求，设计策略，以及根据设计策略选择的主要技术方案之后，王一男对他们在哥德尔系统帮助下，实现这个系统的能力和实现质量还是充满信心的。

接下来就是客户端了，一张白纸好作画，王一男面临的第一个问题，是选择跨平台的高层解决方案，比如说ive，一种语言或者说一套代码，可以在多个平台运行。

还是选择每个平台自己的主力开发语言，java，objectc，或者最新的kotlin或者。

两种方案各有利弊，跨平台的方案，代码量小，需要维护的东西也少，但是性能肯定比平台原生方案要差，而且碰到一些底层的调用，还得求助于原生代码。

而原生方案其他都好，就是一个问题，同样的功能每个平台都要写一遍。

经过长时间的权衡和讨论，最后决定安卓直接上kotlin，io，反正这也是版本0.1，没有任何遗留代码的包袱。

解决了开发语言和随之而来的开发工具的问题，接下来就是浩如烟海的具体功能了。

当然对于推向市场的第一个版本吗，功能可以简化简化再简化，但是最基础的一对一视频、一对多视频以及多对多视频是必须支持的。

在此之前，有一个看起来简单，但是直接影响成败的问题需要解决。

那就是用户的注册问题，在移动互联网来临之间的互联网时代，这是一个非常困难的问题，我举个简单的例子大家就明白了，鹅厂的一次点击明码标价，大概从几毛钱软妹币，到几块钱软妹币不等。

但是再好的内容，注册的广告做得再好，50次点击能够产生一次注册，那就是非常了不起的成就了。

因为注册至少需要用户填写用户名，密码和确认密码三个栏目，而且用户名这个栏目跟已有用户名冲突的可能性是100，需要用户反复尝试输入。

当然还有更多作死的产品经理，要求用户在注册的时候输入昵称啊、性别啊、年龄啊、爱好啊等等等等，这样完完整整完成一次注册的用户比例就更低了。

于是鹅厂当年最早推广企鹅的时候，采用了唯一企鹅号码的办法，自己挑选组合加上随机生成的办法，这种方法最大的好处是避免了用户名的重复，但是增加了用户的记忆成