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. 全部視頻與文檔請看 這裏