2015.7.4 阿里移動技術峯會 分享

    

       第一次參加移動互聯網的峯會，起初感受是一個華麗麗的產品宣講會，稍微認真聽一下，仍是可以瞭解到阿里在項目管理、產品、開發、安全和工做方式等等方面的一些相對成熟的作法，值得借鑑。會議的嘉賓包括：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就能知道需求的討論過程和最後的決定，感受也是很直觀的。

    終於告一段落，還有不少小的實例無法一一列出，我聽到的主要內容差很少都在這裏了，包括本身的一點點理解，歡迎吐槽。

     完。