屬於我的三年·第二年

語言: CN / TW / HK

今年成就

「反混沌」計劃

正如下面的想法所說——

2018 年年初形成的理念,誕生的名字;2020 年年中明確了方向,堅定了信心。

願景 - 目標;追趕 - 超越。

If not ME, WHO? If not NOW, WHEN?

經過三年左右的發酵,終於在今年開始著力去建設「反混沌」。

當前在工具層面有三大體系:與日常開發息息相關的各類底層基礎設施,如程式碼校驗與格式化、開發套件等的 Infra;以「設計即程式碼」為目標的跨 JS-based 技術棧、跨平臺 GUI 開發的Fxxk Design;以「需求即程式碼」為目標,將前端應用各個層次、各個環節之間的通訊規範化、標準化的Future.js。

目前將「反混沌」在工具層面的藍圖劃分為四個階段,正處於第一階段,其目標就是實踐並驗證「聊聊前端 UI 元件」與「聊聊中後臺前端應用」系列文章所闡述的思想理論,具體體現為 PetalsKokiriZoraOrganikHandieBulbasaurSquirtle 等庫/框架。

從年初開始到現在利用非工作時間斷斷續續地為「反混沌」寫程式碼,至今為止的進展為——

在 Petals 中定義了將近 90 個以上 UI 元件的介面 ;寫了 50 個以上 與 Vue 繫結的結構元件基類 ,12 個以上 與 React 繫結的結構元件基類 ;自研了 30 個以上 Vue 元件 ;初步適配了 45 個以上 Element 元件 ,30 個以上 ViewUI 元件 和 12 個以上 Ant Design 元件

在 Organik 中提供了檢視、欄位、動作、搜尋、過濾器、模型、模組等抽象,能夠通過收集相關元資料並根據情況建立上下文,在應用中注入後使用,助力配置化開發。

在 Handie 中將基於 Petals 的 UI 元件及 Organik 所提供的機制進行整合,內建了一些無頭部件及資料型別定義,並外接了為 CRUD 相關功能拿來即用的部件,可以在中後臺前端應用中直接進行配置化、模組化開發。

在公司內我已找到兩個試點專案,並進行了小範圍「推廣」,目的在於尋找潛在的使用者、合作者和共建者。有興趣者可以加入「 Fxxk Design + Future.js 興趣組 」進行討論交流。

打工生涯

在去年年末,經過幾個月的休整後,我加入了一家行業軟體公司的資料智慧相關團隊。這雖然不是一個純粹的業務部門而是中臺部門,但對於前端這個職業來說它就是業務部門——發展瓶頸是一樣的。

在決定加入這個部門前,我的目標很明確——先搞基建,解決前端內部問題及與上下游協作問題;然後嘗試部門內向架構或產品轉型,這樣就不存在前端職業發展瓶頸的問題了。

團隊中算上我總共有三個前端,在我來之前已經積累了很多技術債:規範缺失,抽象不足導致的強耦合和大量重複程式碼,程式設計方面的問題等。

作為團隊中最「老」的前端,結合現狀與我個人的目標,在心裡初步定下了前端團隊的大概發展方向:

  1. 規範化、標準化——讓開發流程變得更正規、有序,讓專案維護和開發起來更容易;
  2. 配置化、低程式碼化——提高業務從需求到交付的效率;
  3. 自動化、智慧化——提升部門內部的整體效率。

前兩個是解決前端內部問題,最後一個是解決上下游協作問題。

第一個的規範化、標準化已經基本完成。主要是編寫並與團隊成員討論確定了《編碼風格》、《目錄結構劃分模式》、《程式碼稽核規則》和《技術方案評審規則》。以這些為思想指導,配以工具和人為干預,提升了一些程式碼質量。

當前正在進行配置化改造。用 Handie 對一個有幾十個業務模組且模組間依賴混亂的專案進行重構,取得了一定成果——前端整體的目錄結構按業務模組劃分,部分列表頁改為配置式;由於 Handie 的設計所帶來的約束,促使拆分出高內聚的功能模組,大幅提高了程式碼可讀性、可維護性、可複用性。

因為 7 月中到 11 月底「外出」支援業務部門一個專案的開發,被迫中斷了前端專案重構,但也有了另外的收穫——

支援的專案主要是做一個長得像電子表格(Spreadsheet)的配置工具,有低程式碼那味兒了。

看了幾個開源庫,想要滿足業務需求都需要二次開發,並且專案的 deadline 在那呢,沒那麼多時間深入研究它們那複雜的程式碼,最後決定 fork 一份 x-spreadsheet 做渲染器,自己寫 資料邏輯操作部分 :合併和取消合併單元格、插入與刪除行列等。在魔改 x-spreadsheet 時還順手 幫它摁死幾隻「小強」

上面這個只是個小收穫,更大更有意義的是幫我驗證了 Handie 的模組化和跨環境的能力。

我開發的長得像電子表格的配置工具,姑且叫它「底稿電子表格」,在兩個相互獨立的應用中都用到這個功能,雖然它們都是基於 Vue 的,但用的 UI 元件庫不一樣,分別是 Element 和 ViewUI。

大部分人遇到這個場景可能要頭疼了——在兩個應用中用 Element 和 ViewUI 各實現一遍功能?這顯然不可能,後期維護成本會高得離譜!並且,如果再要整合進其他應用中呢?用其中一個 UI 元件庫去開發那個模組,然後在整合的應用中再額外引入那個 UI 元件庫?別想了……怎麼保證模組的樣式與應用的風格統一併且低維護成本?

由於在專案中引入了 Handie,所以我一點也不頭疼——歸功於 Handie 及其配套是基於介面程式設計的,在開發底稿電子表格模組時只考慮 API 的呼叫、拼接就好了,什麼 UI 元件啊請求服務的,都在整合的應用中注入進去。

「底稿電子表格」模組整合

上圖中紅色部分是 Handie 及其配套與我自研的電子表格庫;藍色部分是具體的業務應用;綠色部分是底稿電子表格這個被整合的模組,它單獨存放在一個 Git 倉庫裡,作為 NPM 包被業務應用依賴。

另外,在「外出」期間與對接的前端應用的 owner 及公共體驗團隊的前端負責人和其他人員針對 Handie 有過一些交流,為日後的合作及推廣做下鋪墊。

個人網站

在去年年終總結中談到關於個人網站的來年期望時,我提到——

上面列出的那些模組基本已經能夠看到雛形,就差將分散到其他平臺的資料轉移過來了,然而這正是耗時耗力的體力活,尤其是在當前這種直接編輯檔案的方式下。為了稍微提高點編輯效率,我要做個基於 Git 的 CMS;為了能夠隨時發想法和方便分享內容,需要做個移動客戶端。

由於這一年將精力主要投放在「反混沌」計劃工具層面的體系建設上,因此在「以個人為中心的服務」的工具開發上沒啥進展,只是有些資料上的積累,令我的個人網站首頁瀏覽起來更像是在看豆瓣動態、微信朋友圈或是微博——這也算是我的目的。

個人網站首頁的「時刻」

在積累網站資料的過程中,我進一步地想要 將 Teambition 上的任務、Google Sheets 上的每日記錄、語雀上的筆記等全部個人化 ,讓我的個人網站不僅是「個人版豆瓣」,還是「個人知識庫」——(儘量)任何由我產生的記錄、內容都掌握在自己而非平臺手中,集中在我的個人網站上,通過 Git 倉庫去組織與管理。

同時,產生了一些開發消費 Git 倉庫中資料的工具的想法。除了去年所說的基於 Git 的 CMS,另一個比較重要的應該是基於瀏覽器的工作臺(Browser as a Workbench),主要用來處理每日的任務、工作記錄以及其他不向網際網路公開的內容。

日常生活

在工作與生活方面,去年的期望是今年能夠達到「work-life balance」——

工作日,也就是非節假日的週一到週五,絕大部分時間是「工作」。以「下班」為分割點,一般情況下不去處理公司相關的工作;下班後不看工作用聊天軟體,有重要事或急事電話聯絡。回家後到睡覺前這段時間,可以做 side project,學習或總結知識,陪老婆等。

休息日,也就是非節假日的週六和週日,一天絕大部分時間是「工作」,另一天絕大部分時間是「生活」;預設是週六用來「工作」,週日用來「生活」。休息日進行的「工作」不是公司相關的工作,而是去做 side project 或寫文章等事情。

節假日,也就是有法定假期的那幾天,絕大部分時間是「生活」,好好陪老婆。

今年差不多是按照上面所描述的規則去做的,能夠達到「work-life balance」,自我控制是一方面,更大的影響因素是公司或者說所在團隊的文化,因此我十分感謝目前所在的團隊,這樣可以在各種意義上健康發展。

因為疫情,很多時候想江浙滬周邊遊甚至到更遠的地方都沒法去,頂多到人煙稀少的山上轉轉,生活情趣少了點。希望疫情早日過去吧!

除此之外,在聚焦注意力方面也有一點點小進展——

現在是資訊大爆炸時代,並且那些資本家為了流量,想方設法儘可能多地吸引每個人的注意力,蠶食十分有限且無價的時間。不是說時間不能拿去浪費,我要主動地去浪費,而不是被動或被迫浪費。

現在那些內容平臺,越做越同質化:想法、影片、文章。每個平臺都提供差不多的功能,都想去搶人然後圈養起來,再一點點割韭菜。他們沒給使用者實在地帶去多大價值,卻總想著收割。沒準兒堅持不了多久就跑路了,留在平臺的使用者個人資訊和產生的內容被怎樣就不知道了。

一方面是為了減少自己在沒什麼價值的事情上浪費時間,另一方面是為了打造「個人知識庫」,我在以下平臺做了清理退出工作:

  • 刪除微信公眾號「Coding as Hobby」上的文章並登出,微信公眾號「歐雷流」暫未處理,但會處理;
  • 刪除知乎上的文章並解除安裝客戶端,是否登出賬號有待考慮;
  • 刪除 SegmentFault 上的文章並登出賬號;
  • 刪除掘金上的文章並登出賬號。

對於內容平臺,難聽、貶低的話這裡就不說了,我有自己比較優質的資訊源,不需要它們。除非哪天出現好的去中心化內容服務,否則我不大可能去用。

一點思考

關於 Web 開發本身,我認為它五到十年內會真正進入平緩區——幾十年內不會消失,但人員需求不會那麼旺盛。

React、Vue 等庫/框架讓開發者將關注點從 DOM 操作 + 狀態操作減為只有狀態操作,各種 CLI 的出現助力了模組化、自動化的同時帶來了工具配置和構建流程的複雜度,將關注點進行了轉移,甚至是分散了。

我認為下一代前端框架所要解決的問題就是儘可能將上層業務與底層技術隔離開——業務線開發人員將精力主要用在業務規則的維護上,對底層的具體技術如 Vue、React 和 Webpack、Vite 等無感知無關心;除了開發框架,還有就是從需求到開發可以針對同一份產物進行協作的工具,也就是「產研一體化」。

上面所說的就是「反混沌」計劃在工具層面的目標。其中,實現「產研一體化」的可以認為是一個無程式碼/低程式碼的工具或平臺。如此發展,業務線就不需要那麼多做複製貼上工作的工具人了。

Web 開發場景的大頭是 to B 的企業服務,隨著低程式碼平臺、RPA、AI、雲端計算等的漸趨成熟,在企業中某個業務模組甚至是整個應用根本無需專業人員去開發,業務人員通過視覺化的方式就能夠自己做出來。

綜合上述兩點與其他的一些因素,會促使企業組織架構和產業形態發生改變——業務導向的企業中對技術人員的直接依賴大幅降低,也就沒必要去招那麼多 Web 開發人員,甚至是完全不需要;技術人員會向技術屬性更強的低程式碼平臺、RPA、AI、雲端計算等廠商流動。

那些技術導向的企業對技術人員的能力水平要求更高,再加上單純 Web 開發方面的方法論和工具(庫、框架)都比較成熟了,不太會去重複造輪子,而是在它們基礎上進行定製。 這樣一來,求職門檻變高了,薪水並不會變高,甚至會降低。

說了這麼多,只是想說——要想未來有競爭力,賺更多的錢,不能將眼光單純放在 Web 開發上, 應該儲備些資料智慧、混合現實、圖形化、結合生物/生命科學的計算等面向未來的技術相關的知識。

任何工具類事物(如科技、技術、服務等)都有時效性,所以如何將它們所產生的利益、價值最大化是很重要的。

來年期望

明年,即 2022 年,我要努力做的事情整體來說有三方面,它們圍繞著同一個中心——

讓 Handie 在 Vue 和 React 應用中達到 production-ready 的狀態,並提供可用的基於 Web Components 的多技術棧執行時共存方案。

將今年落下的 學習研究「領域(domain)」相關知識、方法論、技術的計劃 補上,夯實自己在這方面的知識體系並提高認知。如果有可能,再去學習研究下型別系統相關知識、方法論、技術。

在前端團隊和部門中通過培訓、分享的方式幫助其他人理解領域驅動、模型驅動等思想,促進領域驅動團隊的推動,為「前後端一體化」、「產研一體化」的落地做準備。

總結

在業務導向的團隊中,純做技術層面的建設是「政治不正確」的,一定要留出比較大比例(至少 45%)的業務支撐,否則考評時必然是「不及格」那群人中的。

所以,要發展只有兩條路:要麼轉到技術導向的團隊,專心處理專業技術方面的問題;要麼深入業務而非停留在業務表層,比如向架構或產品轉型。

想要寫出優雅的程式碼,做出優秀的軟體,就要從「寫程式碼」和「做軟體」這些事情中跳脫出去,多瞭解瞭解世界、人類、社會、經濟等看起來與「寫程式碼」和「做軟體」無關的事情——因為你是數字世界的「造物主」。

目前來看,近幾年我關注和要做的方向主要是從需求到開發的「一體化」提效和「個人知識庫」,也許還會有與 Web 3 相關的一些事情。歡迎志同道合且有一定能力的人合作。