2015.7.4 阿里移动技术峰会 分享

孤街醉人 提交于 2020-03-25 08:33:50

3 月,跳不动了?>>>

    

       第一次参加移动互联网的峰会,起初感觉是一个华丽丽的产品宣讲会,稍微认真听一下,还是能够了解到阿里在项目管理、产品、开发、安全和工作方式等等方面的一些相对成熟的做法,值得借鉴。会议的嘉宾包括:uc浏览器应用业务部高级经理林蓬蓬,分享uc垂直导航业务的快速开发实践之路;阿里移动高级技术专家铁花,分享如何一周产出一个高质量移动app;阿里技术保障高级专家青裂,分享阿里巴巴双十一大促保障体系演进;uc浏览器uc内核组软件架构师陈炳辉,分享android native devlelopment;阿里移动安全高级专家典扬,分享移动互联网时代的安全挑战;阿里技术保障研究院赵海平,facebook 文化分享。

       在夹杂着一点乐队表演和舞蹈表演的情况下,会议持续了一整天,朝九晚五的听完了整个会议。当然中间会有人在打瞌睡,毕竟有些人能做但不一定能说。整个会议个人比较有感触的是赵海平分享的facebook文化,陈炳辉分享的native development和林蓬蓬的快速开发实践之路。那个铁花其实也讲的挺好,语言幽默风趣,但很多人如他所说,光听他扯淡,没有听到重点了,而且绕来绕去都带着挖人的中心思想,想想他也是蛮拼的。

        快速开发在互联网公司是从实践中总结出来能适应互联网开发的一种模式,林的分享中,快速开发的主要思路是:启动快--》评审快--》迭代快--》发布快---》反馈快。其中启动快这个在大公司中是一个项目相当重要的环节,他们的做法是采用,研测合并+授权下放,自决策团队的做法,即去除了很多流程,让下级小组自行决定项目的启动,人员的调配,达到每个小组都是一个小型创业团队的状态,最后让成果去说明一切。个人认为,这不仅体现了团队成员的重要性和自主性,而且能发挥成员以自发心态对待工作的积极性,是一个值得借鉴的方式。评审快,体现在评审客观(数据+目的+价值+指标),20mini讲不清楚的需求pass(要么产品没想清楚,要么存在分歧,要么很复杂),多用wiki反馈变化,少用邮件。这点也是在实际工作中很有意义的做法,易跟踪需求的变化过程,及时让每个人清楚最新的需求,上周跟产品开完会时,已推荐了产品使用wiki的方式进行沟通,如果能在wiki上通过评论的方式体现整个讨论的过程,那么就跟下面要说的facebook的文化有点像了。在迭代快的环节中,uc使用 scrat 模块化开发框架 提高效率,能做到:请求合并,就近维护,同步加载,预加载,延迟加载等等方式,我感觉最主要的是他模块化了,ui 组件化,js 模块化这种抽象是快速迭代的基础。另外一个优点是请求合并了,因为它的ui 资源存放有一定的规则(模块化的基础上),通过其中一个文件的请求连接,就能知道其他相关资源的连接,然后打包下载到本地缓存,从而减少了其他相关资源的请求次数,提高了访问速度,因为服务器建立连接和释放连接是比较耗时的。通过 NAPI 框架完成整个版本的迭代,框架内容很多,有些听不懂。发布快,由运营组提供的uae 应用云来提高发布的速度,运营接触的少,不是很了解,就这样吧。反馈快,有自己的数据处理及报表中心,能及时展示各种报表快速反馈。听的也是有点累,忘了大部分内容,呵呵。关于快速开发,他还分享了很多原则,沟通环节少,研测一体,研发懂数据这几个原则能提高开发速度听的懂,其他有点模糊。关于研测一体,他提出让研发写测试用例,测试来检验,测试写测试用例,研发检验的做法也是值得借鉴的。最后的总结,“快”不是一个点上的提升,而是整个链条上的提升。反思一下,我认为不要为了快速开发而去追求快速开发,而是应该在各个环节里面寻找最合适的做法提高效率,让快速开发成为自然而然的事情。

        铁花分享的app真的是完全在听他扯淡了,一周开发一个高质量的app,还要跟微信pk,呵呵。就听到他们能够复用连接,提升速率,解决了弱网问题,app耗电耗流量问题,实现了私有的协议。完了。

       双十一的技术负责人青烈,在会上就说了2009-2011的一些数据,每秒处理8万笔订单,每个订单250次左右的业务处理,确实很让人惊讶。更让我们惊讶的时,双十一我们的消费在他看来完全是冲动消费,并且是按照他们精心策划好的方式进行消费,说到这里,不知道你们有没有一种被设计的感觉。现在知道为什么双十一要提前加入购物车了,因为他们前端是比较薄弱的,他们要把用户引导到他们最坚固的领域,现在知道为什么有余额宝的出现了,因为阿里能接受这么巨大的访问量,而银行不行,要通过余额宝缓解一下压力。但是从另外一个角度来看,他们确实找到了用户更容易接受的方式,让客户开开心心的进行“剁手”,还要满心欢喜的等待下个双十一。个人感觉比较有用的是,让开发忘掉技术的本身,回归业务的丰富性,尽量不要因为技术去限制产品的发展,让开发人员懂的数据,听到用户的感受,从用户视角进行智能精准的推荐。

       浏览器内核组炳辉,分享android开发环境搭建到内核问题处理和优化的一个简单的过程,中间提到很多工具,有系统提供的工具,平台提供的工具,开源的工具,还有自己实现的工具。才知道,原来 uc 也用 mantis,简单的工具大家都喜欢,哈哈。里面大部分是android开发的东西,不太懂。只知道,用一些简单的脚本开发小工具来提升工作效率这种方式值得我们学习。完了。

       互联网安全挑战典扬,总的来说,安全问题可以分为三大类:破解,漏洞,木马。app的通常防护手段是代码混淆和加壳,安全系数较高的是通过native develop 修改代码的执行指令,让代码基本没有可读性,达到更高一层的防护。介绍了一下他们的聚安全平台,也是听不太懂在说什么。面对代码安全可以有几种对策:代码扫描审计,人工审计,安全意识培训。

        压轴出场的前facebook高p赵海平,是本次会议的焦点。他分享了facebook的上班文化,最吸引大家的目光的是,work from home,可以在家工作。为什么?他从同步沟通,异步沟通,通知这三种交流方式作为基础,引导大家的思维,让大家认同异步沟通是一种高效的工作方式,从而认为在家工作也是没问题的,而且,可能会更容易让大家接受。同步的例子是电话,异步的例子是类似朋友圈讨论组的方式,通知的例子是邮件。他认为,硬盘式的工作能记录整个工作的过程,形成知识的沉淀,而且让你的绩效有据可查。并推荐大家使用开源协同工作的工具 phabricator 来完成项目管理、代码审查和缺陷管理的工作。我认为这个最好的一点是平滑的衔接了各个系统,因为很多公司项目管理/代码审查跟缺陷管理都是分别有各自的系统,没有在系统间建立连接,达到真正的协同,统一管理。例如你的哪些代码是解决那些bug不能在bug系统中体现出来。而他们就是解决了这些系统间的衔接问题,达到了一个很好的沟通、管理的效果。目前,个人感觉在wiki上建立需求文档,把需求讨论的过程在wiki的评论上体现出来,这样每个人看wiki就能知道需求的讨论过程和最后的决定,感觉也是很直观的。

    终于告一段落,还有很多小的实例没法一一列出,我听到的主要内容差不多都在这里了,包括自己的一点点理解,欢迎吐槽。

     完。

      

    

    

       

    

    

    

       

       

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!