我在日本最大的房地產信息網站作重構

日本互聯網行業現狀

去日本以前就對日本互聯網產業的各類奇葩現狀有所耳聞,本身過來以後更是親身經歷了不少。總的說來有如下幾個方面:前端

  1. 整體技術通常: 日本計算機理論研究其實作的很是不錯,可是工業運用方面卻作的通常,有點兒不思進取的感受。不思進取到什麼程度呢?好比說日本最大的門戶網站Yahoo Japan,搜索引擎居然是直接用的Google的API。webpack

  2. 開發體制落後: 由於日本的製造業很是發達,取得過很是大的成功,不少實業產品都是經過層層外包實現的。簡單來講就是OES,貼牌。經過這種模式,他們在傳統制造業取得了很是大的成功,因此對於興起的互聯網行業也堅決果斷地沿用了這套模式--層層外包。git

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

以上的緣由形成了不少問題,以後我會在後面的例子裏具體說明。github

剛入社時的狀況

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

技術棧

  • 前端技術棧: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人才,這邊急缺。有興趣的朋友能夠關注個人知乎,微博帳號歡迎來諮詢。

筆者知乎

筆者微博

相關文章
相關標籤/搜索