D-Day 2015 杭州站：SegmentFault 三周年的技术盛宴-阿里云开发者社区

SegmentFault D-Day 2015 杭州站暨三周年技术大会上周六顺利地进行了，全天四个会场、20 位嘉宾、各个技术方向深入探讨分享，从最新的技术趋势展望，到热门的技术议题深入探讨，再到众多嘉宾的技术经验与心得，这次杭州站 D-Day 就是一场我们三周年的技术盛宴。

由于全天是四个会场 20 位嘉宾的分享，内容非常多，所以这里只节选部分精彩的演讲和圆桌，分享给大家。

上午主会场

先重点说一下上午主会场的三位分享。

《SegmentFault 成长记》 by Joyqi

我们 CTO Joyqi 主讲公司的技术成长史，从最开始的 1.5 G 内存、40 G 硬盘的一台 Linode VPS，没有缓存没有 CDN、只有 7 张数据表，到现在各种安全服务都开始使用，网站构建开始全面化，讲了很多其中踩过的坑，有料的内容很多，具体评价请看用户 @rainy 的文章《D-Day 杭州一日行程记录》引用：

上午第一个 SegmentFault CTO 祁宁的后端开场演讲还是有很多干货的，介绍 SegmentFault 从一开始一个人一台 VPS 逐渐迁移到云服务上，分享了创业过程中遇到的一些技术问题以及解决方案等，非常适合刚刚开始创业或者正打算创业的小伙伴参考借鉴。而且更重要的是他用 SegmentFault 作为活生生的例子告诉我们，如果有创业的想法或者很棒的 idea，其实创业的成本并没有想象中那么高，只要开始动手做，把遇到的问题当做是历练自己的考验，总能完成从 0 到 1 的飞跃。

演讲：《SegmentFault 成长记》文档 | 视频

《移动 App 技术架构的“四段论”》 by Gaosboy

任何一个 App 都会经历从小到大的过程，经历几个必须经历的阶段，区别在于有些 App 迅速长大，而有些则还没来得及长大就转型，或者干脆停止维护了。不同阶段关注的重点不同，所以对上述几个要素的取舍也就会有所区别。而 Gaoboy 就这些，将自己的经验心得进行了分享，开发效率、稳定性、开发成本、精细度、产品功能一个不可或缺，而一个技术团队如何在选择技术方案，制定技术架构的过程中，在合适的时间做合适的取舍，发挥正面作用也是非常重要的。

演讲：《移动 App 技术架构的“四段论”》文档 | 视频

《如何打造优秀的技术产品》 by 玉伯

什么是技术产品
解决什么问题
如何找到合适的人
如何形成小团队去把产品做出来
如何把技术产品养大
技术产品的归宿是什么
如何用技术产品去创业

等等，玉伯就这些问题认真讲解了一堂课，不仅仅止步于技术的东西。这些是深度的思考结果发散，非常有启发性。

演讲：《如何打造优秀的技术产品》文档 | 视频

下午各会场

上午三位嘉宾分别是后端、移动端、前端的演讲，之后下午便分散到各个分会场，下面节选部分各分会场嘉宾的分享。

《天猫 React Native 实践与探索》 by 朱柯军

天猫前端工程师朱柯军（跑猪）在移动端会场主讲《天猫 React Native 实践与探索》。他将原本 Web 版本《猜你喜欢》业务使用 React Native 进行了重写，随后又开发了 iOS Native 版本，所以这次的分享就主要是他在 React Native 方面的实践分享，从 Memory 占用、CPU 消耗、Load 时间、使用体验等多个维度，实验对比了 Native、Web、React Native 三个版本之间的差异。由他的分享可以看出，React Native 的性能和稳定性是介于 Native 与 Web App 之间而又兼具了 Web 开发的优势，感兴趣的可以看下他的分享，自己动手试一试。

演讲：《天猫 React Native 实践与探索》文档 | 视频 | 引用鬼道文档

《Container & ContainerOps》 by 马全一

wharf 作者马全一在后端会场主讲《Container & ContainerOps》。从容器技术的发展开始，讲到了目前容器的特性、相关技术（热迁移 / LXC）、Docker 和 Hyper 的出现与发展，直到现在的 ContainerOps。下面是他的演讲提要：

Container 技术
Docker 和 Rocket
Application Container Spec
ContainerOps
ContainerOps Open Source Platform: Wharf

他的演讲稿很详细，可以直接阅读~

演讲：《Container & ContainerOps》文档 | 视频

《后 Angular 时代二三事》 by 徐飞

前端界大V 徐飞在前端会场主讲《后 Angular 时代二三事》，主要是关于 Angular 2.0 所带来的一些思考，由 ES6 和 TypeScript 到组件化与路由，再到指令与 Web Components，MVVM、React……讲的内容很多，无论有没有到现场，他的演讲稿和文章都值得一看。正如他文中所说：

抛出这样的问题来，是为了让大家察觉，在很多不为人知的地方，存在很值得思考的东西。一些新的 Web 标准是为了解决 We 系统的大型化，应用化，但仅仅以这些标准本身而言，还是存在一定的不足，需要更深刻的改变。

演讲：《后 Angular 时代二三事》文档 | 视频 | 文字版

圆桌精彩

由于时间限制，只有前端和移动端进行了圆桌讨论，这部分也只节选一些看看。（完整版请见文章末尾的共享链接）

前端会场

当下说的传统做法归根到模板引擎，React 是很好的解决方案，但问题是前后端结合点呢？前端后端比如说 React 怎么去结合，我刚才问我司马，他说了同一台服务器，同一台物理机或者是虚拟机上，通过 HTTP、JS 做一些简单的数据传输，当然这是可以在一定场景下解决一定的问题，但我觉得这可能不是一个绝对或者说非常优化的解决方案，其实我的关注点最核心的就是数据分析，让我去理解是一个痛，第二个就是 Native 怎么一起携手。

何翊宇：第一个问题是关于数据传输格式。其实对于我来说，我做这件事情的时候，看到前后端协作的模式上，前后端通信协议越简单越好，简单到只有数据是最好的，因为完全不同的工种要通过 VC 应用，就是一种业务模式。我们希望数据成面上简单的数据沟通，把接口部分做到最简单。

第二个是怎么做到JS相关的东西更好的协作，我们这地的做法是尽可能人后端不去写模板的东西，让后端专注于产出数据，后端负责的就是继承数据，把这件事情简化到前端和后端的模板，数据模板变成HTM的东西，后端不关心，后端只关心数据产出，数据产出是非稳定，尽量中间的东西，如果前后端都要做的，那前后端都做，因为这样可以最大程度的降低成本。

与会者：我大概听懂你的意思，就是界限在哪里，一个是吐数据，一个是建模板。

何翊宇：大家知道阿里内部有一个 HCF 的东西，其实也是类似这样的东西。我刚开始 Node 的时候也是在写 HCF 的 Node 的端，就是把 Java 加起来的东西，其实他用的地方跟荒，任何纯 JS 的东西要和 JAVA 应用，但具体到某个问题上，要把模块接过去的层面上，我们是不会让它投入 RTC 的东西去做，而是更简化的 JS，因为都有自己的应用场景。

与会者：以前我在学校里的时候，我一直认为前后端分析，认为前端就是服务器，后端就是数据，后来工作之后前后端有点不对，因为一个页面出来以后，最近我也在理解，前端是不是接入服务器的 web 层了？

何翊宇：这个前后端的分法在每个团队有自己的想法，但是有一点的是可以确定的，view 肯定是属于前端，我个人更希望是一个 web 工程师的职位，除了大前端的概念，就是把一些 web 这一层的相关服务加上前端的脚本，打包在一起做大的浅淡的东西，但是这块涉及的内容比较大，对个人要求会比较高，所以现在的情况是前端被划分在浏览器的东西，大部分是前端负责 view，加上 Native 都是属于前端工作里面。

这个问题是问徐飞和贝勒。关于 Angular 和 React，因为现有的案例是我们选 Angular，因为一些原因我们选择 React，再往后看，可能 React 以后自己会像 Angular 1.0 和 Angular 2.0，甚至后面会出现更多抽象层级更高的，语法特性更好的语言，但我们写业务逻辑的时候，它在那里，我在想会不会有中间一个语言，所以我问两位，中间的抽象层，事实上我们不关心底下是 Angular 还是 React。因为写业务逻辑的人，业务的人总是觉得做架构的人，今天这个明天那个，其实就是安安静静写代码，应用工程师关心的是那个东西，可能 React 是一个方向，但又缺少了东西，这两个东西是不是可以找到一个东西，以现在的技术方向有没有可能？

徐飞：我觉得这种东西基本上不可能。相当于一个人喜欢吃肉，一个人喜欢吃青菜，你想一个既是肉又是青菜的东西让他们两个都喜欢吃，难度很大。很多时候决定的人绝对不是写代码的人，以他们的口味为准，我觉得两个都可以。

李振强：其实很多的应用，像前端和后端发展，他们 mode 层或者应用层，我们也会做一些服务化，其实服务化的代码都是用 JAVA 写的，view 都可以用，最开始的时候都可以用 PHP 写的，view 层也是 PHP，服务层的话是用 JAVA 写，现在服务调一些 JAVA 的服务，目前还没有发展到一定要分得那么那么细，所以现在选择React，可以做得方式就是说去把一些业务逻辑渐渐从 view 分离出来，写 view 可以写 model 层，model 换了一些其他的方向，其实是可以附庸的。

玉伯：补充一下，可能还是有可能的，可能是十年以后。我觉得这种可能真正要达到协议层。

与会者：标准或协议吗？

玉伯：标准都不靠谱。协议中有 HTTP 协议，有网络协议，model 层和 view 层，可以出现徐飞协议或者说其他的协议，就是说这种协议被大规模接纳采用就实现了，但是太遥远了。

HAX：我觉得其实不那么遥远，我觉得现在 Angular 或者 JS 非常火，我一直讲新技术，我觉得到目前为止，不管是 React 和 Angular 都不能让我信服，就是这个东西就是让我们接受，从历史看，这个历史很短，Angular 才出现多少时候，那时候觉得这个很牛，又出现了 React，说不定一两年之内会有人出现颠覆 React，也是有可能的。

但前面提到的至少有两点，第一个是不管是 React 还是 Angular 都是在 model 层，所以即使现在 React 和 Angular 实现很多东西不一样，就算你不用 React 或者是 Angular，还有很多的实现方法。就算用 React，React 自己也有很多种不同的，但不管怎么样，这一块矛盾层的话，决定矛盾层这一块，业务逻辑怎么样的，不是选用 Angular 或者是 React，还有很多因素决定你怎么写，如果有确定的方法能够很好的写出来，我相信在 Angular 或者 React 某种框架里切换都不是很难的事情。

前面好像谁提到了，如果有人分层好的话，你的迁移肯定是 OK。第二个点，想补充的是其实如果我们抛开后面的 model 层，往前看的话，虽然 React 和 Angular 很多地方不一样，但本质上有很多类似的地方，比如说整个组建的框架，如果再往下看的话，里面都有一个数据绑定的问题。这个地方，我觉得也许是在未来几年会发生变化的，现在 web content 还欠缺很多，比如说欠缺数据绑定，但不知道往什么方向发展，也许数据绑定未来会标准化，或者有一种大家多接受的忙市，也许这块就变得一致了。

我想问一下 Angular 的问题，如果是用两个发包块的话，双向数据绑定。如果有时候写模块的话，如果要开发一个指令的话，如果想引用这个模块，不能让每个都引用，怎么用最简单的方法，或者说 Angular 会有什么解决方案，让性能上得到优化？

徐飞：这个问题可以分开看，要解决的依赖关系。我觉得这个依赖是因为在1里面，模块机制设计不合理，如果要做的话，只能在最外层，如果是在 2 里面，这个问题的解决对每个模块是自己对自己的依赖，而且依赖并没有在再上一级的关系，相当于大家都是平级，每个人都可以，这时候应该就不存在这个问题了。其实我本来想找个机会彻底把这个讲一遍，这个性能有一些问题，特别是有一个很大的数字，有一千的长度或者一万，我只改了其中的一个，为了要看这个倏地有没有变，第一次先找变的东西，在 2 里面会有一些办法，用存取系或者是观察的方式去解决，但并不完全解决这个问题，有些变量在 model 外面，把变量带出去了，我觉得这是非常复杂的东西，我希望一段时间之后写一个完整的交流。

与会者：因为有些问题困扰我们，因为 Angular 本身自带，社区里面感觉做项目的时候，感觉在路由上有什么样的取舍呢？

徐飞：我刚才也提到了，有三种方式，原来自带的 NJNode，除非路由真的非常简单。还有 ruiluter，新的路由机制也是其他共享了一个路由机制，这个不一样，一个组建是 A 包含了 A1、A2，这个路由本身是签到关系，但如果有一天 A1 移到 A2 了，这时候路由是不是要准备，如果路由开始放在组件内部，可以自己追加到里面来，就是希望通过这样的方式让组件的使用更加灵活。

前端会场圆桌

移动端会场

一个是 Hybrid 方案，还有一个是 React 方案，还有一个是关于自动化测试。我们在这样一个开发方式转型的阶段，从纯 Native 开发到混合开发，在混合开发之后发布的频率以及开发的速度都提升很多，在这种条件或者在这种前提下，我们对质量保证应该如何做？因为发布成本会变得很低，这里的质量如何保证？

史江浩：其实 Hybrid 模式在 PC 端里不是刚刚起步的，所以测试可以沿用PC端以前的经验，但是现在我们的实践和以往没有太多的区别，不知道天猫有没有不一样的？

朱柯军：React Native 刚刚才做一个业务。针对 React Native 来讲，最后是到 OC，所以这个测试需要全面充分，最后还是要执行 OC，如果很多没有控制的话，会造成信息泄露，现在还没有做得很充分，以后我们会在这个方面会做一些测试的 case，并出来一些全面的方案。

倪华杰：因为我本身是做 SDK 开发，可以简单地聊下来。我刚才提到的 Android 的 SDK 中只有一个是支持自动化测试，其他都没有测试支持。所以，像 Hybrid 的 APP 我见得比较多，我现在见得比较多的是 webview，这个大部分是它做。现在成熟的东西不是特别多，当然，前面说用 web 的方式去做，我之前在 web 做自动测试的时候就是用 lua 的脚本做测试，但是在 Android 上没有找到。

主持人：在整个无线端的测试方面是比较初级阶段，整套体系完整地建立起来可能需要一点时间，大家有没有什么问题？或者比较想讨论的话题？

如果大家没有的话，我刚才和两位讨论过一些问题，我们在移动端设计 API 应用方案，即我的端和 API 交互有各种各样的东西，因为我的端发布到用户手上以后，它的控制权限不在我这里，那么开口开放出去之后会涉及到各种各样的问题，比如数据的问题、版本的问题，甚至权限的问题。这些问题想听一下各位在平时的应用中有没有可以分享的经验？

史江浩：我可以这样理解，现在的问题是如何解决一个 APP，离开开发者的手里，达到手里已经交付了，如何解决用户产生的一系列的问题，可以这样理解吗？

主持人：可以。

史江浩：这个问题是 case by case。比如我们离开用户的时候，有时候需要记录用户的行为，帮助我们重现用户的 bug，比如打一些日志，让我们在用户崩溃的时候，通过日志得知用户做了什么样的操作。还有用户崩溃日志的收集和解析，以及崩溃日志转化为程序员可读的日志。这些是可以做的点。

另外一个比较关键的是，充分利用用户反馈的功能，当用户把页面打开的时候，可以反馈给我们他遇到的问题，然后拿到他的联系方式去联系他。

倪华杰：我们做 SDK 开发遇到这个问题很麻烦。这相当于是二到手了，我们比你们更着急，比如我们做一个 case 你们又不升级，然后一直问我们为什么线上有 bug，我们很痛苦，听到这个以后，我马上记到我的备忘录。

刚才说到 API 版本设计和变更的事情，这个我们是有的，早年的时候，我们有一个 API 的设计问题，还有一个问题是代码缺失，要进入老版本的数据，这时候可能数据格式都变了，这个没有办法，如果你们细心的话，可以发现以前的 API 是 1.0 版本，现在是 1.1 版本，在云代码只能改了，这里沿用了早年的服务器的 API 设计，老版本就走老的 API 接口，新的走新接口。