我在日本最大的房地產資訊網站做重構

再見尼克發表於2018-05-03

日本網際網路行業現狀

去日本之前就對日本網際網路產業的各種奇葩現狀有所耳聞,自己過來之後更是親身經歷了很多。總的說來有以下幾個方面:

  1. 總體技術一般: 日本計算機理論研究其實做的非常不錯,但是工業運用方面卻做的一般,有點兒不思進取的感覺。不思進取到什麼程度呢?比如說日本最大的入口網站Yahoo Japan,搜尋引擎竟然是直接用的Google的API。

  2. 開發體制落後: 因為日本的製造業非常發達,取得過非常大的成功,很多實業產品都是通過層層外包實現的。簡單來說就是OES,貼牌。通過這種模式,他們在傳統制造業取得了非常大的成功,所以對於興起的網際網路行業也毫不猶豫地沿用了這套模式--層層外包。

  3. 從業人員大多都是半路出家:大多數都非科班出身,基本都是從其他行業轉職過來的。不同年齡層的人都有。

以上的原因造成了很多問題,之後我會在後面的例子裡具體說明。

剛入社時的情況

筆者入職的公司叫リクルート,是一個提供資訊諮詢的公司,旗下有很多分公司,基本涵蓋了日本人生活的各個方面。房地產,美容,酒店預定,二手車,招聘,等等。你可以想象一下,國內大眾點評,鏈家,58同城,攜程等等資訊提供網站集合在一家公司的情況。筆者入職後具體工作就在題中提到的叫的房地產資訊平臺分公司工作。筆者進入的組,是負責移動端網站的開發維護。

技術棧

  • 前端技術棧:PHP(Zendframework)+模版引擎Smarty+自己開發的類似jQuery的庫,整個環境部署在AWS上。
我在日本最大的房地產資訊網站做重構
  • 後端技術棧: 至於後端的架構就不清楚了,因為是外包出去的,開發和維護都是在外包公司在做。對,你沒有看錯,日本最大的房地產資訊平臺,最核心的資料都交給外包公司在做。

那麼,自己公司能做什麼呢?只剩下前端了對吧。那我們來看一看,這個前端他們是怎麼做的。

所謂大前端

放在公司內開發的,也就是自主開發的(這裡的自主開發,其實也有一半左右是常年入駐公司的外包人員),只剩下PHP和前端這塊了。那麼有朋友會問了,不是說沒有後端嗎?這裡不是有PHP嗎? 入行比較早的朋友們可能都知道,在沒有AngularJS,ReactJS,VueJS等等前端框架之前,網站架構的模式。早些年間,模版引擎都是在後端的。後端獲取必要資料之後,根據模版繪製成基本可用的HTML傳送給前端,前端獲取了繪製好的HTML後,只是做一些動畫或者AJAX非同步請求等等動作。這裡的PHP就是做的模版繪製的工作,還有就是訪問API獲取處理資料。在這種構架下,可以將PHP歸為大前端範疇。

面臨的問題

作為日本最大級別的房地產資訊平臺(雖然日活躍也就40萬而已),前端構架如此簡陋,肯定是有問題的。 那麼問題在哪裡呢?

技術問題

  • JS/CSS層沒有框架,DOM的操作全是直接手動操作,自家開發的類似Jquery的庫也是時不時出現一些很難排查的BUG,重複程式碼和全域性函式漫天飛。

  • 模版引擎在PHP層,有zendframework作為框架,所以多多少少還有些章法,以頁面為單位組織著模版程式碼,但是頁面之間有很多重複的程式碼,造成維護困難。

  • 總的來說,就是亂。

組織問題

至於為什麼這麼亂,很組織構成有很大關係。

日本網際網路公司是培養產品經理的天堂。我們公司算是大企業,裡面的程式設計師有不少都是正社員。但是大多數的網際網路公司,寫程式的都是外包人員。只有產品經理是正社員。這樣的組織架構就形成了,程式設計師完全無條件服從於產品經理。就算是正社員的程式設計師,話語權都不是很高。怎麼樣,會點日語,想當產品經理還不趕緊來日本?

以上的組織結構,就造成了為了KPI而趕進度的(動ければいいじゃん)的程式碼。產品經理看不懂程式碼,不關心程式碼質量,跟別說公司高層了。這樣的情況下,加上本身程式設計師本身素質不到位,寫出的程式碼可想而知,反正,外包程式設計師大多數都是幹完一個季度就要走的。

說多了都是淚,大環境是這樣,我一個小小程式設計師也無法改變,我能做的就是在組內好好推動一下的先進概念技術。

最初的解決方案

如果你的公司恰巧也是處於這樣的一個很落後的架構的情況下,你也在尋找出路,希望這篇文章能給你一點點啟發。

當時入職的時候,AngularJS已經開始疲軟,ReactJS已經無人不曉,VueJS也剛剛開始發力。前端如同春秋戰國,各國崛起,一派亂世之像。

準備工作

第一反應當然是匯入新框架。當然,在匯入前端框架之前,需要為匯入框架做準備。比如說把混在模版裡的JavaScript提取出來,把模版中可以複用的元件抽出來等等細枝末節的工作。

匯入webpack

然後就是將webpack匯入專案,匯入的具體形式是:以介面為單位,每一個頁面對應一個 entry 。在 entry 中將每個頁面所引用的 JavaScript import 進來。這樣就把所有的JavaScript就都經由webpack打包處理了。這裡的webpack多頁面打包處理會存在一個問題就是,重複打包。多個頁面往往會 import 一些同樣的包。這裡我用了 code split 來解決了這個問題,本來 code split 的目的是按需載入,避免過大的包。我這裡用 code split 將所有包做成了非同步包,這樣一來,所有的包都是按需載入並且可以很好的複用。

重構前: 我在日本最大的房地產資訊網站做重構

重構後: 我在日本最大的房地產資訊網站做重構

因為匯入了webpack就可以做很多有意思的事情了,比如說,我在公司內部做了一個類似 storybook 的工具,與 storybook不同的是,我可以執行 PHP 模版。當然,用ES6寫JavaScript也成為可能。

還匯入了 eslint,以及 postCSS ,各種先進工具。大大提高了工作效率和程式碼品質。

選擇框架

匯入了webpack之後最重要的是,匯入前端框架。

但是各種對比,最後選擇了VueJS作為框架進行匯入。有這麼幾個原因

  • VueJS上手簡單,因為組內外包人員都是半路出家,有做音樂轉行過來的,有做拍賣轉行過來的,有做銷售轉行過來的,是的你沒有看錯,有40多歲的女程式設計師,有30多歲的單親媽媽,也有20多歲專科畢業的小朋友。但是有個共同的特點,就是幾門固定技術幹了不下於5年。要他們去學習熟悉新的技術,時間成本,出錯成本都非常高。所以如果能用現有技術,那是非常好的。VueJS的話,HTML/CSS/JavaScript上手就來,我給他們配置好webpack環境,基本上不用學習直接上手。

  • 可以部分匯入,具體來說就是可以掛載在已經繪製成功的 HTML 節點上,也就是說,在PHP繪製好的HTML上,仍然可以繫結 VueJS 例項。

一切看起來都是那麼順利,但是實際匯入的時候,卻遇到了很多問題。

越不過去的坎兒

SEO對我們網站非常非常重要,而且當時Google正式提出了mobile index first的政策,也就是說以後搜尋都要從移動端網站走了。

PHP的模版引擎雖然古老,但是對SEO非常友好,經過常年的修改和運營,已經是非常優的狀態了。公司對這塊非常看重。大家都知道,雖然VueJS 理論上通過 SSR 解決了 SEO 的問題,畢竟是新技術,對於大公司,而且是日本大公司,是非常非常謹慎的。那有朋友就會說了,可以小範圍實驗一下嘛。まあな、我要先說說組織架構了

我在日本最大的房地產資訊網站做重構

公司的移動端網站的開發不止一個組,開發的組是根據市場領域來區分的,比如說土地市場,是由土體市場小組領導的,土地領域的網站開發是由土地市場小組領導的,新的功能的開發是有土地小組發起,然後由土地小組下面的程式設計師開發的。總體來說,網站是同一個網站,根據市場分組,每個分組有自己的程式開發。但是為了全站的維護和更新,還有一個全站的開發小組,我就在那個全站的開發小組裡面。但是在組織上,全站的小組對其他市場的小組並沒有控制權利,控制權掌握在市場小組的產品經理手上。 整個網站大大小小有5,6個小組。各自為陣,組織上有壁壘,如果級別不夠,想全站推動非常非常困難。

關於重構的思考

無法改變的現狀如此,只能再想辦法。 讓我們回到原點來看問題,我到底要解決的是什麼問題?

不是SEO問題,也不是PHP需不需要存在的問題,而是要提高開發效率的問題。

當前的開發效率為什麼低下?

  • Template的程式碼的組織以介面為單位,介面之間通用的程式碼通過複製貼上解決。重複程式碼過多,修改起來到處亂竄。
  • JS/CSS比Template更亂,各自存在於不同地方,沒有按照介面或者功能方式統一劃分檔案或者資料夾,常常為了尋找一個CSS,JS到處尋找,這些CSS,JS之間也存在非常多重複的地方。

那麼當前的問題,就是組織好,Template/JS/CSS這三者之間的關係,那麼怎麼組織呢?

元件化是良藥

不管是AngularJS也好,ReactJS也好,VueJS也好,他們提供的資料繫結,虛擬DOM這些炫酷的功能,其實對我們這種傳統大型CMS網站,沒有太多的用武之地。但是,他們其中很重要的一個概念是非常適用於我們網站的,那就是元件化(Web Component)。

那麼問題來了,如何在沒有框架的情況下實現元件化呢?

webpack-component-loader

具體的解決方案,在我的另外一篇文章中具體闡述過了,

如何在沒有大型前端框架的情況下實現元件化

總結一下就是:通過自己實現的webpack-loader,在開發階段,將Template/JS/CSS按照元件單位放到一起,打包階段將他們各自移動到他們本來屬於的地方。

總結

我的 loader 匯入之後,實現了元件化,但是又沒有改變既有的技術棧,更加沒有影響到SEO,效率大大提高。而且按照大家都推行的元件化的大潮,以後遷移到VueJS,ReactJS或者以後新的框架(只要他符合元件化思想)遷移成本都不是特別大。

PS

看到評論裡很多朋友問我怎麼來日本工作,筆者本身沒有在日本讀大學,是在國內畢業後直接來日本工作的。其實有很多渠道可以過來,特別是IT人才,這邊急缺。有興趣的朋友可以關注我的知乎,微博賬號歡迎來諮詢。

筆者知乎

筆者微博

相關文章