###技术参考:精益全平台产品构建

这个春节回家,和朋友们聊到最多的话题有这么几个,互联网金融的余额包们、微信红包、创新硬件和智能家居、互联网思维的传统行业改造进程、规模化盈利的手游和移动电商的思路。观察讨论完一些有趣的现象和模式之后,大家总是摩拳擦掌,总有跃跃欲试的冲动。非常理解朋友们的心理现象,于是我只能一次次不厌其烦的答复全平台产品(iOS+android+web)大致的构建思路和成本,做下来几次之后,发现自己其实可以更完整地转化为文字,既能省事而且也是个技术总结提升的机会。

####精益是什么概念? 精益全平台产品,这里加了一个修饰词精益,这是很有必要的。因为有个误区,最明显的表现在很多其他行业的老板,有涉足移动互联网蛋糕的各种idea,但在八字尚无一撇之时,就满心自信地谈到如何用大数据驱动挖掘用户需求,这真就把我给吓懵了。当然,这也是远见者才能有的视野点。但是对于执行的技术人员,常念及“千里之行,始于足下”是最好不过的,因为一次性地拨高理想的技术实现预期,非常危险。循序渐进的技术实现方是上策,退可固守实力承受试错成本,进可灵活迭代积极反应,不至于一开始就陷入积重难返的境地。精益,则就是最小成本,最小可用原则。

好久没写技术总结了,一时竟不知该往细的还是往粗的方向写。个人向来尊崇“真传一句话而一语道明”的原则,不求堆砌故作。所以下面,仅以个人有限视野,针对精益技术构建做个“关键节点”摘要和其要点点名。

####1、精益的构建原则&方案思路

精益,就是最小成本做成最小可用产品。当然,对于已经蓄谋大志向且能烧钱的高富帅团队来说,或许精益策略未必合适。所以这种建议更多只是适用于草根创业者,或者兼职创业的上班族。精益,其中两个很关键的操作逻辑是“取材,一切从实际出发”和“善假于物”。

  • 摸透标准规范,选择标准规范:标准规范,这是“取材”过程中很重要的参考之一。从实际出发地取材,就是要度量好我们自己的实现水平,采用与之匹配的方案,这个过程不能自视过高地求超出自身实际水平,也不能懈怠菲薄凑合了事,这个判断虽然不是这里能够探究清的,但是采用“标准方案”实质已经帮助我们在取材的时省了不少力气。我们设计一种架构方案,有两个陷阱:

    • 其一,认不清“标准方案”所在。这个乍一看,好像不应该的吧。能够有4、5年经验的程序猿老家伙怎么能有这么糊涂的一面呢?但我就是不止一两次遇到这种情况,比如采用http协议设计API接口,有一位真是有经验的老程序猿犯了用http status code来作为自身API的业务逻辑status code。这是很不应该的,http设计初衷就已经定义好了http status code的用途,不能够不采用标准规范而用自身应用status code去覆盖传输层本身的那层http status code。客气地说,这或许是偶然性错漏,但是把一个错误的经验使用了4、5年,无法面对&分清各种杂乱开源方案的优缺就很不应该了。并且可以肯定地说,这种程序猿绝大时间都是在拼轮子,还没有功夫去对轮子大致原理有个一探究竟的过程。摸清标准规范,这其实也并不需要多大精力,只需要有心花个空闲时间经常浏览一下,各种经典技术的“设计说明书&使用建议”便可。这其实就是个,阅读说明书的过程。但是很有趣的现象是100个人中能够浏览说明书再使用的人应该不到5个人吧。so……阅读说明书不仅仅是个好习惯,还是种很有力的生产力量。

    • 其二,未作足论证,就无视标准规范,而只为了满足程序猿自己的狂妄心态。迄今为止,我就被一个GS程序吓尿了,比如对“数据交换格式”,他“面红耳赤”地推崇二进制方案的速度,却不加思考什么才是与我们匹配的标准规范和选择。一个整天把c++、服务器技术挂嘴边的人,很难相信他的行为是不是只是为了技术才技术。无视标准规范,重新定义一门更优选择的标准一般只发生在巨头内部或者高校研究队伍中,因为有充裕的研究资源。而作为灵活创业者,即便我曾遇到的最具有聪明气质的剑桥硕士生创业者也未曾为了技术而技术地选择方案。

  • 选择新型创新基础设施:技术的进步,遗憾的是有一些扎实的基础功我们年轻一代没能来得及打牢,令人振奋的是不断冒出一些颇具魅力的更便携的解决方案。而这就是技术构建中可用到的“创新性基础设施”。善假于物,这得益于能敏感地捕捉新型基础设施,所以,保持空杯学习心态跟踪最新技术趋势是很有必要的。以下就以罗列一些经典的“创新基础设施”来表达这种精益善假于物的思路。

 	* 云平台部署:使用云平台,最大的好处就是极大的节省了服务器管理配置的功夫,即节省人力资源又可以对服务器资源进行按需付费。这类服务诸如:阿里云、腾讯云、AWS、新浪云。 
	* 后端即服务:这类服务最大特点就是“可以像操作本地数据一样,便携存取云端数据”。对于纯App性产品,资源有限情况下。使用这类服务是最好的选择了。比如有parsekinveyStackMob。这个领域parse应该算做的最出色的,facebook就做价8500万美元把parse给收编了。
	* 云端开发环境:在线的开发环境,如果厌倦传统笨重的开发环境,那么选择这种轻盈的开发环境,把主要精力聚焦到业务核心代码上绝对是个好方法。最出色的是koding,而cloud 9 IDEeXo Cloud IDE也是不错的选择。	* 为项目管理的服务:备受推崇的当属37signalbasecamp,但更适合国内使用习惯的有tower.imteambition。选择一款与老板管理理念相对位的项目协作服务是很关键的,这极大地节省了沟通的成本。
	* 为产品运营的服务:分析用户行为数据,调整恰当的产品思路是产品经理或老板最关心的事,所以能够精确捕获分析用户行为数据的服务就是必不可少的,这里有flurry、友盟、talkingdata。本节扩展阅读[^1]

####2、抓准主干业务逻辑==>服务器后端开发&部署

抓准主干业务逻辑,这抓准的水平就取决“产品架构师”的经验和功力了,当然还会涉及到对产品使用环境业务的理解,老板的态度风格的正反影响等等相关因素。但其实也就是考验架构师对噪音的过滤处理水平。分析明白了产品的业务逻辑之后,接下来就是数据建模过程,以下则就是其中两个核心要点。

  • 数据库设计(数据模型):核心数据obj数量限制在5个以下,辅助数据obj在3个以下,数据联动关系线在3个以下。这几个数据基准没有科学地统计过程,只是个人的感性经验判断,对于实际的需求,应该是按照技术团队所能够承受的实际复杂度进行合理降低。一旦感觉系统设计变复杂了,那就说明主干业务逻辑被杂乱产品方向感给弄脏了,应该立即做出调整地措施。

  • API设计只围绕主干业务逻辑:主干业务逻辑收到噪音,最可怕地发生情况是产品经理(老板)对产品的方向和定位的功力较薄弱,导致产品的迭代方向总是背道而驰最初的方向,主干业务逻辑同样已经发生改变,这种技术调整中,就很容易陷入积重难返的泥淖。所以这点实质也跟上一点类似,先要保证产品的需求模型不发生本质变动,然后回到在API设计层面遵循围绕主干业务逻辑的原则

####3、有章法的API结构设计==>项目管理&沟通协作

  • 总结一份通用API设计精要list:阅读经典的API设计规范,进而整理一份自己的API设计精要规则。下面就列两本书,但是真正有用的东西还是,得学习吸收完后,总结一份简单易行的个人API设计规则。原因之一,普通商用级别技术团队里,请相信1000个人中没有10个人能够100%的严格遵循官方设计建议。原因之二,捷径的习惯总应该被正视的,同时最灵活地实现方式这也符合我们本文“精益”的解法

  • 寻找一种受用的api管理方式:技术团队在开发过程中,沟通最费劲、费时的就是业务逻辑的API设计和使用。感性统计,至少60%的绕脑技术沟通发生在API接口讨论环节。 很多技术团队首先是没有建立有效的API文档,然后就算是建立了文本文档,后来接手的人对于文本文档的接受程度并不高。而寻找一种受用的API管理方式就是我一直在思考的。除了分析了Apigee、Mashery这类成熟服务,还有swagger这类开源服务,但一直未找到能让我满意的一种API管理方式。关于我对这提法的思考,移步见这里寻找优雅的API管理方式,apiBox?。等我编码完毕,希望我的apiBox的能带来这种受用的方式。

####4、App功能明了、设计到点==>iOS、Android开发

  • 功能明了:萌生一个idea,最可贵的是不断分支出很多令人兴奋的可能性,可怕的也是这导致了产品功能已经拖累了产品生命的开始。对于App而言,更忌讳功能的数量。所以,功能明了会非常难得和珍贵。因此建议,主交互线路的功能做结实&明了。如果避免不了功能的多样性,建议功能树采用“简主干,富枝干”策略:这样设计的目的是,最大程度降低噪音,让高价值用户高频率沉浸在有价值的core loop中,同时提供潜在可探索的空间。
  • 设计到点:初创产品,保持产品欲望地克制是很有必要的。一开始,坚决不要奢求酷炫的交互效果,踏踏实实把最核心最小可用功能做扎实了,就已经是非常完美的一步了。另外,盲目奢求酷炫效果,部分有限主次,最好把核心功能做坏了,极有可能是会得不偿失的。当然,设计定位的产品则另当别论。

####5、节制的品味&形象&价值==>形象主页&web前端 这点貌似偏离了技术参考的范畴。但,这同样是精益产品执行策略重要的一个节点。这类问题既属于产品拥有者思考范畴的,也是见仁见智的问题,所以在这里不以技术式的遵循规则做参考建议。抓提法,后留白……

  • 善于把握情感地,点明产品的品味和价值

  • 发掘一种优雅方式,描绘的产品形象容貌

一图一体系update...

一图一架构,一图一知识体系。 Continue reading

website【2045区块链导航】
Published on March 19, 2018
DevOps在CI/CD上的工具链
Published on December 01, 2017