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 包含了 A一、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 接口，新的走新接口。

移动端会场圆桌

花絮

如今来看看其余的一些照片放松就行了（前面知识洗脑那么久

肉山大魔王

谁说的没有妹子？

主会场盛况

前端会场提问

累了来把推拿

最后来一张当天的晚宴

内容下载

1. 更多的现场照片请看 这里

2. 全部视频与文档请看 这里