中國第一代程序員潘愛民的 30 年程序人生

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!


搞技術是一件極其幸運的事情,不僅是我們迎來了最好的時代,亦在於我們的祖師爺大多還都健在甚至健談,比如 Linux 之父 Linus Torvalds、Python 之父 Guido van Rossum,而中國第一代程序員們也都還在折騰,首推 UCDOS 發明人鮑嶽橋、超級解霸創始人梁肇新,以及今天我們的主人公 —— 國內知名操作系統專家、指令集創始人兼 CEO 潘愛民博士。

潘愛民博士生於 70 年代,起於 BASIC 編程,師從漢字激光照排系統之父王選院士,從北大計算機研究所、微軟亞洲研究院到任職盛大創新院專家顧問,又先後任阿里 YunOS、阿里安全、飛豬、阿里業務平臺首席架構師,進入物聯網時代創立指令集深耕並親自主導物聯網操作系統研發,歷經中國互聯網行業從星火到移動、AI、大數據、IoT 等各種燎原,幾乎可以算作是中國互聯網發展的一大縮影。

浮生多變化,萬事有盈虛。當國內程序員們憂於「35 歲職業坎、45 歲屈服現實、55 歲就得隱退」之時,透過潘愛民博士的 30 年程序人生,我們不僅能夠看到一箇中國第一代程序員死磕技術,又深邃思考技術如何落地與產業融合,更能從他的身體力行中看到,後浪奔湧,老兵如何不息。

_1

潘愛民

我第一次寫程序人生是2000年,當時有很多編程實踐,剛剛開始有系統性的思考;第二次是2010年寫了我的成長故事(發表在《程序員》雜誌上),當時即將從微軟亞洲研究院畢業,準備進入國內工業界。到2020年,又10年過去了。回顧這10年,我一直在工業界努力,經歷了三家公司:盛大、阿里巴巴和杭州指令集,親歷了移動互聯網的發展,以及物聯網時代的興起。

在計算機技術飛速發展的年代,10年是一個很大的跨度,足以發生翻天覆地的變化。我有幸在正值壯年之際,又一次經歷了中國互聯網產業的蓬勃發展。本文記錄我在這10年中的職業經歷、技術感悟,以及從技術轉向業務、與產業融合的實踐與思考。

1 職業經歷

2010年夏天,我離開微軟亞洲研究院,踏上了南下到上海的旅程,加入盛大創新院。當時的感受是,在經歷過北京大學的教學科研以及微軟亞洲研究院的系統研究以後,非常渴望回到國內的企業或機構進行基礎軟件的研發。經過多方考察,我選擇了盛大創新院作爲職業生涯的下一站。

盛大創新院

對於程序員來說,盛大創新院是一個理想的創新機構,有老闆的大力支持,有大量互聯網人才,正趕上移動互聯網蓬勃發展的大好時機。有一批優秀的項目脫穎而出,涉及到語音、短視頻、雲計算、雲筆記、LBS、智能手機等很多領域,其中有不少項目在盛大創新院解散以後還在延續並且做成功了。

當時我帶領的方向是移動操作系統——VisionOS。爲什麼要做移動操作系統,以及如何做、技術路徑如何選擇,這是在立項階段反覆思考和推敲的問題。我至今認爲,那是發展自有移動操作系統的最佳時期,Android尚未佔據市場壟斷地位,並且Android手機的體驗和性能離iOS還有顯著差距,自研系統有機會快速趕上來。

如果把微軟亞洲研究院看作企業象牙塔的話,那麼在盛大創新院則感受到了國內工業界的創新活躍氛圍。在盛大做終端操作系統,遊戲作爲應用生態中的一個重要組成部分,是獨特的優勢。

當時手機遊戲尚處於早期摸索階段,但很多頁遊已經商業化運營了。VisionOS選擇支持Flash和HTML5(H5),作爲對於手機終端小遊戲的基礎平臺。儘管當時有Flash和H5誰是未來的爭論,作爲基礎系統平臺,面對大量存量的Flash內容,VisionOS必須做好支持;同時基於前幾年我對Web技術的研究,未來我更看好H5。因此VisionOS對於Flash的策略是兼容支持;對於Web則從系統底層打造形成一個應用平臺(Web Runtime)。

這是我第一次組建並帶領一個操作系統研發團隊,自己做架構師,從Linux操作系統到應用層技術棧,再到雲端服務,都涉及到了。

VisionOS的技術架構跟Windows比起來,簡化太多了,所以我在VisionOS的架構設計與技術選型上都能得心應手。得益於盛大創新院良好的技術創新氛圍以及相對優厚的待遇,我組建了一個非常優秀的團隊,有玩Linux的,有精通圖形引擎的,有精通軟件工程的,有精通多媒體編解碼的,也有擅長系統安全的,共十多個人,用一年多時間建立了一個性能優異的基於Linux/WebKit的移動操作系統。

我從一開始就沒考慮跟Android兼容,而是走自建生態的道路。VisionOS從立項到決定解散,差不多兩年時間,對我來說,就像一次創業經歷,做出了一個原型系統,但未能實現商業化。

_2

2010年潘愛民在盛大創新院

阿里巴巴

離開盛大創新院,我休息了兩個月,拿到了華爲和阿里巴巴的操作系統首席架構師的Offer,最終命運使然,2013年初,我來到杭州,加入了阿里雲OS。

當時阿里雲OS是阿里雲下屬的一個部門,所以,確切來說,我加入了阿里雲。杭州是我家鄉的省城,一向以風景優美著稱,當時還算不上互聯網技術人才聚集地,但我時有耳聞,很多前端工程師經常在杭州聚會,技術的氛圍正在濃厚起來。

我在阿里巴巴工作了將近六年,主要分三個階段:雲OS(後更名爲阿里YunOS)、集團安全部,以及飛豬和業務平臺部。在雲OS工作的兩年間,正趕上雲OS蓬勃發展的時期,從一個以Android BSP爲基礎的兼容Android應用的移動操作系統,演變爲一個自主移動操作系統。

作爲雲OS首席架構師,最大的挑戰是確定新的架構,並且推動各個開發組接受新的架構。我同時也帶領了核心系統模塊的研發組。基於盛大VisionOS的研發經驗和教訓,我在設計新架構以及核心模塊的技術選型方面,有足夠的把握讓新的雲OS符合未來發展。

兩年間,雲OS技術團隊已經非常強大了,聚集了國內大量的系統工程師。我一心想做成雲OS,然而,天時、地利、人和很難三者得兼,最終我還是放棄了繼續努力,轉到了阿里巴巴安全部。

當時正趕上阿里的電商業務全面從PC互聯網轉向移動互聯網,安全能力也勢必要跟着升級。我一方面支持阿里業務的移動安全,另一方面帶領一個架構師團隊來梳理和重構阿里巴巴的安全體系。經過兩年的安全領域實踐以後,我希望能到業務部門學習和鍛鍊,於是選擇了阿里飛豬。我認爲這是一個小而美的業務部門,既有平臺屬性,也有行業屬性。雖然飛豬的業務體量相對淘寶和天貓的總量小得多,但旅遊是一個發展中的行業,業務空間大,創新的機會也多。

最後趕上中臺戰略下的部門調整與合併,我來到了業務平臺部門。我突然發現,加入阿里巴巴時滿懷着做成一個移動操作系統的夢想,但現實中卻發展成爲了企業中的老白兔。結合自己最後兩年對於業務的認知,以及物聯網行業發展的判斷,也感受到杭州這塊互聯網熱土,最終我決定離開阿里巴巴,建立一家創業公司。

杭州指令集

在杭州,從阿里巴巴出來創業的前員工是一個廣泛的羣體,並且不乏成功者。我估計杭州一半以上的科技創業公司的合夥團隊中都有前阿里員工的身影。在這樣的羣體氛圍中,我選擇出來創業,也就絲毫不奇怪了。

我創立指令集有兩個初衷:

一、物聯網是後移動互聯網時代能看得到的一個大趨勢,而這個產業還處於零散發展的階段,除了一些嵌入式操作系統演變爲物聯網設備的操作系統以外,還缺乏基礎性的系統軟件,所以我認爲有機會做物聯網場景的系統軟件(解決一些共性的基礎功能需求)。

二、感受到了智慧園區/智慧樓宇的發展與變遷,以阿里巴巴西溪園區爲例,2013年啓用時就是一個普通的安裝了很多智能設備的園區,但經過幾年的發展,園區內的很多設施,越來越智能,包括門禁閘機、燈、空調、停車、電視屏等,這一切都源於背後有一套系統,將所有相關的設備連接到一起,並且與企業信息系統打通,從而實現了這些有良好體驗的智慧功能。

我堅信物聯網時代需要這樣的系統軟件。經過一年的研發和運營,指令集公司於2019年6月發佈了商業智能操作系統1.0版本,可用於樓宇、園區等商業場景。通過跟大量的目標客戶和合作夥伴交流,確實看到了廣泛的市場前景。更進一步,在跟夥伴交流的過程中,我也看到了在工業製造場景下更加需要這樣的物聯網操作系統軟件,因此指令集公司也把工業智能操作系統作爲第二個重要的發展方向。

一旦加入創業大軍,每天工作的重點以及思考問題的方式跟以往在大企業工作不一樣了。某種程度上,這是一個身份的轉變,原來是專業工作者,現在是企業經營主。儘管如此,我仍然努力做到對技術保持關注,特別是新興的技術趨勢。我堅持寫技術文章,通過寫文章來理清思路,對相關技術進行全面的整理,並結合實踐提出一些觀點。

2 技術成長

從2010到2020年這10年,我們經歷了移動互聯網的蓬勃發展、人工智能的再次復興、大數據的各種應用,以及物聯網技術在各行各業的應用。我作爲一名從業者,有機會在大公司的平臺上經歷了這些技術的發展與應用,並且也有機會親自主導一個物聯網操作系統的研發和推廣,實屬幸運。

一、移動系統技術

早在2005年,我就選擇了將來往系統技術方向發展,當時還在微軟亞洲研究院工作。我的想法是,在微軟工作最有價值的,應該是鑽研Windows操作系統,這是獨有的機會,所以我從Windows性能診斷分析作爲切入點,研究Windows的內部機理,將Windows線程調度、內存管理、I/O等最核心的模塊剖析了一遍,並形成了一套系統性的診斷方法。有了這些基礎以後,我又進一步考慮應用層的性能問題,以瀏覽器的渲染引擎作爲研究對象,分析渲染引擎的整個計算過程,挖掘可優化的空間。核心的思想是,在計算流程中儘可能把重複的計算移除掉,從而保持整個響應過程的高效。這些研究工作爲我後來做操作系統打下了紮實的基礎。

2010年,我在盛大創新院有機會設計一個新的移動操作系統VisionOS。基本的思路是,在移動設備上,用Linux加一個Web渲染引擎來支撐一個Web運行環境(Web Runtime),既可以運行本地的Web應用,也可以運行在線應用,並且通過插件的形式運行Flash控件。我調研了Linux平臺上可使用的各種圖形軟件,最終決定自行開發一套適合於移動設備的圖形庫,與WebKit高效對接。Linux社區有許多開源的圖形庫,也有像Qt這類比較成熟的跨平臺圖形窗口系統,但它們首先爲了兼容性的目的犧牲了效率,其次爲了提升效率又做了很多優化,從而軟件變得很複雜。在移動設備上不需要複雜的圖形功能和窗口管理能力,我當時的想法是,借鑑Windows圖形窗口系統的思想,簡化到極致,只需要基本的圖形能力和簡單窗口管理,就可以支撐VisionOS的底層圖形需求。移動應用內部的控件管理由WebKit自身來完成即可。

在當時的智能手機硬件環境下,要想做到流暢的觸控體驗,必須進行深入的優化,其中有一點至關重要,把芯片的圖形加速能力啓用起來。由於我們選擇了原生的Linux系統,C庫採用glibc,那就要找到芯片廠商提供的硬件加速庫,才能完成這一優化。然而我接觸了四五家芯片廠商,發現當時的移動芯片廠商基本上只提供Android的BSP,幾乎不再提供Linux BSP,除非有足夠採購量來提出特殊需求。在沒有得到芯片廠商支持的情況下,我們做了一個高難度的折中方案,將Android BSP中的硬件加速庫移植到VisionOS中,也就是說,將非glibc環境下的一個二進制代碼庫鏈接到glibc中,供上層模塊調用。我團隊中的同事足夠優秀,將這些工作做得很漂亮,VisionOS比當時同機配的Android系統要明顯高效,並且也很穩定。

跨進程通信是一個操作系統非常重要的能力,它讓應用與應用之間、應用與系統之間便捷、高效地相互調用功能。系統底層往往有很多瑣碎的細節要處理,包括應用數據到底層二進制數據的轉換、共享緩衝區的管理等。作爲一個面向終端用戶的操作系統,必須要提供一套便於開發者使用的跨進程通信機制。VisionOS選擇了自研方案,在Linux提供的跨進程通信基礎上包裝了一套可解析應用語義的系統機制。(Android對應有一套binder機制,用於應用與系統、應用與應用之間進行通信。)

除了支持Web應用和Flash內容,我們也移植了一些Linux原生應用。此外,有幾個系統應用(包括桌面和相冊應用)也是原生開發的。在當時的硬件條件下,Web版本的相冊應用與原生版本的相冊應用有顯著的性能差異。因此,對原生應用的支持也是VisionOS的一個特點。事實上,我調研了當時Android手機上的某一家應用市場中排名前一千個Android應用,大部分應用包含了原生版本的核心模塊(譬如圖形處理、多媒體處理、重力模型、加解密等),Java代碼只是搭建了應用的框架而已。這些核心模塊是以.so文件格式打包在應用發行包中,導致非ARM處理器的其他手機或移動終端根本用不了這些應用。我曾經接觸過一家MIPS芯片商,儘管他們也支持Android操作系統,但當時環境下他們的終端設備無法直接運行市場上的這些Android應用。

我做移動操作系統將近五年時間,先是做了VisionOS,後來兩年又做了雲OS,在技術發揮上可謂淋漓盡致,但遺憾的是,因爲種種原因沒有真正意義上建立起一個移動操作系統的生態。而隨着Android系統越來越先進,其生態粘性越來越強,再要建立一個對標的移動操作系統,可能性微乎其微了,除非某種特定的產業結構需求出現。

二、架構師之路

最近這10年,我的技術角色定爲架構師可能是最合適的,雖然我自己最喜歡的稱呼是系統程序員。架構師是一個泛稱,在具體場景中,往往對應了一個規模或大或小的系統,可以是軟件系統,也可以是軟硬件結合的系統。比如一個應用軟件,需要有一個架構師;一個操作系統,對應有一個架構師;一個業務模塊,可能也有一個架構師。

隨着互聯網技術和業務的快速發展,架構師這一職業也跟着在互聯網行業風生水起。我談談對軟件架構師,特別是系統軟件架構師的職責的理解。

軟件基本架構首先要合理,所謂合理,指採用當時相對成熟的軟件技術來實現系統功能。

  • 一方面,架構師要對相關的軟件技術有足夠的瞭解或精通,才能做好基礎的選型工作;另一方面也要了解技術發展趨勢,對軟件架構的擴展能力和前瞻性有清晰的判斷。現實中的絕大多數問題在業界都有一些參考方案,或者有一些成型的模式可供參考。
  • 對軟件,特別是系統軟件的性能,有充分的理解。性能包含多方面的指標,有關於資源使用方面的,譬如存儲使用、網絡帶寬使用等,也包括異常情況下的表現、對大併發量的容忍、延遲等。在設計階段有針對性能的預估,在系統上線後有對性能的監控,確保軟件系統健康運行。
  • 穩定性,軟件的質量保障是一個工程過程,在軟件發佈以前經過充分測試,包括功能測試和性能測試。軟件升級迭代流程要充分考慮到兼容性要求,常見的做法是,先採用灰度發佈再全量發佈,並且系統具有回滾能力。
  • 成本控制和預測。高性能和穩定可靠(以及安全性)都是以成本爲基礎的。在技術選型、性能和穩定性保障方面所做的決策,都需要考慮到成本因素。成本是一個綜合考慮,涉及到業務需求、商業價值、技術方案等多方面因素。

從軟件工程師(或程序員)到成爲合格的架構師需要技術積累,有足夠廣闊的知識面,更需要大系統經驗的積累。大系統經驗是難能可貴的,如果在客觀的工作場景中找不到,也可以從剖析一些軟件系統入手,來積累對複雜系統的認知和把控能力。

系統程序員在這方面有天然的優勢,因爲系統程序員往往精通底層工作原理,所以在系統性能、穩定性、安全性等方面能直接看到問題的本質。但是從系統程序員到架構師有一道坎,須放下對底層技術的執念,接受上層應用或中間件的各種妥協,包括一些不優雅或不精巧的習慣做法。

這10年間,我的架構師生涯也分幾段經歷:

  • 在移動操作系統方向上,我核心工作在架構設計上,帶領一些核心模塊的開發小組。

得益於早年在Windows操作系統和Web渲染引擎方向的深入研究,我能夠提出比較合理、先進的系統架構。最具挑戰性的部分是如何構建應用生態,包括應用開發語言和環境的選擇,以及是否或如何兼容市場上已有的應用。

  • 在互聯網業務安全方向上,依託阿里巴巴集團的業務背景,我有機會全面地梳理和構建企業服務安全體系:從系統攻防,到業務平臺的安全,再到情報收集,到研發流程中植入安全要求等。

特別值得一提的是,阿里業務安全的背後是大數據能力和對計算平臺的需求。我曾經負責過某一年雙11防刷單的業務,本質上這是一個大流量場景下惡意流量的識別與阻斷問題,背後的技術要求是,長期的數據積累,再加上實時計算與響應。

  • 在阿里業務線做架構。電商是典型的互聯網業務,從PC互聯網到移動互聯網,既有技術挑戰(比如支撐頻繁的促銷活動),又有大量的數據和服務需要拓展(比如旅行服務)。

阿里巴巴的技術體系具有代表性,其基礎平臺結合了雲計算的各種技術應用。我正好趕上了阿里的中臺戰略:業務中臺+數據中臺,期間收穫很多。其中有一段時間,我一直在研究與思考:如何將學術界關於軟件工程的研究成果與阿里的場景結合起來。阿里業務平臺的工程實踐在有些方面超前學術界很多,但學術界的很多研究成果並未在阿里實踐中發揮作用。

  • 在物聯網方向,我從產業現狀出發,看到一個潛在的系統需求:能夠將一個物聯網場景中的各種IoT設備連接起來並協同發揮作用的系統或平臺。我將這樣的系統軟件稱爲物聯網操作系統,而對應的運行在設備上的系統軟件稱爲IoT設備操作系統。

指令集公司正是做這樣一個物聯網操作系統,其核心能力是連接設備、數據匯聚與處理、業務支撐平臺。設備連接面對的是各種IoT設備和廣泛的協議;數據匯聚解決從數據採集,到數據存儲、分析和處理的全流程;業務支撐平臺主要將設備和數據的共性服務暴露給上層應用。

架構師解決的最核心問題是軟件的複雜性。首先要對軟件複雜性有深刻的認識,否則容易出現“過於畏懼系統而不敢下手”或者“對系統不敬畏而導致犯不該犯的錯誤”的情形;其次,要有足夠的經驗來應對軟件中的複雜性。

如上文所說,系統程序員更有優勢成爲架構師,因爲系統底層往往需要提供基礎的手段來克服一些本質困難,比如單機操作系統的內存管理與線程調度、分佈式系統中的一致性算法等。

三、思考成爲一種習慣

胡適曾經在贈給大學生的文章中提到“總得時時找一兩個值得研究的問題”。作爲IT技術人,雖然已經離開學校,但身處快速發展的產業中,更應該時時思考一些問題。下面列舉一些我在過去十多年曾經思考過或實踐過的技術題目。

  • 內存跨機調度。

還在PC互聯網時期,曾經有一段時期桌面P2P(peer-to-peer)技術很流行。我注意到,有些機器的內存很富餘,而有的機器限於當時1GB或者2GB內存配置而導致性能低下。於是很自然的想法是,讓空閒機器的物理內存放出來供忙機器使用,通過千兆局域網絡,把忙機器發生page fault的頁面按規則調度到空閒機器上。通過改Windows內核的做法,我和實習生實現了一個原型系統。最終的效果沒有預期的那麼理想,但此過程中我們學到了很多,掌握了頁面調度的算法和路徑,並且在內核中實現了高效的網絡傳輸。

  • 快速反彙編。

反彙編是逆向工程的基礎,但是在x86二進制可執行文件中,反彙編難以做到100%正確,原因是代碼段中總有一些空隙,並且指令又是變長的,按順序反彙編很快就會丟失線索。我改變思路,從原始的程序入口和符號表線索入手,層層遞進,不斷挖掘新的線索;若沒有確定性的線索了,我們再從未反彙編的代碼區找出疑似的線索進行嘗試,直至代碼段全部反彙編出來。最終實驗的結果非常理想,比商用的反彙編器達到的覆蓋面還要大。在調試過程中,我們也見識到某些商業軟件使用花指令(很少聽說吧)做了代碼混淆。

  • 一切計算均用查表來解決。

這是一個異想天開的主意,原始的想法是,既然計算機的本質是計算,每天有大量的計算在不斷髮生,其中必定有大量的計算是重複的,對於重複的計算,是不是隻要算一次,下次直接查表就可以了。進一步的想法是,只要在雲端部署一個大計算機,所有的計算都交給雲端查表來完成。這其實也是函數式編程的思想,但我們不知道如何框定一個可計算的範圍。這種想法也僅限於想想而已。這一思路我和實習生後來用在Web渲染引擎的性能優化上,把渲染樹上的重複計算識別出來剔除掉,確實能顯著提高渲染性能。

  • 一個安全問題的解決辦法。

有一次碰到一個做雲安全的朋友,想在雲主機里加一些防護措施,但他的方案和思路沒有得到技術老大的認可。後來,一支菸的功夫,我跟他討論了這個方案,如何把風險降到最小,嘗試着建立一個最小的代碼基讓技術老大審覈。功能性的代碼可以動態加載。據說後來這個方案被接受了。這個方案就是Windows保護模式的變種,也是一些安全軟件採用的手段。

  • 紅綠燈配時優化問題。

坐車或開車的時候經常等紅燈,腦子裏就想着是不是合理,能不能優化;等電梯也是如此。終於今年4月份我在查閱了一些專業論文以後,系統性地整理了一下思路,將一路綠燈作爲目標,進行了概率意義上的分析。並且,進一步以減少停車次數爲目標,在紅綠燈不能控制的情況下,是否通過控制車速來做到車協同路,變相地實現車路協同。

計算使這個世界的運行變得更加高效,我們的生活也爲之發生變化。電腦的計算只是低級(機械)的計算,人腦的纔是最聰明的計算;把平時的閒暇時刻用來做一些發散性的思考,說不定會有意外的收穫。曾經有一位我很尊敬的老師說過,腦子越用越靈光,對此我深信不疑。程序員受編程思想的影響,平時的思考往往是程序化的,我也逃不脫這種思維的禁錮。

3 職業成長

在10年以前,我還是純粹的技術人,以深入鑽研技術爲樂趣。最近這10年,我的職業生涯發生了很大變化。其中最重要的是,開始接觸業務,貼近業務,並且也開始思考產業,最終走向了技術創業。

一、技術轉向業務

我的經歷是一段極其緩慢地從純技術崗位走向業務的過程。先是在學校裏工作,我職業初期做過一個地圖編輯產品,並進一步搭建地理信息系統,但很快就走上了教學科研崗位,脫離了業務需求。接着在微軟亞洲研究院工作,比在學校裏還純粹鑽研技術。這是一段非常幸福的時光,大部分時間可以海闊天空地思考技術,做實驗。能做成原型就不錯了。

進入工業界做移動操作系統和安全保障這一階段開始接觸業務,前者需要運營一個移動操作系統,後者要支撐阿里移動業務的安全。實際的需求來自於運營方或業務方,我的職責是做好技術和實施方案。如果把這些工作也看成業務的話,則它們屬於後臺支撐性的業務。

我在阿里後期階段的工作跟業務(旅行電商)結合越來越緊密,也參與一些業務發展會議。除了做一些技術決策以外,還需要在業務需求基礎上平衡和分配技術資源。如果有人問我,在阿里最值得學習的是什麼,我的答案是阿里做業務的方法,包括如何制定目標、拆解目標,以及如何運營一個業務(特別是利用數據來運營業務,這是阿里的優勢)。雖然很多書或者文章也會講這些方法,但再多書面的學習都抵不上親身參與一個業務週期更爲有效。

二、產業的思考

能將自己的工作融入到一個產業中,這是擴大視野最好的做法。有些技術或產品天然要從產業的角度來看待,操作系統就是這樣的典型產品。做移動操作系統要結合移動互聯網產業的發展來思考,上游有芯片廠商,下游有手機廠商和移動服務商,可能中間還有設計公司或系統服務商。

2012年我曾經訪問過多家移動芯片廠商,瞭解到芯片廠商對於移動操作系統的態度和技術支持,知道自研獨立系統的困難,並且從一些關鍵點上探索可能的技術方案。另外,通用市場和垂直領域各有不同的要求,其對應的產業鏈不一定是相同的。最終如何形成生態,包括硬件產業的生態、移動應用的開發者生態,決定了一個移動操作系統應該使用什麼架構、如何運營。

我花了五年時間想做成一個移動操作系統,有這樣的機會是非常幸運的,但最終沒有做成卻是遺憾的。我個人獲得了成長,這是一個額外的收穫。

2018年我轉到物聯網領域,再次趕上了一個快速發展的產業。儘管物聯網被提出並發展有很多年了,但是其發展空間仍然廣闊。我們在各行各業都能看到設備在聯網和升級,智能家居、汽車、監控攝像頭、空調、電梯、人車通行道閘、工業生產設備等等,都以各種方式連接上網絡。

基於對衆多設備連接網絡的技術路徑和整體軟件結構的分析,我認爲除了設備上的操作系統,還需要一個針對物聯網場景的系統軟件,它解決該場景中的設備連接和數據共享的需求,讓這些設備形成一個整體來協同工作。

從物體聯網的角度來講,這纔是真正的物聯網操作系統。產業界既有的做法是建立共享的物聯網平臺,然而大量的業務場景中這種共享平臺並不能滿足需要;另一方面,在許多業務領域中已經在以各種方式來解決設備連接和數據共享的問題,但往往是一些局部的非通用方案。

跟上一個產業的發展,比跟蹤一項技術的發展,要困難得多。這需要不斷學習,不斷思考。產業中的很多知識和經驗並沒有那麼高科技,它們來源於實踐者的日常活動中,包括失敗的和成功的各種嘗試。這10年間,我接觸到了一些引領產業發展的人物,從他們身上學到了很多,也開始從產業發展的角度來思考問題。

三、技術創業感悟

從2018年我選擇了加入創業大軍,最深刻的體會是:離開大平臺了,你就什麼都不是了。經歷了兩年不到的創業歷程,說幾點感悟:

  • 技術創業,要快速搭建出目標軟件,並找到試用客戶。

這一步是把創業的“故事”變成看得見、感受得到的場景,產品可以不完善,但要體現出核心理念。此步驟既可以驗證可行性,也會接收到試用客戶的初期反饋。創業前期是個不斷試錯的過程,每走好一步都可以增強支持者(包括股東、投資者,或合作伙伴等)的信心,也讓團隊更有信心。爲了減小試錯的代價,快是最有效的手段。

  • 聚焦。

用技術來賺錢有各種途徑,越貼近用戶需求的技術或產品,相對而言變現容易得多。底層技術和產品要獲得市場認可的週期則長得多。

我們經常面臨各種誘惑,比如有客戶希望做一些他們的應用需求(像小程序之類的),或者客戶已有的系統有遺留的問題需要解決一下。承接這樣的需求可以快速地賺到錢,但影響主線產品的研發進度。作爲初創的技術公司,一定要抵擋住誘惑,學會拒絕。做系統軟件產品,更要耐得住寂寞。

  • 時刻保持危機感。

在大平臺上工作,危機感源於自己的職業價值;而一旦開始創業,危機感來自於公司的生死存亡。這種危機感可以把一個人或一個團隊的潛能發揮出來。做好技術是一種聰明,而面對內心中的危機感,需要的是智慧。

  • 信任團隊。

技術人創業,有大量知識需要補充,涉及財務、法務、品牌、市場、商務等,自己不可能在每個方向都成爲專家,所以要依靠團隊,信任團隊。有了凝聚的、可信任的團隊,企業才能走得遠。

4 寫在最後

程序人生又10年,但這10年我實際上跟程序代碼的接觸並不多。曾經有一次,我團隊中的架構師給我講代碼實現,他怕我聽不懂,就用以前DOS時代或者Windows時代的系統機制打比方,向我解釋當前的架構方案。

感謝這些架構師對我的貼心,確實軟硬件技術發展都很快,編程的理念也有不小的變化。用10年的跨度來看技術進步,老程序員的知識結構是需要升級的。在國內IT企業市場,程序員35歲是一個職業坎,45歲很多程序員就屈服於現實了,55歲絕大多數就得退羣了。

我在20年前寫第一篇程序人生時,提到了我是軟件開發隊伍中的老兵,那時一方面是由於身體的垮塌,另一方面也是感受到了後浪的力量。

最近這10年,我還培養了一個輔助習慣 —— 跑步,跑的距離從5公里開始,到10公里,再到半程馬拉松(約21公里),然後到全程馬拉松(約42公里)。跑得不快,但能堅持下來。我希望自己的程序人生還能有至少兩次續篇,寫代碼不一定多,但仍然保持跟代碼的接觸。

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-06-18
本文作者:程序員大本營
本文來自:“cocoachina”,瞭解相關信息可以關注“cocoachina”

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章