入職一年啦

從入職到如今已通過了一年，然而博客幾乎沒有更新。原本畢業時和過年先後是打算寫點總結什麼的，寫着寫着就沒有繼續。

但不寫點回顧的話，內心總感受難受。之後要是想回憶一下當初都作了啥，結果沒想起什麼，感受都是在浪費時間，這就很差了。

這幾天恰好是咱們這批新人入職滿一年，腦中「寫點什麼回顧一下吧」的想法頻繁浮現。索性就把週末時間拿來寫這篇博客了。

公司、部門

在同班同窗的安利下，來到如今就任的這家公司面試。如今咱們在同一個小組。

當初是衝着說不用加班來的（然然後來卻常常加班，雖然是自找的）。此外，待遇好也是很是吸引個人地方~

同事以前的氛圍很好。你們人都挺好的。此外咱們老大（咱們都叫他大大~）常常會請咱們吃下午茶，有時候會組織部門聚餐，上週六還一塊兒去看了《我不是藥神》。小組的聚餐也組織過幾回。前面說過，這幾天咱們這批新人入職滿一年，你們會買下午茶請部門的同事。因而咱們就這樣吃了一週下午茶，哈哈哈。在這樣的部門裏面，感受很幸福~

也有很差的地方。我所在的小組就編程而言，個人水平是最高的了，其餘技術方面的也差很少。這也就意味着在這個小組裏面，沒有大腿能夠抱，只能經過自學來提升本身。自學的進步速度比不上有人帶的速度。這也是我常常感到壓力的緣由——進步速度太慢了。

所幸的是，從去年十二月開始，咱們部門有同事組織起了知識分享會，成立了學習小組。每週五下午會抽出兩個小時的時間給知識分享會。期初是針對特定議題，你們各自學習，並在會上針對議題講述所學內容或發表見解。後來則是由每一個人自定主題，而後上臺演講。主題的範圍很廣，非技術相關的例如：時間管理、如何作好演講、團隊合做等；技術相關的例如：代理服務、分佈式、存儲組件等；不知道怎麼分類的例如：人工神經網絡介紹（我講的），三維地圖重建，密碼學入門等。

總的來講，能學到東西，但仍是不夠。一般只有講師學到的東西最多，其餘人能學到多少，仍是要看講師講得如何。像我講的人工神經網絡，雖然全程都是有畫圖講解的（徹底沒有PPT），可是到了後半部分往深講的時候，仍是有一半同事懵圈了。

項目

一年間接觸的項目總共有三個，姑且稱做項目 A B C。用的語言都是 PHP。

• 主要參與的項目是 A ，是一個用 PHP 寫的至少有十年曆史的任務系統（是否是有點可怕？）。
• 項目 B 是參與了其中一個模塊的重構，但重構得不完全。由於此次重構的目的主要是加個流程的流轉引擎進去。
• 項目 C 是個聊天機器人，用到了人工神經網絡。然而我並無負責核心部分（淚）。

項目 A 放後面講，另外兩個內容比較少。

項目 B

項目用的是 Zend Framework 框架，1.10.8 版本，2010 年 8 月發佈的。如今最新版本是 3。

舊代碼不多用到框架已經寫好的東西，還有很多東西是框架已經寫好，但仍是本身寫的。應該只是爲了用上 MVC 和部分功能吧。

和其餘模塊的重構是把原來的代碼拷一份，而後在上面修修補補的方式不一樣。我基本重寫了全部代碼。把業務相關的東西抽出來，簡化複雜的邏輯，把大塊的代碼拆解成幾個部分。然而這是有代價的，我爲此加班了好多天。不過最後仍是定期交付了。若是不重寫的話，我能夠不加班也能完成一樣的功能，可是過不了本身這一關。本身經手過的代碼，讓它們保持之前那種糟糕的狀態，實在不能接受。

不過我也知道本身這樣作的風險。從公司的角度講，天然是項目越快完成越好。萬一要是由於我想把代碼寫好一些，致使項目進度變慢，那問題就大了。雖然在很多地方我剋制了衝動，但仍是常常忍不住去重構代碼。幸運的是，項目的進度要求都沒有緊張到沒有時間來作優化。這也是受到公司氛圍的影響吧~

項目 C

一開始衝着機器學習來的，興沖沖地加入到項目裏面，想着學點有深度的東西。但果真仍是太年輕了。自身並無相關的技術積累，想經過加入項目來提升技術的想法，是否是太幼稚了呢？

在這個項目組裏面，到目前爲止我都是負責後臺的簡單工做。例如提供知識庫的錄入界面等各類界面及其配套的後臺邏輯代碼，大部分工做都是前端相關。後端框架用的 EasySwoole ，由於涉及到通訊，須要用 swoole 擴展。不過我這一部分的工做跟這個框架其實沒什麼關係。先後端接口用的 Restful API 標準，可是 GET 查詢的支持不完善。

其餘同事有的負責模型訓練，有的是負責通信模塊。雖然原理我懂很多，但沒有實踐。後面咱們會交換工做內容，我到時爭取換到模型訓練去。

說到我在這個項目所作的事情，能夠引出一個話題：

前端 VS 後端

其實我指向好好地作一個後端開發人員。嗯！前端是要了解一點，可是也沒必要要這麼早吧。等此次作完，之後再有其餘前端的事情，我都推掉。此次沒有早點推掉，把本身給坑了。

待我成爲後端大佬，須要拓展技術面的時候再去多瞭解和實踐前端。

項目 A

因爲是主要參與的項目，因此能夠說的東西就比較多了。下面我就叫它流水系統吧。事先說明，這是個內部系統，用戶量不會大到哪去，但使用頻率很高，並且跟絕大部分提供給用戶的線上的機器有關。

前面說過，這個項目的歷史有十年以上。想象一下十年前的開發吧，如今流行的幾個框架中，最先的是在 2007 年左右發佈第一個版本。沒錯，也就是說這個項目沒有用到任何框架。最多見的 MVC 也是不存在的，基本全部東西都寫在一塊兒，面向過程。聽說這個項目的開發人員基本都是從運維轉到開發，包括目前組內的幾個成員都是從運維轉到開發的。

不過神奇的是，我參與的這部分（也是整個系統最有業務價值的部分），能夠說是隔離的還不錯。前輩們已經把前端相關的東西封裝好了，只須要到配置界面配置一下，就能組合成一個簡單的表單界面。剩下的就是寫後端部分，你能夠把它當作是一個接近純 API 形式的系統，最終只要 return 一個 json 字符串就好了。這點實在是使人佩服。這也爲我接下來的改造提供了便利，由於在整個請求中，會有一個地方成爲主入口，只要在這個地方作個攔截，把部分請求重定向到另外一個位置，最後返回的時候是一個符合規定的 json 字符串就行。

流水系統的開發面臨幾個問題：

• 代碼管理方式落後
• 本地環境搭建複雜
• 單個代碼文件過大
• 難以測試
• 維護成本高
• 沒有文檔

聽說在我來以前的一年，已經有說要重構項目了，但一直沒有行動。由於維護自己就要花去不少時間，再加上需求一直作不完。這周才又開始提起這件事，由於組內目前有幾個同事，他們負責的部分沒有需求了。並且我在最近的半年間也作了很多事情，對他們也會有幫助。

接下來講說我怎麼逐個解決上面那幾個問題吧。

1. 代碼管理方式落後

本來能夠說是沒有什麼管理方式。事實上咱們改代碼基本都是直接到線上用 vim 改（致使我如今 vim 幾個快捷鍵用得 66 的）。一旦保存，就會自動生成一份備份文件到指定的備份目錄。而後咱們會有代碼審覈，要調用 linux 的 diff 比較兩個文件的不一樣，而後截圖發到討論組讓其餘人審覈。有時候改的地方多，要截圖好幾屏幕。

連 svn 都沒有，更不用說 git 了。

今年三月，我開始推進代碼管理方式的變化，改爲用 git 管理代碼。固然，老大是支持滴。我作了幾件事：

1. 準備工做
   • 找其餘組瞭解到咱們這邊內部有搭了一個 Gitlab，因而到上面建了個倉庫。
   • 線上代碼整份備份，拷貝一份到我本地。把線上代碼目錄下，一些沒用的東西都移動到一個備份文件夾。例如文件名爲：！或者`這一類奇奇怪怪的文件；還有一些開發者我的的備份文件、測試文件等等，通通移出去。這些在移動以前都會把列表發出來，讓其餘人確認過才移動。
   • 找到程序運行時產生的文件夾，這些是要放到 .gitignore 裏面的。
   • 本來超過 100G 的項目文件夾，只有大約 80 MB 的有用文件。大部分都是 log。這 80 MB 的文件裏面，還有能夠排除掉的，但可能有危險，就算了。這樣之後要搭建新環境的時候，只要下載 80 MB 的文件就好了。以後把這些文件提交到 Gitlab 倉庫上。
2. 代碼同步
   若是使用 Gitlab ，那麼要怎麼把代碼同步到線上機器呢？最簡單的就是在線上目錄下直接用 git pull 了，只是要記得把 .git 目錄屏蔽掉，否則別人直接把你 .git 下載過去，就能獲得你整套代碼了。固然，也能夠在另一個目錄 pull ，而後用 rsync 同步到線上目錄。後一種方式會比較安全，不過沒有采用，多是由於要支持線上修改代碼？
   線上修改代碼是爲了在上線代碼後出現問題時可以當即在線上修改代碼，而後不能影響到後續代碼上線。要補充一點，這個項目沒有按期發佈版本的概念，一旦完成需求，就當即上線。既然是這樣，就不能直接 git pull 。因而我寫了個腳本專門用來同步。當線上代碼和要更新的代碼有衝突時，自動處理衝突——其實就是自動用衝突部分的線上代碼覆蓋上線的代碼。
3. 培訓
   上面準備工做作完了，就得向組內其餘人推廣了。組內只有我那同窗有接觸過git，但也是那種 push 和 pull 的程度。此次用的是 GitHub Flow 的方式，就是 Pull Request + 審覈，沒有人能夠直接 push 代碼上去。
   我總共組織了三次培訓，每次半個小時到一個小時。把 git 的基本使用和 GitHub Flow 的方式都介紹了。而後還寫了篇教程。以後你們就開始用起來。

先後大概一個月的時間，前期準備花去大概三週（畢竟還有需求要作）。培訓先後跨度一週。培訓完的下一週開始使用。算起來應該要從四月初開始算起，到目前爲止合併了 760 個 Pull Request。

咱們組四月份的時候來了個新人。當後來談起 git 的時候，我說了在三月底才逐漸開始使用 git 以及之前是怎樣管理代碼的時候，她都驚呆了。

2. 測試機

讓咱們回到還沒使用 git 的時候。

上面說了修改代碼時一般要在線上修改，爲何不在測試機上修改呢？

• 測試機代碼跟線上代碼有不少不一樣的地方。數據庫也有不少不一樣。我那個同窗就曾經栽在數據庫表字段不統一上。
• 咱們的系統依賴於其餘系統提供的數據，在測試機上難以獲取所需數據，雖然他們也有提供測試機，但很差找到合適的數據。

不過我也有一段時間是在測試機上修改，而後複製到線上。可是 vim 編輯雖然挺熟悉的，但仍是不舒服。後來就下載 PHPStorm ，在本地電腦上修改，而後經過它內置的 ftp 傳到測試機上測試。

爲啥不在本地搭建個環境呢？這其實也挺困難的。

• 代碼有不少依賴，甚至於有些代碼寫的是用 linux 的路徑。你在 windows 下根本無法跑。
• 把系統跑起來的數據庫表要先建好，數據要先準備好，但很差找到須要哪些表。

第一點還好解決，畢竟有虛擬機呀。第二點就比較麻煩，所有數據都同步的話，要幾十個G吧。

因而本地搭建環境這點就先擱置了。要等到接下來講的這件事作完纔有繼續的可能。

3. 調試

先說以前的開發是如何調試代碼的。首先確定是在線上調試，調試的手段是 echo var_dump print_r 這些，直接把數據打印到界面上。是的，你沒看錯。用戶都能看到他們打印出來的信息。

大量的數據暴露給用戶，並且我以前還看到把一個接口請求的 key 暴露出來。更慘的是，這是已經調試完，沒有刪掉的。也就是說存在至關長的一段時間。事實上代碼裏面有大量的這種輸出信息沒有刪除。所幸直接用戶都是公司內部員工，這要是外部人員使用，早炸了。

對於開發者而言，若是是本身寫的代碼，echo 看一下可能很快就找到問題。但若是是別人寫的代碼，可能要 echo 一大堆才知道問題在哪。更可怕的是，這若是是系統基礎層面的問題，根本不知道在哪找 bug，那代碼一坨坨（來自同事的描述）的。

有個比較好的地方是，這個系統有備機。我在備機上裝了個 Xdebug，這才使得斷點調試成爲可能。固然，爲了支持多人能同時調試，還去裝了個 dbgp。這些在我以前的博客中有寫了：php+xdebug+dbgp遠程調試（多人）。當時發到博客園首頁，還被管理員踢掉哈哈哈。

此後我都是使用 IDE 來斷點調試，這才能知道系統究竟是怎麼運行的。

4. 本地環境

可以斷點調試意味着我可以知道它鏈接了哪些數據庫，查了哪些表。這樣就能夠開始作配置了。

爲了方便之後新搭建系統，我還寫了個半自動初始化的腳本。把要修改的配置組織好，而後轉化成原系統可用的數據。還提示了要把系統跑起來，須要同步哪幾個表格。可是碰到路徑依賴的代碼時，仍然要再去手動修改代碼，而後重試。

這種方式持續很長一段時間，直到我最近接觸 Docker 才獲得解決。我在 Windows 10 上面裝了 Docker。而後對 PHP 鏡像作了定製，其實就是額外裝了 xdebug 、 composer（PHP 的包管理工具）、一些項目會用到的 php 插件。

通過一些配置的調整，總算是跑起來了。效果還不錯~不過還有幾個地方須要調整和添加的，後續再繼續處理。

5. 單個文件太大

看如下幾個數字：

19264 17622 13223 12160 6621 6067 4655

這些是幾個主要文件的行數，最大一個將近兩萬行了。用 PHPStorm 打開後有點吃力，解析要好一下子。

裏面實際上是不少個 if-elseif-else 組合成的，每一個分支完成一件事情。其實能夠把它們看爲一個個 function，事實上把它們抽取爲 function 也能正常執行。最大的一個文件由大概 200 個分支組成，平均每一個分支 100 行代碼。可是也有很多分支有 5~6 百行代碼，3 百行的 foreach 循環瞭解一下？

後來我作了個改變。前面有提到，它在某一個地方會有一個統一的入口，而後也有一個統一的出口。我另外建了個文件夾，而後建了一個文件做爲新的入口，把知足條件的請求轉發到這個入口。就像是進入一個子系統。

這個子系統能夠直接使用 PHP 的一些特性，例如命名空間。在裏面寫代碼直接用面向對象的方式來，只要最後返回的結果是 json 就好了。這樣能夠爲之後的重構（實際上是重寫）作準備，提早寫好一些工具類，積累一些須要注意的點。

在實現上面，沒有直接使用開源框架。一個是編碼問題，咱們項目是 GBK 編碼（其實也不是很難解決）；另外一個是之後項目重寫的成本問題。目前不用框架，把骨架搭建起來仍是蠻快的。在一些實現上面會去參考開源框架，像 Yii2 和 Laravel ，也會往 PSR 上面靠。

這樣單個文件的大小就變小了，變成多個小文件。不少能夠重用的代碼也能夠封裝起來，放到類裏面。前面那麼多年，沒有留下什麼有價值的代碼，實在是惋惜。若是之前有封裝一些業務相關的代碼，如今要了解業務也比較方便些。

新的代碼會寫在這裏面。若是有舊代碼須要維護，且感受能夠重構的時候，也會把代碼重構到子系統裏面。

這個是在 git 以後。由於作這種大規模添加和變動的時候，有 git 會比較好處理。

6. 測試

這項目的測試基本都是在測試機上直接進入網頁測試，沒有什麼單元測試的概念。有時候測試機沒辦法測試，只能到線上測。Emmm...是挺危險的。

嗯對，沒有專門的測試人員。

如今 git 有了、IDE 有了、面向對象也有了，能夠了解一下單元測試。正好公司有這方面的績效要求。

之前那些代碼很難測，我先處理的是面向對象這部分的單元測試，引入 PHPUnit。先把工具類的單元測試搞定了。

接着想着怎麼測試之前的代碼。仍是從單一入口那裏入手，一些全局變量都事先聲明好，還有一些文件都導入進來，而後調用。固然還要處理其餘問題，例如原先的代碼裏面，會直接 echo 出東西，這些要用 ob_start() 這種攔截下來。不過 PHPUnit 也有對這方面的支持。

7. 文檔

這項目沒有什麼文檔，他們的理由是業務常常變化，文檔要常常改，麻煩。不過連基礎的業務無關的開發文檔都沒有，確實麻煩。新人來了還得找導師問，由於並無相關的培訓課程。

後來我寫了篇開發文檔，填補了這個空白。（聽說寫得不錯）

自從引入了子系統，也補充了篇開發文檔。不過由於結構挺清晰了，不用文檔也能開發。

至於業務上的文檔尚未寫。以前公司的機器在作集羣架構調整，目前咱們這邊還在作相應改變。調整完成後，我會逐漸把業務文檔補充上去。

8. 重構

上面提到這個項目要重構（重寫）。這個其實才是我最感興趣的地方，由於能學到很多東西。到時要向大佬們多請教。若是到時有大腿來指導就行了。

結束

你可能會問，哪來時間作這些事情？不用作需求嗎？我說一個數據。咱們加班是沒有加班費的，可是有一個誤餐補貼。天天加班到八點半後就有 20 塊錢，而我上個季度的補貼是 1k+。

這一年間作的事情看起來不是不少，也不是不多，惟一能肯定的是學到的東西很少。這是最讓我憂慮的地方。這一點以前咱們部門的一個大佬跟我聊的時候有說過，孤軍奮戰進步很慢。其實部門裏面的高手也是有的，但我不善於使用已有資源這一點是硬傷，要想辦法有所突破。

但願接下去能有更多進步的機會~我也會去多爭取這樣的機會。